This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
18 duplicates so far ... Build: NetBeans IDE Dev (Build 200710051200) VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05 OS: Linux, 2.6.22.9-91.fc7, i386 User comments: STACKTRACE: (first 10 lines) java.lang.StackOverflowError at java.util.regex.Pattern$SliceI.match(Pattern.java:3502) at java.util.regex.Pattern$Branch.match(Pattern.java:4114) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227) at java.util.regex.Pattern$Curly.match0(Pattern.java:3782) at java.util.regex.Pattern$Curly.match(Pattern.java:3744) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) at java.util.regex.Pattern$Branch.match(Pattern.java:4114) at java.util.regex.Matcher.match(Matcher.java:1127) at java.util.regex.Matcher.matches(Matcher.java:502)
Why was this reassigned to java.editor? The first exception in the reporter is: java.lang.StackOverflowError at java.util.regex.Pattern$SliceI.match(Pattern.java:3502) at java.util.regex.Pattern$Branch.match(Pattern.java:4114) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227) at java.util.regex.Pattern$Curly.match0(Pattern.java:3782) at java.util.regex.Pattern$Curly.match(Pattern.java:3744) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) at java.util.regex.Pattern$Branch.match(Pattern.java:4114) at java.util.regex.Matcher.match(Matcher.java:1127) at java.util.regex.Matcher.matches(Matcher.java:502) at org.netbeans.modules.websvc.rest.support.Inflector$Replacer.matches(Inflector.java:845) at org.netbeans.modules.websvc.rest.support.Inflector.pluralize(Inflector.java:532) at org.netbeans.modules.websvc.rest.wizard.Util.pluralize(Util.java:301) at org.netbeans.modules.websvc.rest.codegen.model.EntityResourceModelBuilder.createContainerResourceBean(EntityResourceModelBuilder.java:97) at org.netbeans.modules.websvc.rest.codegen.model.EntityResourceModelBuilder.getContainerResourceBean(EntityResourceModelBuilder.java:88) at org.netbeans.modules.websvc.rest.codegen.model.EntityResourceModelBuilder.computeRelationship(EntityResourceModelBuilder.java:161) at org.netbeans.modules.websvc.rest.codegen.model.EntityResourceModelBuilder.createItemResourceBean(EntityResourceModelBuilder.java:149) at org.netbeans.modules.websvc.rest.codegen.model.EntityResourceModelBuilder.getItemResourceBean(EntityResourceModelBuilder.java:116) at org.netbeans.modules.websvc.rest.codegen.model.EntityResourceModelBuilder.createContainerResourceBean(EntityResourceModelBuilder.java:104) at org.netbeans.modules.websvc.rest.codegen.model.EntityResourceModelBuilder.getContainerResourceBean(EntityResourceModelBuilder.java:88) Which does not seem related to java.editor in any way. Please do not reassign bugs to java/* without clear evidence that there is a problem is the corresponding module. Anyway, the number of duplicates is wrong - looking at various exceptions, there are obviously at least three distinct problems. Marian, could these be separated and filled separately? Thanks.
This issue has already 20 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=7612
Evaluation: I would like to waive this issue for 6.7, since - There is no resource to work on this issue.
Build: NetBeans IDE Dev (Build 200905051401) VM: Java HotSpot(TM) 64-Bit Server VM, 11.3-b02, Java(TM) SE Runtime Environment, 1.6.0_13-b03 OS: Linux, 2.6.28-11-generic, amd64 User Comments: Stacktrace: java.lang.StackOverflowError at java.util.regex.Pattern$Branch.match(Pattern.java:4110) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) at java.util.regex.Pattern$Loop.match(Pattern.java:4295) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227) at java.util.regex.Pattern$BranchConn.match(Pattern.java:4078) at java.util.regex.Pattern$CharProperty.match(Pattern.java:3345)
Created attachment 81608 [details] stacktrace
Build: NetBeans IDE Dev (Build 200905200201) VM: Java HotSpot(TM) 64-Bit Server VM, 1.6.0_07-b06-57, Java(TM) SE Runtime Environment, 1.6.0_07-b06-153 OS: Mac OS X, 10.5.7, x86_64 User Comments: Opened a Maven POM project with multiple modules Stacktrace: java.lang.StackOverflowError at java.util.regex.Pattern$BranchConn.match(Pattern.java:4078) at java.util.regex.Pattern$CharProperty.match(Pattern.java:3345) at java.util.regex.Pattern$Branch.match(Pattern.java:4114) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) at java.util.regex.Pattern$Loop.match(Pattern.java:4295) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227)
Created attachment 82520 [details] stacktrace
Build: NetBeans IDE Dev (Build 200905270201) VM: Java HotSpot(TM) 64-Bit Server VM, 11.3-b02, Java(TM) SE Runtime Environment, 1.6.0_13-b03 OS: Linux, 2.6.28-11-generic, amd64 User Comments: Stacktrace: java.lang.StackOverflowError at java.util.regex.Pattern$Loop.match(Pattern.java:4275) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227) at java.util.regex.Pattern$BranchConn.match(Pattern.java:4078) at java.util.regex.Pattern$CharProperty.match(Pattern.java:3345) at java.util.regex.Pattern$Branch.match(Pattern.java:4114) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168)
Created attachment 82888 [details] stacktrace
Just after submitting my report, i went ahead and fixed my pom.xml files in my checkout, which i was suspecting causing the issue. By fixing pom.xml's in my Maven check out fixed it: i no longer get a stack overflow error.
Build: NetBeans IDE 6.7 (Build 200906241340) VM: Java HotSpot(TM) 64-Bit Server VM, 11.3-b02, Java(TM) SE Runtime Environment, 1.6.0_13-b03 OS: Linux, 2.6.28-13-generic, amd64 User Comments: Stacktrace: java.lang.StackOverflowError at java.util.regex.Pattern$BranchConn.match(Pattern.java:4078) at java.util.regex.Pattern$CharProperty.match(Pattern.java:3345) at java.util.regex.Pattern$Branch.match(Pattern.java:4114) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) at java.util.regex.Pattern$Loop.match(Pattern.java:4295) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227)
Created attachment 84492 [details] stacktrace
This issue was originally marked as duplicate of issue 111722, that is already resolved. This issue is still valid, so this seems to be another issue, but it might be related. Build: NetBeans IDE 6.5.1 (Build 200903060201) VM: Java HotSpot(TM) Client VM, 14.0-b16, Java(TM) SE Runtime Environment, 1.6.0_14-b08 OS: Windows XP, 5.1, x86 User Comments: buld project Stacktrace: java.lang.StackOverflowError<br/> at java.util.regex.Pattern$8.isSatisfiedBy(Pattern.java:4783)<br/> at java.util.regex.Pattern$8.isSatisfiedBy(Pattern.java:4783)<br/> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3345)<br/> at java.util.regex.Pattern$Curly.match0(Pattern.java:3760)<br/> at java.util.regex.Pattern$Curly.match(Pattern.java:3744)<br/> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3345)<br/>
Created attachment 84944 [details] stacktrace
This issue was originally marked as duplicate of issue 111722, that is already resolved. This issue is still valid, so this seems to be another issue, but it might be related. Build: NetBeans IDE 6.5.1 (Build 200903060201) VM: Java HotSpot(TM) Client VM, 14.0-b16, Java(TM) SE Runtime Environment, 1.6.0_14-b08 OS: Windows XP, 5.1, x86 User Comments: open project Stacktrace: java.lang.StackOverflowError<br/> at java.lang.Character.toLowerCase(Character.java:4175)<br/> at java.lang.String.toLowerCase(String.java:2408)<br/> at java.io.Win32FileSystem.hashCode(Win32FileSystem.java:581)<br/> at java.io.File.hashCode(File.java:1891)<br/> at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.createID(NamingFactory.java:172)<br/> at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectFactory.getCachedOnly(FileObjectFactory.java:545)<br/>
Created attachment 84973 [details] stacktrace
Looking at REST area (EntityResourceModelBuilder). The other web service cases related to JaxWsClasspathProvider/JaxWsSourceForBionaryQuery were fixed. (classes were completely removed). However, from the 6.7 stack traces it's obvious the problem is related either to creating project group or to opening maven project(s).
The REST issue with EntityResourceModelBuilder, and org.netbeans.modules.websvc.rest.wizard.Util was fixed already. See: http://hg.netbeans.org/main/rev/b9058b0f17b2 Reassigning to project category, as the last 6.7 stack traces are related to "project open" and project group creation, or may be something wrong with Maven project?
massimo: can you please provide more comments what changes in pom.xml caused the exception to stop appearing? Without additional information (steps to reproduce and/or a sample project) I'm not able to proceed. The remaining stacktraces show just java.util.regexp methods, thus provide no information at all, closing as IBVALID, please reopen with more details..
Do not remember what was wrong in that pom, i should have thought of that and report it. Will reopen this issue if it happens to me again, will keep that in mind, sorry about that, cannot reopen now.
This is from my IDE log file after opening a Maven project (first few lines of stacktrace only): WARNING [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater] java.lang.StackOverflowError at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) at java.util.regex.Pattern$Loop.match(Pattern.java:4295) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227) at java.util.regex.Pattern$BranchConn.match(Pattern.java:4078) at java.util.regex.Pattern$CharProperty.match(Pattern.java:3345) at java.util.regex.Pattern$Branch.match(Pattern.java:4114) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168) I don't think there's anything wrong with the POM (reverting to previous versions - where it still worked - doesn't fix the problem). However, it must have something to do with this specific project, as it fails consistently (and not my other projects). But there's no way of knowing where to look for errors. I should add that all the problems started after adding Maven profiles. Netbeans seems to remember the profiles even after removing them from my settings.xml, profiles.xml and pom.xml files (I created some tests to figure out where the best location would be). So my uninformed/humble guess is that the POM is fine, but that Netbeans somewhere stores meta info that breaks the project loading/parsing?? Sorry for reopening, I wasn't sure if you'd be notified of this comment otherwise. Please mark as INVALID again if this additional info isn't helpful.
I have now discovered that the problem lies with these few lines in my pom: <dependency> <groupId>it.tidalwave.betterbeansbinding</groupId> <artifactId>betterbeansbinding-swingbinding</artifactId> <version>1.3.0</version> </dependency> When I remove it, the exception goes away on project opening. When I put it back, no matter where in the pom, the exception comes back. I can reproduce this always on Vista 32, NB 6.7. The project is however able to execute and the jar is found from the central repo. Any ideas? The other BBB dependency works fine: <dependency> <groupId>it.tidalwave.betterbeansbinding</groupId> <artifactId>betterbeansbinding-core</artifactId> <version>1.3.0</version> </dependency> A bug with beansbinding instead? Please ignore my earlier post. This has nothing to do with profiles etc.
Yes, I'm able to reproduce too, consistently on Ubuntu 9.04, JDK 1.6.0_14, exactly as danie wrote: 1) Take Maven project, add to its pom: <dependency> <groupId>it.tidalwave.betterbeansbinding</groupId> <artifactId>betterbeansbinding-swingbinding</artifactId> <version>1.3.0</version> </dependency> 2) close project, then open it again --> Regexp blew, and from this time in a session it remains corrupted. Bad thing is that this is 99% probability error on JDK side in Regexp, where some special input breaks it. We should isolate input somehow and ideally write small test case in order to be able to file JDK bug (if my assumptions are right)
I think I've found it. StackOFlow comes from JavadocAndSourceRootDetection, full stack is as follows: org.netbeans.spi.java.project.support.JavadocAndSourceRootDetection.findJavaPackage(JavadocAndSourceRootDetection.java:196) org.netbeans.spi.java.project.support.JavadocAndSourceRootDetection.findPackageRoot(JavadocAndSourceRootDetection.java:115) org.netbeans.spi.java.project.support.JavadocAndSourceRootDetection.findSourceRoot(JavadocAndSourceRootDetection.java:102) org.netbeans.modules.maven.queries.RepositorySourceForBinaryQueryImpl$SrcResult.checkPath(RepositorySourceForBinaryQueryImpl.java:161) org.netbeans.modules.maven.queries.RepositorySourceForBinaryQueryImpl$SrcResult.getRoots(RepositorySourceForBinaryQueryImpl.java:143) org.netbeans.modules.java.queries.SFBQImpl2Result.preferSources(SFBQImpl2Result.java:63) org.netbeans.api.java.queries.SourceForBinaryQuery$Result2.preferSources(SourceForBinaryQuery.java:229) org.netbeans.modules.parsing.impl.indexing.PathRegistry.createResources(PathRegistry.java:593) org.netbeans.modules.parsing.impl.indexing.PathRegistry.getSources(PathRegistry.java:213) org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:2350) org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$InitialRootsWork.getDone(RepositoryUpdater.java:2748) org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:1693) org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:3039) org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.run(RepositoryUpdater.java:2981) org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:574) java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) java.util.concurrent.FutureTask.run(FutureTask.java:138) java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) java.lang.Thread.run(Thread.java:619) ---- On mentioned line, Matcher is constructed to find package definition inside java source file (specifically this file in our reproduction case: http://kenai.com/projects/betterbeansbinding/sources/src/content/SwingBinding/src/main/java/org/jdesktop/swingbinding/JListBinding.java?rev=137) and fails on StackOverflow. It looks like JDK failure, we can probably isolate test case now - on the other hand we are feeding Matcher with whole java source file (here 21600 bytes only though) and rather complex match Pattern, see JavadocAndSourceRootDetection.findJavaPackage source. Maybe we can workaround this by separating into several patterns, but I'm no expert at Regular Expressions so I don't know.
I found relationship to issue 124779, where detecting of package name was implemented using regular expressions, Jesse's hint. I'm ccing jglick and dkonecny - guys do you have some idea how this can be workarounded? (please read my last post, which hopefully describes our situation well).
I filed bug to JDK team, should be online in few days at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6882582. Meanwhile I'm attaching simple small nb project that demonstrates the problem with regexp Matcher. However, what remains is a question if and how we can workaround this?
Created attachment 87777 [details] Nb project demonstrating regex Matcher error on specific input and pattern
Note that I'm trying to solve only one specific Matcher failure - this issue in fact contains traces of various different failures, which we are not able to fix, as they are not reproducible. Only thanks to danie's reproduction steps we could succeed in this specific case which touches maven.
Not sure offhand why there would be a matcher overflow here; should match the package decl and complete. Perhaps the long line of asterisks is confusing it? Agreed that root problem is probably a JDK issue; the regexp engine should not use stack recursion as the stack usage can be proportional to input size.
I am already working on a test, so I will just take this over.
OK, my wild guess for workaround was to read the file line by line and perform just quick matching to "packageSentence" for first say 200 lines of code and only if this fails then fall back to current solution. I wonder what your fix will be - perhaps pattern changed somehow?
http://ostermiller.org/findcomment.html was helpful. core-main #70c66fa25606 seems to do it. I cannot reproduce using the Maven project, or inside a unit test, only using MatcherStackOverflow.zip, so independent verification would be highly appreciated.
*** Issue 172435 has been marked as a duplicate of this issue. ***
there's another exception report in #172435 coming from the build which already contains this fix (unless i'm reading mercurial logs wrong)
The fix is not yet in any production build, so that seems unlikely. Issue #172435 links to http://statistics.netbeans.org/exceptions/detail.do?id=158646 which includes no information (???) but the last report I see is http://statistics.netbeans.org/exceptions/exception.do?id=263224 which says it is from 4434e4114f37. You can see for yourself that this does not contain the fix: main$ hg debuganc 4434e4114f37 70c66fa25606 145671:2a7b4afdcf9e5d81ab268dcc697ba3271fc4c024 Anyway a SOE in regexp matching is not automatically a duplicate of this issue; plenty of code uses regexps, so you need to see the top of the stack.
I can confirm that the case for which user danie gave reproducible set of steps is fixed, I can't reproduce anymore. For other cases I'm not sure, theoretically it's possible to fall into this trap anywhere when using regexp on big input AFAIK. Let's see what JDK team will have to say.
Well it is certainly not hard to make a poorly conceived regexp spin into a near-endless search - that is unavoidable. But you might expect that this would simply consume a lot of CPU and a bit of heap, not result in a stack overflow. If you run with -Xmss64m or similar you will likely see better behavior, but I think we run with 2m by default.
Integrated into 'main-golden', will be available in build *200909181401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/70c66fa25606 User: Jesse Glick <jglick@netbeans.org> Log: #154894: stack overflow matching comments.
*** Issue 170012 has been marked as a duplicate of this issue. ***
Would be trivial to backport. (Patch depends on, and partly supersedes, b9883f324499.)
*** Issue 166281 has been marked as a duplicate of this issue. ***
Created attachment 90030 [details] Source patch for 6.7
Created attachment 90031 [details] Binary patch for 6.7
*** Issue 164207 has been marked as a duplicate of this issue. ***
Regarding the attached binary patch, a user writes: "Seems to solve the issue. Since installing I've not discovered any of these exceptions. However, I cannot verify the patch in general, but I can say that I was able to consistently reproduce the exception before the patch. I didn't see any new eceptions comming from the patch either."
*** Issue 164549 has been marked as a duplicate of this issue. ***
*** Issue 167882 has been marked as a duplicate of this issue. ***
*** Bug 170026 has been marked as a duplicate of this bug. ***