Closed Bug 277477 Opened 20 years ago Closed 7 years ago

rt->scopeSharingDone/LockScope deadlock (take 2)

Categories

(Core :: XPConnect, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: timeless, Unassigned)

Details

(Keywords: hang)

i'm using 1.8a5 (some minor changes by brendan), plus a proxy written in js
(which only runs on non main threads), plus venkman (which we *know* to be very
threadunsafe).

Most of the assertions i'm getting are venkman's fault. at a certain point i
disabled threadsafe assertions for (GlobalWindow|Location)Impl::(AddRef|Release)

this bug is similar to the long resolved bug 123930.
biesi reports this sort of problem happens in his own threaded js (based on 1.7
on linux i686), hence os:all.

i'm fairly certain i saw this when we first started writing our proxy, but we
fairly quickly abandonned using debug builds because of the amazing number of
threadsafety assertions :(.

attachments coming /slowly/.
It's not a JS engine bug, for the umpteenth time.  It's a failure to follow the
request model on the part of XPConnect and the DOM.  It won't be easy to fix.

/be
Component: JavaScript Engine → XPConnect
Assignee: general → nobody
See bug 176182, which is against the suite for historical reasons.

Need some request model reconciliation brainstorming, ideally here.  Probably
bug 176182 should be forward-duped against this bug.

/be
QA Contact: pschwartau → xpconnect
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.