28.86 KB, application/octet-stream
79.29 KB, patch
|Details | Diff | Splinter Review|
tar.gz of fix for this bug, first iteration. Untar onto 11/1/00 webclient tree, in the webclient directory.
24.38 KB, application/octet-stream
Webclient bookmarks don't work with tip.
Status: NEW → ASSIGNED
After looking at this long and hard, I have determined that I need some JDK person to help me. I think it's thread related.
Created attachment 18474 [details] [diff] [review] cvs diff -u of fix for this bug, first iteration.
Created attachment 18475 [details] tar.gz of fix for this bug, first iteration. Untar onto 11/1/00 webclient tree, in the webclient directory.
This fix makes it so bookmarks work with the tip of the branch as of 11/01/00. This fix removes the necessity to modify xpcom/base/nsDebug.cpp to remove the thread safety assertions. This fix primarily does two things: 1. Make nsActionEvents for all bookmarks/rdf actions 2. Remove the synchronized(this.browserControlCanvas.getTreeLock()) call around nativeProcessEvents() in NativeEventThread.run(). Files in this fix: M classes_spec/org/mozilla/webclient/test/EMWindow.java M classes_spec/org/mozilla/webclient/wrapper_native/BookmarkEntryImpl.java M classes_spec/org/mozilla/webclient/wrapper_native/BookmarksImpl.java M classes_spec/org/mozilla/webclient/wrapper_native/NativeEventThread.java M classes_spec/org/mozilla/webclient/wrapper_native/RDFEnumeration.java M classes_spec/org/mozilla/webclient/wrapper_native/RDFTreeNode.java M src_moz/BookmarksImpl.cpp M src_moz/RDFEnumeration.cpp M src_moz/RDFTreeNode.cpp M src_moz/nsActions.cpp M src_moz/nsActions.h M src_moz/motif/NativeLoaderStub.cpp
Here is the reason for the deadlock: Our NativeEventThread runs the pump that pulls events out of a queue and processes them. The processing of these events happens inside a synchronized(getTreeLock()) block. Events are put into this queue by anyone that wants to send an nsActionEvent. In order to not get the thread safety assertion for bookmarks, I had to convert bookmarks over to use nsActionEvents for all calls to the bookmarks or rdf service. So, the NativeEventThread is humming along. We're inside a getTreeLock() synchronized block. Meanwhile, the AWT thread is trying to draw the tree. All of these drawing calls happen inside of a getTreeLock() synchronized block. Eventually our RDFTreeNode.isLeaf() is called. This call puts an nsActionEvent in the queue and waits for it to be processed, but it can't be processed because the AWT thread is blocked waiting to acquire the tree lock! My solution was to remove the call to getTreeLock from NativeEventThread, but this has dire consequences on Solaris. Anyone with another suggestion please volunteer it here. Thanks, Ed
OS: other → All
Hardware: PC → All
Fix checked into the trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Component: Java APIs to WebShell → Java APIs to WebShell
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.