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.

Bug 175990 - "Hinting" exception reporter's stack similarity algorithm
Summary: "Hinting" exception reporter's stack similarity algorithm
Status: NEW
Alias: None
Product: ide
Classification: Unclassified
Component: Exceptions Reporter (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Hurka
Keywords: API
Depends on:
Reported: 2009-11-04 08:21 UTC by Jindrich Sedek
Modified: 2015-07-10 15:46 UTC (History)
3 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jindrich Sedek 2009-11-04 08:21:01 UTC
See Jesse's mail:
We have persistent problems with issues such as

which involve an exception being thrown from the same piece of code but for different reasons each time. Often this is 
an IAE or ISE; the code throwing the exception is behaving as designed, it is some caller higher up in the call stack 
which is doing something wrong.

If the caller is pretty close to the thrower, then the exception reporter's stack trace similarity algorithm decides 
that two stack traces from different callers are indeed distinct, and files separate issues for them - which is good, 
since they get tracked independently and reopened only if they really should be.

But if the caller is deeper in the stack trace, all the stack traces look the same for the first few lines and get 
grouped together. Then we go into the exercise of trying to pick out which ones belong to whom, reassigning the issue 
to different people at different times, the issue gets reopened assigned to person #13 when the problem is really a 
distinct issue that should be assigned to person #14, some less usual stack traces get ignored, etc. - a mess.

Tuning the similarity algorithm to require more lines of similarity would help this problem, but would result in too 
many unclassified duplicates from cases where the immediate code really is at fault - e.g. an NPE - just being called 
in slightly different, and insignificant, ways.

Can the throwing code somehow "hint" the stack trace so that the server knows which parts of the lower stack trace are 
expected to be common to all occurrences? For example, in the issue I mentioned, perhaps the throwing code can be 
amended to read something like this:

throw new IllegalStateException("Should not acquire Children.MUTEX while holding ProjectManager.mutex()\n[EXCUSE 
org.openide.util.Mutex org.openide.nodes.*]");

The specially formatted line in the message would let the server know that before applying its usual algorithm, it 
should first trim off any lines from the bottom of the stack trace (i.e. first lines when printed) matching those 
patterns. Then it would get a collection of traces which either look like

java.lang.IllegalStateException: Should not acquire Children.MUTEX while holding ProjectManager.mutex()
        at org.netbeans.modules.cnd.makeproject.ui.MakeLogicalViewProvider$BaseMakeViewChildren.stateChanged
        at org.netbeans.modules.cnd.makeproject.api.configurations.Folder.fireChangeEvent(
        at org.netbeans.modules.cnd.makeproject.api.configurations.Folder.fireChangeEvent(
        at org.netbeans.modules.cnd.makeproject.api.configurations.Folder.addElement(


java.lang.IllegalStateException: Should not acquire Children.MUTEX while holding ProjectManager.mutex()
        at sun.reflect.GeneratedMethodAccessor60.invoke(
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
Comment 1 Jesse Glick 2009-11-04 15:16:43 UTC
A method call to associate hints with the exception would also be fine; say, something like

IllegalStateException x = new IllegalStateException("Should not acquire Children.MUTEX while holding
Exceptions.ignoreProximateCallers(x, "org.openide.util.Mutex", "org.openide.nodes.*");
throw x;

I'm not sure what the hypothetical ignoreProximateCallers method would do; perhaps work similarly to attachMessage but
with a different kind of LogRecord, one which TopLogging would probably suppress but which the exception reporter would
send in a special field to the server.
Comment 2 Marian Mirilovic 2009-11-07 11:28:50 UTC