Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 328347

Summary:

Synchronizer does not release locks when released from Display.dispose()

Product:

[RT] RAP

Reporter:

Cole Markham <cole>

Component:

RWT

Assignee:

Project Inbox <rap-inbox>

Status:

RESOLVED DUPLICATE

QA Contact:

Severity:

critical

Priority:

Version:

1.4

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Patch that implements Cole's solution	none
Patch that implements Cole's solution preventing null pointer	none

Description Cole Markham

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

2010-10-22 14:51:36 EDT

Created attachment 181530 [details]
Patch that implements Cole's solution

Comment 2 Austin Riddle

2010-10-22 15:49:46 EDT

Created attachment 181547 [details]
Patch that implements Cole's solution preventing null pointer

Comment 3 Ivan Furnadjiev

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

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 ***