Community
Participate
Working Groups
Follow up from Bug 17588 @Matej, If you want to take this up, it can be assigned to you!
(In reply to Sarika Sinha from comment #0) > Follow up from Bug 17588 > @Matej, > If you want to take this up, it can be assigned to you! Sorry, from Bug 175888.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Yes this problem still occurs! Key point being huge console output - and/or very very long lines in that output. Was using version 2022-06, and happen to put a detailed tracepoint on `java.security.MessageDigest.update(byte[], int, int)` that dumps the input array both as hex, and printable characters (replacing others with "."). What I have realized was that that function is also used for getting the hash of each class by class loader!! What that meant was that there were lines that were 330K characters long! The pattern matcher then goes to work, and doesn't ever return becoming a runaway thread it seems. I've seen the following in the thread dump when eclipse was using 100% of one of the cores: "Worker-29: Match Job" #158 prio=5 os_prio=0 cpu=25568.56ms elapsed=53.35s tid=0x000000005f80b430 nid=0x1f20 runnable [0x000000007a79e000] java.lang.Thread.State: RUNNABLE at java.util.regex.Pattern$CharPredicate.lambda$negate$3(java.base@16.0.1/Pattern.java:5625) at java.util.regex.Pattern$CharPredicate$$Lambda$19/0x000000001d8cea98.is(java.base@16.0.1/Unknown Source) at java.util.regex.Pattern$CharPropertyGreedy.match(java.base@16.0.1/Pattern.java:4293) at java.util.regex.Pattern$CharProperty.match(java.base@16.0.1/Pattern.java:3943) at java.util.regex.Pattern$StartS.match(java.base@16.0.1/Pattern.java:3653) at java.util.regex.Matcher.search(java.base@16.0.1/Matcher.java:1728) at java.util.regex.Matcher.find(java.base@16.0.1/Matcher.java:772) at org.eclipse.ui.internal.console.ConsolePatternMatcher$MatchJob.run(ConsolePatternMatcher.java:131) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Another dump after restart of the debugged program (note the cpu time!): "Worker-29: Match Job" #158 prio=5 os_prio=0 cpu=342469.00ms elapsed=373.22s tid=0x000000005f80b430 nid=0x1f20 runnable [0x000000007a79e000] java.lang.Thread.State: RUNNABLE at java.util.regex.Pattern$CharPropertyGreedy.match(java.base@16.0.1/Pattern.java:4302) at java.util.regex.Pattern$CharProperty.match(java.base@16.0.1/Pattern.java:3943) [snip] Additional notes: - "Clear console" doesn't work once the job starts running - Even terminating and relaunching (forcing the close of console) doesn't get rid of the CPU consuming thread. Possible enhancements: - Option to disable console pattern matching jobs - Action button to cancel the job (this may be impossible/difficult (?) though, since the JDK function is the one hogging the CPU) ("Progress" view kind of task could have been nice if the "Cancel" does work!) - Some sort of "self destruct/cancel" programmed on the job if the console output is over a certain threshold (this could also be interesting, since it's a moving target).
