Community
Participate
Working Groups
Build ID: 3.5.0 -- current version at CVS This is a code-inspection type of bug report. The code in WorkbenchAdvisor.openWindows uses a local array-variable initDone to signal the main thread that the worker thread is done. But the read and write operations to the initDone array element are not properly synchronized, creating a data race. My suggestion is to use a local holder class with a volatile boolean member.
Created attachment 109768 [details] Patch with the proposed solution
What error can this "data race" produce in a boolean with only 2 threads involved? This seems to me that it will either be true or false ... and the only reader of this variable is in the main thread. PW
(In reply to comment #2) The main thread is not guaranteed to observe the write at the time the worker thread executes Display.wake(). Of course, this is not very serious because the worker thread is already about to die at that time. Unfortunately, now I don't think even introducing volatile will guarantee this. The compiler will still be allowed to reorder the execution so that Display.wake happens before the write. All that is guaranteed is that all the writes lexically preceeding the write to the volatile will be observed at the time the write itself is observed. Still, this piece of code could easily be misunderstood because one is led to believe that the mentioned guarantee holds. In the future something else might be inserted here that is more relevant to program correctness and then the ordering may become a real issue, leading to nondeterministic bugs.
(In reply to comment #2) I checked once again and realized the following: 1. The write to result[0] is not guaranteed to be observed at the time it is read as a return value of openWindows so the method may legally return false even though the worker thread wrote true. The same is true for error[0]. At least these problems are definitely solved by the proposed patch as those writes precede the write to initDone[0]. 2. If initDone[0] is read as false upon display.wake from the worker thread, it returns to sleep and will stay there until the next event, stalling further progress of the init routine for an indeterminate period. So this might after all be a more serious problem than it seemed. Of course, as usual with multithreading issues, all this can be happily ignored because right now "it just works". But it's nice to at least know where the code stands with respect to proper thread synchronization.
Prakash is now responsible for watching bugs in the [WorkbenchLauncher] component area.
Created attachment 255599 [details] Suspended JVM after application hangs
Hello, are there any plans to address this issue? It appears that our product that is based on Eclipse, runs into this on HP-UX(this is the only OS where this issue has been reported to occur so far). Connecting to the JVM with a debugger and suspending the JVM when our application hangs, the debugger shows that the main thread sleeps at line: "WorkbenchAdvisor.openWindows() line: 806" (see attached image "WorkbenchAdvisor.openWindows()") This is reproducible on HP-UX about 40% of the time. Here is the whole main thread stack trace: Java HotSpot(TM) Server VM[<machine_name>:8000] (Suspended) Daemon Thread [Bundle File Closer] (Suspended) Daemon Thread [[ThreadPool Manager] - Idle Thread] (Suspended) Daemon Thread [[Timer] - Main Queue Handler] (Suspended) Thread [Worker-JM] (Suspended) Daemon Thread [Framework Event Dispatcher] (Suspended) Daemon Thread [Start Level Event Dispatcher] (Suspended) Daemon Thread [State Data Manager] (Suspended) Thread [Framework Active Thread] (Suspended) Daemon System Thread [Signal Dispatcher] (Suspended) Daemon System Thread [Finalizer] (Suspended) Daemon System Thread [Reference Handler] (Suspended) Thread [main] (Suspended) OS.Call(int, int, int, int) line: not available [native method] Display.sleep() line: 4061 AgentUIWorkbenchAdvisor(WorkbenchAdvisor).openWindows() line: 806 Workbench$23.runWithException() line: 1493 Workbench$23(StartupThreading$StartupRunnable).run() line: 31 UISynchronizer(Synchronizer).syncExec(Runnable) line: 180 UISynchronizer.syncExec(Runnable) line: 150 Display.syncExec(Runnable) line: 4316 StartupThreading.runWithoutExceptions(StartupThreading$StartupRunnable) line: 94 Workbench.init() line: 1486 Workbench.runUI() line: 2587 Workbench.access$7(Workbench) line: 2476 Workbench$5.run() line: 593 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 550 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 AgentUIApplication.launch(IApplicationContext, String[]) line: 387 AgentUIApplication.start(IApplicationContext) line: 87 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 353 EclipseStarter.run(String[], Runnable) line: 180 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 57 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 606 Main.invokeFramework(String[], URL[]) line: 629 Main.basicRun(String[]) line: 584 Main.run(String[]) line: 1438 Main.main(String[]) line: 1414
Wouldn't using an AtomicBoolean might be a better solution?
(In reply to Brian de Alwis from comment #8) > Wouldn't using an AtomicBoolean might be a better solution? It would. But anyone would be able to understand the code in that case :)
Mass move to 4.7 as M7 is approaching. Please move back in case you are planning to fix it for Neon.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
