Last Comment Bug 55004 - Webclient bookmarks don't work with tip.
: Webclient bookmarks don't work with tip.
Status: RESOLVED FIXED
:
Product: Core Graveyard
Classification: Graveyard
Component: Java APIs to WebShell (show other bugs)
: Trunk
: All All
: P3 normal (vote)
: ---
Assigned To: edburns
: geetha.vaidyanaathan
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-02 21:26 PDT by edburns
Modified: 2012-04-09 22:27 PDT (History)
0 users
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Checkpoint 10/2/00 (28.86 KB, application/octet-stream)
2000-10-02 21:27 PDT, edburns
no flags Details
cvs diff -u of fix for this bug, first iteration. (79.29 KB, patch)
2000-11-01 12:49 PST, edburns
no flags 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)
2000-11-01 12:52 PST, edburns
no flags Details

Description edburns 2000-10-02 21:26:18 PDT
Webclient bookmarks don't work with tip.
Comment 1 edburns 2000-10-02 21:27:05 PDT
a
Comment 2 edburns 2000-10-02 21:27:49 PDT
Created attachment 16020 [details]
Checkpoint 10/2/00
Comment 3 edburns 2000-10-26 18:51:27 PDT
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.
Comment 4 edburns 2000-11-01 12:49:13 PST
Created attachment 18474 [details] [diff] [review]
cvs diff -u of fix for this bug, first iteration.
Comment 5 edburns 2000-11-01 12:52:30 PST
Created attachment 18475 [details]
tar.gz of fix for this bug, first iteration.  Untar onto 11/1/00 webclient tree, in the webclient directory.
Comment 6 edburns 2000-11-01 12:58:26 PST
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
Comment 7 edburns 2000-11-02 10:38:54 PST
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
Comment 8 edburns 2000-11-02 19:17:09 PST
Fix checked into the trunk.

Note You need to log in before you can comment on or make changes to this bug.