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 213291 - Root methods randomly reset
Summary: Root methods randomly reset
Status: RESOLVED FIXED
Alias: None
Product: profiler
Classification: Unclassified
Component: Base (show other bugs)
Version: 7.2
Hardware: All All
: P2 normal (vote)
Assignee: J Bachorik
URL:
Keywords: REGRESSION
Depends on:
Blocks:
 
Reported: 2012-05-31 11:37 UTC by Jiri Sedlacek
Modified: 2012-06-05 06:06 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Debug output (4.06 KB, text/plain)
2012-05-31 14:26 UTC, Jiri Sedlacek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Sedlacek 2012-05-31 11:37:06 UTC
Steps:

 1/ Fresh profiler-main build, clean userdir
 2/ Create AnagramGame, Profile, CPU, Advanced
 3/ Periodically click the customize.../edit... links and close the profiling roots selector using OK button

Randomly the root methods are set/cleared, can be verified using the Advanced button.
Comment 1 Jiri Sedlacek 2012-05-31 14:26:07 UTC
Created attachment 120140 [details]
Debug output
Comment 2 Jiri Sedlacek 2012-05-31 14:26:19 UTC
Likely caused by wrong synchronization in org.netbeans.modules.profiler.selector.ui.RootSelectorTree.

Method setSelection(SourceCodeSelection[]) is called twice when the dialog is opened and each call starts a different thread which invokes applySelection(SourceCodeSelection[]). Based on the actual order of applySelection invocations the selection might be reset.

See the attached debug output showing stack traces for both setSelection invocations and thread names for applySelection invocations.
Comment 3 J Bachorik 2012-06-01 07:00:18 UTC
Actually, the setSelection() method is serialized. Only one thread is manipulating the profiling roots selection at a time - it is enforced by the semaphore used.
The first call to setSelection() method, originating in the setContext() method, uses an empty set of profiling roots as it is called before the tree receives the list of the previously selected profiling roots. The second call is the actual place where the valid profiling roots are set.

The real puzzler is why the order of queueing the setSelection() request is changes - from the debug output it seems that the original call sequence is correct (first called with an empty set then setting the actual profiling roots), the calls are carried on the same thread but the subsequent execution of the SwingWorker does not preserve the "happens-before" predicate - seems like a later call to setSelection() is scheduled to run before the first one. 

It is rather unfortunate that on Linux, JDK 1.6.0_32, 32bit I am not able to reproduce the behaviour at all. I will try to investigate more.
Comment 4 J Bachorik 2012-06-01 11:38:00 UTC
The set of selected profiling roots was not properly synchronized and it may happened that a change made to the set was not visible from a concurrent thread.

Synchronizing properly - http://hg.netbeans.org/profiler-main/rev/d4d98d775df6
Comment 5 Quality Engineering 2012-06-05 06:06:04 UTC
Integrated into 'main-golden', will be available in build *201206050001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/d4d98d775df6
User: Jaroslav Bachorik <yardus@netbeans.org>
Log: #213291: Properly synchronizing the access to the set of selected profiling roots