Community
Participate
Working Groups
Build Identifier: I20090611-1540 First, I want to apologize for waiting so long to report this issue. We have a custom editor that, for some reason, some files are opened and we get a Stack Overflow. Some times it isn't "opening" that triggers it but a mild mutation or even a navigation. I don't think our partitioner is quite that complicated to be honest but I just don't know how to proceed. Additionally because of the repeatability factor I don't know that using Eclipse 3.6M7 will address the issue. At the very least, since I have a stack trace, I'll include it here. java.lang.StackOverflowError at org.eclipse.jface.text.AbstractDocument.computeIndexInPositionList(AbstractDocument.java:480) at org.eclipse.jface.text.AbstractDocument.computeIndexInPositionList(AbstractDocument.java:453) at org.eclipse.jface.text.AbstractDocument.computeIndexInCategory(AbstractDocument.java:542) at org.eclipse.jface.text.rules.FastPartitioner.getPartition(FastPartitioner.java:484) at org.eclipse.jface.text.rules.FastPartitioner.getPartition(FastPartitioner.java:592) at org.eclipse.jface.text.AbstractDocument.getPartition(AbstractDocument.java:1453) at org.eclipse.jface.text.TextUtilities.getPartition(TextUtilities.java:401) at org.eclipse.jface.text.source.DefaultCharacterPairMatcher$DocumentPartitionAccessor.getPartition(DefaultCharacterPairMatcher.java:255) at org.eclipse.jface.text.source.DefaultCharacterPairMatcher$DocumentPartitionAccessor.getNextPosition(DefaultCharacterPairMatcher.java:223) at org.eclipse.jface.text.source.DefaultCharacterPairMatcher.findMatchingPeer(DefaultCharacterPairMatcher.java:132) at org.eclipse.jface.text.source.DefaultCharacterPairMatcher.findMatchingPeer(DefaultCharacterPairMatcher.java:128) at org.eclipse.jface.text.source.DefaultCharacterPairMatcher.findMatchingPeer(DefaultCharacterPairMatcher.java:128) Reproducible: Sometimes Steps to Reproduce: Open a file of our own custom editor. Because it's not too common, it's difficult to identify what values are causing the infinite recursion. This is actually a pretty bad issue though, as you can imagine - it kills the workbench.
Robert, you can imagine it's even harder for us to track this down and we've never heard of this so far i.e. there's not much I can/will do unless we have more information. From what you've posted in comment 0 one cannot see any recursion - please attach the full thread dump. Since you say your partitioner is quite complicated it could also be that the thread stack size of your VM is just too small for it. Try to increase it (-Xss, e.g. -Xss10M). Does that help?
You do deserve a full stack trace, but really, it's big. I included it below and truncated. Not very from what I sent you earlier. Regarding -Xss I don't see us setting it now. I can recommend it, but I wonder if this new stack trace gives you a different idea. Also to correct something: I didn't say my partitioner was quite complicated, I was it was not. But I can see the misunderstanding. I'm just glad you jumped on this so quickly, thank you. In the meantime I will actively do some more searching. !ENTRY org.eclipse.ui 4 0 2010-01-21 21:14:22.025 !MESSAGE Error occurred during status handling !STACK 0 java.lang.StackOverflowError at org.eclipse.jface.text.AbstractDocument.computeIndexInCategory(AbstractDocument.java:535) at org.eclipse.jface.text.rules.FastPartitioner.getPartition(FastPartitioner.java:484) at org.eclipse.jface.text.rules.FastPartitioner.getPartition(FastPartitioner.java:592) at org.eclipse.jface.text.AbstractDocument.getPartition(AbstractDocument.java:1461) at org.eclipse.jface.text.TextUtilities.getPartition(TextUtilities.java:401) at org.eclipse.jface.text.source.DefaultCharacterPairMatcher$DocumentPartitionAccessor.getPartition(DefaultCharacterPairMatcher.java:254) at org.eclipse.jface.text.source.DefaultCharacterPairMatcher$DocumentPartitionAccessor.getNextPosition(DefaultCharacterPairMatcher.java:222) at org.eclipse.jface.text.source.DefaultCharacterPairMatcher.findMatchingPeer(DefaultCharacterPairMatcher.java:128) ... Repeat 816 more times in between. at org.eclipse.jface.text.source.DefaultCharacterPairMatcher.findMatchingPeer(DefaultCharacterPairMatcher.java:128)
>You do deserve a full stack trace, but really, it's big. I included it below >and truncated. Not very from what I sent you earlier. If it repeats 816 times findMatchingPeer(...) and then goes on as shown in the stack trace, then it's not a loop but really an issue with the stack size. Hence I'd try this first. Another thing you can do is to connect another Eclipse instance to your dev workspace and set a breakpoint into findMatchingPeer(line 128) which is only triggered if the count is e.g. > 500.
I like both suggestions, and will try them ASAP.
Huzzah! I found the root of the problem!! My call to the DefaultCharacterPairMatcher constructor provided a char array that DID NOT respect the open/close/open/close ordering. Instead, it actually did open/open/open/open/close/close/close/close. So instead of ""''{}() it was "'{("'}). So you know, increasing the stack size also worked, but this solution is muuuch better. I'm curious as to why this resulted in a stack overflow. Any thoughts? Thanks for your help.
Glad you found it. >I'm curious as to why this resulted in a stack overflow. Any thoughts? Because the stack got too deep and ran out of memory. That's why increasing the size also helped: with a bigger stack the the matcher was able to do the job and returned reaching the memory limit and hence no StackOverflowError.
No, of course I get that, perhaps I didn't explain my question correctly. Why would a reordering like that result in a deeper stack?
>Why would a reordering like that result in a deeper stack? Because it will less likely find a match but rather another instance of the start character which will cause nesting and hence recursive calls to findMatchingPeer(*).
