Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 328347 - Synchronizer does not release locks when released from Display.dispose()
Summary: Synchronizer does not release locks when released from Display.dispose()
Status: RESOLVED DUPLICATE of bug 352437
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: 1.4   Edit
Hardware: All All
: P2 critical (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-21 09:28 EDT by Cole Markham CLA
Modified: 2012-09-12 05:03 EDT (History)
0 users

See Also:

Attachments
Patch that implements Cole's solution (12.68 KB, patch)
2010-10-22 14:51 EDT, Austin Riddle CLA 		no flags Details | Diff
Patch that implements Cole's solution preventing null pointer (12.68 KB, patch)
2010-10-22 15:49 EDT, Austin Riddle CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Cole Markham CLA 2010-10-21 09:28:36 EDT 
We are running into some single-sourcing issues with legacy code that calls Display.syncExec from a shared background thread. If one of the displays has not yet been disposed but the browser client is no longer connected (e.g., user closed browser) then the syncExec will be queued on that display and the background thread blocked indefinitely (waiting on the RunnableLock in Synchronizer.syncExec, line 194). Currently the only way this lock will be released is if the runnable is executed in Synchronizer.runAsyncMessages, which will never happen if the client is dead even if the display gets disposed. It seems like Synchronizer.releaseSynchronizer should iterate over the messages array and cleanup each of the RunnableLocks. It would have to null out the runnable and/or set a throwable in the RunnableLock so that done() will return true (or extend to have a cancel), then call notify on it to resume the waiting thread.

I will work on getting a demo project to reproduce and a patch for my proposed fix. My assumption is that this could affect SWT as well since I believe the Synchronizer is a direct copy. However it would be rare or even impossible in practice for SWT because there is no period of uncertainty where the display is defunct but not disposed.
Comment 1 Austin Riddle CLA 2010-10-22 14:51:36 EDT 
Created attachment 181530 [details]
Patch that implements Cole's solution
Comment 2 Austin Riddle CLA 2010-10-22 15:49:46 EDT 
Created attachment 181547 [details]
Patch that implements Cole's solution preventing null pointer
Comment 3 Ivan Furnadjiev CLA 2012-05-23 07:19:27 EDT 
(In reply to comment #0)
> I will work on getting a demo project to reproduce and a patch for my proposed
> fix.
Sorry for the very late response, Austin. Cole, did you create a demo project that demonstrate the issue? It will help us to track the issue down and better understand your patch. Could you update the patch to the latest Git master (please ensure that the patch includes only the related changes, use Unix line breaks)? Could you create a JUint test case and include it in the patch too? Thanks
Comment 4 Ralf Sternberg CLA 2012-09-12 05:03:04 EDT 
This issue has already been resolved in bug 352437.

*** This bug has been marked as a duplicate of bug 352437 ***