Community
Participate
Working Groups
Build ID: M20060921-0945 Steps To Reproduce: Sadly, I can reproduce this with my app, but I can't share it. The situation is that, when debugging, my app logs lots of XMLish data to standard out. The amount of data sent over several seconds is about 2700000 bytes. What happens is that both Eclipse and the debugged app are non-responsive for 15-20 minutes. The machine is using a lot of CPU, but all other applications are responsive. If I remove the console and send the output to log file, there is no sluggishness. More information: What appears to be happening is that ConsolePatternMatcher$MatchJob is thrashing somehow while trying to process the console data. I have my console at the default limit of 80000 characters. The line that seems to be taking a long time to run is: if (reg.find(startOfNextSearch)) { //this is ConsolePatternMatcher:123) startOfNextSearch=4611 lengthToSearch=164830 The text is 164830 characters long The pattern it appears to be looking for is \w[^\(\s]+Exception[\s|:] I don't believe I have any exceptions in the output stream. The text data does appear to have a line that is 132000 characters long and has the word "Exceptions" in it. The overall output has multiple lines that are very long. When this happens, I can use the pause button to stop the debugger. It appears that a single invocation of the match routine takes a very long time. I have tried creating a simple program that spits out the same xml data (but not necessarily in the same chunks), but I don't experience the same large delays; I do see some slowness as it appears that the pattern matcher (when the timing of the output happens to invoke it) is much slower than the quick matcher. I'm not sure if this is a jdk issue or not. If so, it might be mitigated by not parsing the console until after a quiet period so that it doesn't thrash so much.
Nothing planned for 3.3
Seeing the same again and again, for me it really kills Eclipse as it never finishes (at least as long as I have patience) and fully blocks Eclipse, stack trace shows the following as the only thing being active: "Worker-500" prio=6 tid=0x0000000010b61800 nid=0x11b0 runnable [0x00000000260cf000] java.lang.Thread.State: RUNNABLE at java.util.regex.Pattern$Curly.match0(Pattern.java:3770) at java.util.regex.Pattern$Curly.match(Pattern.java:3744) at java.util.regex.Pattern$Start.match(Pattern.java:3055) at java.util.regex.Matcher.search(Matcher.java:1105) at java.util.regex.Matcher.find(Matcher.java:561) at org.eclipse.ui.internal.console.ConsolePatternMatcher$MatchJob.run(ConsolePatternMatcher.java:127) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Created attachment 179366 [details] text that hangs eclipse
As this bugs me repeatedly, I invested some time and have now narrowed it down to the attached text and the following regular expression: "\S+\.(vm|vsl|vtl|html|xml)\[.+,.+\]". If you run the regex against this text, a normal Java Regular Expression utility will never finish, as does Eclipse when it tries to execute it on the Console output. I could however not find out which component adds this regular expression in the first place...
I found that the regular expression in my case is added by the veloeclipse plugin, see http://code.google.com/p/veloeclipse/issues/detail?id=32, but I still think that Eclipse should not hang, but allow me to stop the operation.
Note that the org.eclipse.ui.console.consolePatternMatchListeners extension point allows for contributers to use enablement expressions to control what type of consoles the pattern matcher is contributed to. For example, JDT contribtues pattern matchers for stack traces to Java-related consoles: <consolePatternMatchListener class="org.eclipse.jdt.internal.debug.ui.console.JavaConsoleTracker" regex="\(\S*${java_extensions_regex}\S*\)" qualifier="${java_extensions_regex}" id="org.eclipse.jdt.debug.ui.JavaConsoleTracker"> <enablement> <or> <test property="org.eclipse.ui.console.consoleTypeTest" value="javaStackTraceConsole"/> <test property="org.eclipse.debug.ui.processTypeTest" value="java"/> <test property="org.eclipse.debug.ui.processTypeTest" value="org.eclipse.ant.ui.antProcess"/> </or> </enablement> Perhaps the problematic extension needs to use an enablement expression to avoid it's use in consoles that it does not pertain to?
(In reply to comment #2) > Looks like a dupe of bug 175888. Probably. (In reply to comments to Bug 342269 - Eclipse hangs in java.util.regex.Matcher.find() for some output in the Console) > Aaron, what kind of console is the output going to (stacktrace, I/O, etc)? Are > you outputting a lot of data to the console? Or really long lines of data? All of the above :-) When you look for stack traces, instead of looking for Exceptions, look for this really simple pattern: "\n\tat " This is extremely rare to find outside of a stack trace and you can then work backwards. The big advantage of the pattern is that you don't even need regexp; you can search promising parts with indexOf() and *then* apply the regexp to the start of the line directly above it. This way, you only need to match a few characters. > > Now my problem is: How can I find out *which* regexp causes this? > > I guess your best bet would be to profile it. In which plugin can I find the ConsolePatternMatcher? I'd patch the plugin to wrap the code in a little piece of timer code and then log a message if a timeout occurs. If you'd be willing to accept a patch, I'd be willing to spend some time on it. > > Also: Why is this locking up the UI? Can't the partitioning of the console > > content happen in the background? > > The matching, etc. is done in the background, but in certain cases - writing > out large lines of text to the UI widgetry for example - can cause Eclipse to > bog right down. If you look at the log, it joins on the background jobs. Is that a smart thing to do in the UI thread? Wouldn't it be better to run the join in another background thread and then use Display.asyncExec() to display the results?
*** Bug 342269 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > All of the above :-) When you look for stack traces, instead of looking for > Exceptions, look for this really simple pattern: "\n\tat " > > This is extremely rare to find outside of a stack trace and you can then work > backwards. The big advantage of the pattern is that you don't even need regexp; > you can search promising parts with indexOf() and *then* apply the regexp to > the start of the line directly above it. > > This way, you only need to match a few characters. > That sounds like a pretty good idea. > > In which plugin can I find the ConsolePatternMatcher? org.eclipse.ui.console > If you'd be willing to accept a patch, I'd be willing to spend some time on > it. > Patches are always welcome around here :) > If you look at the log, it joins on the background jobs. Is that a smart thing > to do in the UI thread? Wouldn't it be better to run the join in another > background thread and then use Display.asyncExec() to display the results? That would be worth investigating. To be honest I don't recall the design rational for joining like that, perhaps Darin W has some more insight.
(In reply to comment #9) In which plugin is the extension that installs the matcher for stack traces? > > If you'd be willing to accept a patch, I'd be willing to spend some time on > > it. > > Patches are always welcome around here :) You haven't seen it, yet :-) Okay, I managed to make the changes and add some test cases. One issue remains: How do I find out which plugin contributed the broken pattern? All I have is an IConfigurationElement. How do I turn that into something the user can use in a bug report? In which plugin is the extension that installs the matcher for stack traces?
Created attachment 193075 [details] First attempt to patch the issue Some things to note: I'm a TDD guy which is why there is suddenly a dependency to JUnit and some test cases. You will probably want to move them to a different test plugin. I don't have the unit tests for the console plugin, so that makes it hard for me to do it. Either point me to the place where I can find the unit tests for org.eclipse.ui.console or move the classes there yourself. The patch is against 3.6.2. Please try to apply it against 3.7. If it fails, I'll bite the bullet and try to set up 3.7 here but I'd rather avoid that effort, if possible. Just like with you, I don't have an infinite amount of time :-)
Created attachment 193123 [details] Second version of the patch This is the second version. It will print the name, version and location of the bundle which causes the problem. I'll attach an example error message. Last question on my part: Should I use an error or a warning in the IStatus? Since it locks the UI, I tend towards error. OTOH, it doesn't crash Eclipse, so a warning might be sufficient.
Created attachment 193124 [details] Example log message
> Either point me to the place where I can find the unit tests for > org.eclipse.ui.console or move the classes there yourself. The console tests are located in the org.eclipse.jdt.debug.tests bundle. In there the ConsoleTests class would be a good place to start. > Last question on my part: Should I use an error or a warning in the IStatus? If it is something that causes a problem, we typically use error instead of warning.
> The patch is against 3.6.2. Please try to apply it against 3.7. If it fails, > I'll bite the bullet and try to set up 3.7 here but I'd rather avoid that > effort, if possible. Just like with you, I don't have an infinite amount of > time :-) Looking at the patch I have a few comments: 1. There is an API change that is not needed in PatternMatchEvent 2. I am not sure what the patch 'fixes'. It adds in some nice toStrings and some logging for regex's that take a long time, but I did not see the reduced expression or anything else that would fix this bug. Did I miss something? 3. The tests should be in org.eclipse.jdt.debug.tests with the other console tests (but we already talked about that)
(In reply to comment #14) > > Either point me to the place where I can find the unit tests for > > org.eclipse.ui.console or move the classes there yourself. > > The console tests are located in the org.eclipse.jdt.debug.tests bundle. In > there the ConsoleTests class would be a good place to start. I don't have that bundle. Where can I download it? > > Last question on my part: Should I use an error or a warning in the IStatus? > > If it is something that causes a problem, we typically use error instead of > warning. I'll change it to an error. (In reply to comment #15) > > The patch is against 3.6.2. Please try to apply it against 3.7. If it fails, > > I'll bite the bullet and try to set up 3.7 here but I'd rather avoid that > > effort, if possible. Just like with you, I don't have an infinite amount of > > time :-) > > Looking at the patch I have a few comments: > > 1. There is an API change that is not needed in PatternMatchEvent Without this change, I can't compile the tests since I can't create a TextConsole. > 2. I am not sure what the patch 'fixes'. It adds in some nice toStrings and > some logging for regex's that take a long time, but I did not see the reduced > expression or anything else that would fix this bug. Did I miss something? My patch just makes it possible to find out what is causing the lockups. The users can then post the events from the Error Log as bugzilla reports and we can work on a fix. I've managed to replicate the problem with my change and it's in fact the exception handling code. Looking at the existing code, I'm not sure how much of the API must change to speed up Exception matching. I'll create a test case to demonstrate the problem with the existing API so we can start talking about a solution.
We have also found problems while starting a Tomcat Server in Eclipse (via Server-Plugin). Eclipse freezes for two or three minutes and JProfiler shows heavy CPU consumption in java.util.regex triggered by consolePatternMatchListeners. The problematic logging output is the list of our Spring beans. Spring is logging all configured beans on console (Log level INFO). Because we have a lot of beans, this single logging line has 42000 characters. Of course we can prevent logging this huge list of beans on console as workaround. But these three regular expressions from plugin org.eclipse.jdt.debug.ui \(\S*${java_extensions_regex}\S*\) \(Native Method\) \w[^\(\s]+Exception[\s|:] will cause the problem.
I have this problem in Eclipse Juno SR2. Strangely, I have not experienced in Eclipse Indigo, or it has been "bearable" with Indigo (and I feel with Juno SR1, too). So may this bug with Juno SR2 become worse? What about to make some workaround like a preference setting "Disable regexp on console"?
The bug is triggered by long lines. I.e. not the amount of output is the problem but the length of some lines. I found that lines < 500 characters are usually safe. So a "simple" workaround is to make sure no long lines are written to the console. Maybe write a "truncating" appender for your logging framework that inserts newlines into long lines or truncates them.
What if the regexps would be limited to 500 chars? I.g. instead of \(\S*${java_extensions_regex}\S*\) something like ^.{0,500}\(\S*${java_extensions_regex}\S*\) Or limit the regex search programtically (possibly change max search length by a setting).
*** Bug 438329 has been marked as a duplicate of this bug. ***
I'm seeing the same in Kepler SR1. "Worker-7" - Thread t@47 java.lang.Thread.State: RUNNABLE at java.util.regex.Pattern$Curly.match0(Pattern.java:3770) at java.util.regex.Pattern$Curly.match(Pattern.java:3744) at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3366) at java.util.regex.Pattern$Start.match(Pattern.java:3055) at java.util.regex.Matcher.search(Matcher.java:1105) at java.util.regex.Matcher.find(Matcher.java:561) at org.eclipse.ui.internal.console.ConsolePatternMatcher$MatchJob.run(ConsolePatternMatcher.java:130) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) Locked ownable synchronizers: - None It locks Eclipse up dead indefinitely, not just "delays"
It is not so "simple" to limit output line length when you're working with a library. This issue needs fixing badly.
Still presented in Mars M3. I have been beaten by this bug so many times that I have stopped using eclipse. I try eclipse with every new version but then delete it from my system because I need stability. I mean after 7 years ... jeeez
Workaround: Limit the max. line length in the Debug console in the Eclipse preferences to 500 characters.
Limit output to 500 characters does not work. The eclipse still freezes all the time. And it also triggers yet another bug (sigh): https://bugs.eclipse.org/bugs/show_bug.cgi?id=323306
org.eclipse.jdt.debug.ui_3.7.0.v20150505-1916.jar The problem is that qualifier is too loose: regex="\w[^\(\s]+Exception[\s|:]" qualifier="Exception" If I change "Exception[\s|:]" as qualifier it is so muuuuuuch better. Sample from log that is one lines and contains Exception (as qualifier).
Created attachment 255687 [details] sample_lines_1sec_regex sample lines taken from spring mvc application log. that takes one second to find matches.
I have dug a bit more and found out that the problem is because we are searching for every possible character between char and exception string. This poses a problem in really long log strings. In our problem it is a problem with spring debug log that lists all the initialized beans in an application. In our case with larger application using around 500 beans this amounts to couple of KB long lines. I propose that you change the regular expression for java expression: - regular expression: [\\w.#]+Exception[\\s|: (better to only select what can be qualifier) - flags: 256 ... Pattern.UNICODE_CHARACTER_CLASS (so we match \\w as unicode word character) - qualifier: Exception[\s|:] ... to get rid of more false positives </consolePatternMatchListener> <consolePatternMatchListener class="org.eclipse.jdt.internal.debug.ui.console.JavaExceptionConsoleTracker" regex="[\\w.#]+Exception[\\s|:]" qualifier="Exception[\s|:]" flags="256" id="org.eclipse.jdt.debug.ui.JavaExceptionConsoleTracker"> <enablement> <or> <test property="org.eclipse.ui.console.consoleTypeTest" value="javaStackTraceConsole"/> <test property="org.eclipse.debug.ui.processTypeTest" value="java"/> <test property="org.eclipse.debug.ui.processTypeTest" value="org.eclipse.ant.ui.antProcess"/> </or> </enablement> </consolePatternMatchListener> This should solve all the freezing in console and make Eclipse a lot more responsive.
(In reply to Matej Spiller Muys from comment #29) > In our problem it is a > problem with spring debug log that lists all the initialized beans in an > application. In our case with larger application using around 500 beans this > amounts to couple of KB long lines. Can you append an excerpt of your log to this bug which could be used in a test case? That way, devs can make sure that the expression works for all known cases.
I'm seeing this same problem in Mars.1, and interestingly, because of spring log output as well. I've verified that the changes in comment 29 work for me. Seems like there hasn't been too much movement on this bug - can this be committed soon?
I tried using the regex used in Comment 29 regex="[\\w.#]+Exception[\\s|:]" But after using this in the jdt.debug.ui plugin.xml , the pattern , match not found is not invoked for simple NPE log : Exception in thread "main" java.lang.NullPointerException
Typo -- matchFound (and not match not Found) (In reply to Sarika Sinha from comment #32) > I tried using the regex used in Comment 29 > regex="[\\w.#]+Exception[\\s|:]" > > But after using this in the jdt.debug.ui plugin.xml , the pattern , match > found is not invoked for simple NPE log : > Exception in thread "main" java.lang.NullPointerException
Bump. Any progress?
The regexp should be: regex="[\w.#]+Exception[\s|:]" The double \\ are only used when in java strings, this xml string only needs a single \ , doesn't need to be escaped.
Any update on this issue? It really sad that this issue is opened more than 9 years. And the fix is really simple (at least for limiting the problem). Can this be fixed for NEON? Qualifier should catch more cases before using slow regular expression. Patch: <consolePatternMatchListener class="org.eclipse.jdt.internal.debug.ui.console.JavaExceptionConsoleTracker" regex="\w[^\(\s]+Exception[\s|:]" qualifier="Exception[\s|:]" id="org.eclipse.jdt.debug.ui.JavaExceptionConsoleTracker"> <enablement> <or> <test property="org.eclipse.ui.console.consoleTypeTest" value="javaStackTraceConsole"/> <test property="org.eclipse.debug.ui.processTypeTest" value="java"/> <test property="org.eclipse.debug.ui.processTypeTest" value="org.eclipse.ant.ui.antProcess"/> </or> </enablement> </consolePatternMatchListener> Simple test case: public class Test175888 { public static void main(String[] args) { String repeated = new String(new char[16000]).replace("\0", "X"); /* misspelled exception - very fast output */ for (int i = 0; i<100; i++) { System.out.println(repeated + "Excfption" + ".XXXXX"); } /* the part that freezes eclipse to a crawl */ for (int i = 0; i<100; i++) { System.out.println(repeated + "Exception" + ".XXXXX"); } } }
Any updates? The fix is just waiting to be committed. Are there any JDT committers that can get this pushed in? I'm tempted to just create a JDT feature patch to fix this... CC'ing Daniel Megert, David Williams
(In reply to Min Idzelis from comment #37) > Any updates? The fix is just waiting to be committed. No, it is waiting to be reviewed. I only took a quick look and found an API breakage and a new class Tool which seems not to belong there. > I'm tempted to just create a JDT feature patch to fix this... That would not help much since the console is not in JDT.
(In reply to Dani Megert from comment #38) > (In reply to Min Idzelis from comment #37) > > Any updates? The fix is just waiting to be committed. > > No, it is waiting to be reviewed. I only took a quick look and found an API > breakage and a new class Tool which seems not to belong there. > > > > I'm tempted to just create a JDT feature patch to fix this... > > That would not help much since the console is not in JDT. Patch is not provided in the Attachment, it is a simple change in the jdt.debug.ui plugin.xml <consolePatternMatchListener class="org.eclipse.jdt.internal.debug.ui.console.JavaExceptionConsoleTracker" regex="\w[^\(\s]+Exception[\s|:]" qualifier="Exception[\s|:]" id="org.eclipse.jdt.debug.ui.JavaExceptionConsoleTracker"> <enablement> <or> <test property="org.eclipse.ui.console.consoleTypeTest" value="javaStackTraceConsole"/> <test property="org.eclipse.debug.ui.processTypeTest" value="java"/> <test property="org.eclipse.debug.ui.processTypeTest" value="org.eclipse.ant.ui.antProcess"/> </or> </enablement> </consolePatternMatchListener> Where only the qualifier has changed from "Exception" to "Exception[\s|:]" I was having problem with regex, but now it is looking good after Min provided the clarification.
Created attachment 260915 [details] Qualifier change for JavaExceptionConsoleTracker
(In reply to Sarika Sinha from comment #39) > (In reply to Dani Megert from comment #38) > > (In reply to Min Idzelis from comment #37) > > > Any updates? The fix is just waiting to be committed. > > > > No, it is waiting to be reviewed. I only took a quick look and found an API > > breakage and a new class Tool which seems not to belong there. > > > > > > > I'm tempted to just create a JDT feature patch to fix this... > > > > That would not help much since the console is not in JDT. > > Patch is not provided in the Attachment, it is a simple change in the Sorry, my bad! I simply looked at the closest attached patch, which is not what's proposes as fix. Sarika will bring this to a good end.
New Gerrit change created: https://git.eclipse.org/r/70612
Gerrit change https://git.eclipse.org/r/70612 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=940a6ef8075f5e8b73bdb97440decf6180d6f0f3
9 years such performance problem, a few of my colleagues switched to Idea do to this. And finally 1 line of code has solved the problem. Sarika, you are the hero!
@Min, Please sign the CLA. You deserve the credit.
I might be missing something but why Min? It was my proposed fix from #27 and later #36 that was accepted.
(In reply to Matej Spiller Muys from comment #46) > I might be missing something but why Min? > It was my proposed fix from #27 and later #36 that was accepted. I am really Sorry, as the explanation was given by Min I got confused. Please sign the CLA.
Thank you, no problem. CLA Signed.
(In reply to Matej Spiller Muys from comment #48) > Thank you, no problem. CLA Signed. Thanks, I have marked the changes in the commit. Verified the fix using eclipse-SDK-N20160414-2000.
A big thank you to all involved in getting this fixed. This helps restore my faith in Eclipse ;-)
Err, wait a second. I think you forgot 2 parts: regex="[\w.#]+Exception[\s|:]" flags="256"
This was my attempt at a bit even more restrictive qualifier. But it is not completely correct. For example it is missing $. http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-JavaLetter Another thing is that Unicode for \w is in Java defined as: \w A word character: [\p{Alpha}\p{gc=Mn}\p{gc=Me}\p{gc=Mc}\p{Digit}\p{gc=Pc}] This is beyond me to figure if this is correct. Somebody would need to check the lexer code for Eclipse compiler. Another solution could also be to limit the length of the identifier (however the identifier is defined as unlimited length). However the fastest solution would be to search manually without even using the regex (and its slow backtracking).
(In reply to Matej Spiller Muys from comment #52) > This was my attempt at a bit even more restrictive qualifier. > But it is not completely correct. For example it is missing $. > http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-JavaLetter > > Another thing is that Unicode for \w is in Java defined as: > \w A word character: [\p{Alpha}\p{gc=Mn}\p{gc=Me}\p{gc=Mc}\p{Digit}\p{gc=Pc}] > This is beyond me to figure if this is correct. Somebody would need to check > the lexer code for Eclipse compiler. > > Another solution could also be to limit the length of the identifier > (however the identifier is defined as unlimited length). > > However the fastest solution would be to search manually without even using > the regex (and its slow backtracking). I think we have seen a good improvement with the change in qualifier itself. And as we are not sure about the regex change, IMHO it will be good to do some research in early 4.7 and track in a separate bug.
Bug 492461 created for follow up discussions. Verified using Eclipse SDK Version: Neon (4.6) Build id: I20160425-1300
This is NOT fixed, at least not for all inputs. Try running this program... public class ConsoleTest { public static void main(String[] args) { StringBuilder sb = new StringBuilder(); for (int i = 0; i < 100000; i++) { sb.append('a'); } sb.append(" Exception"); System.out.println(sb.toString()); } }
(In reply to Eric Biggers from comment #55) > This is NOT fixed, at least not for all inputs. Try running this program... > > public class ConsoleTest { > > public static void main(String[] args) { > StringBuilder sb = new StringBuilder(); > for (int i = 0; i < 100000; i++) { > sb.append('a'); > } > sb.append(" Exception"); > System.out.println(sb.toString()); > } > } If you still see this using 4.7 RC1, please add your case to bug 492461.
