Closed
Bug 380228
Opened 18 years ago
Closed 3 years ago
Assertion failure at shutdown if console listener isn't unregistered: PR_ASSERT(lock->owner == 0);
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: WeirdAl, Assigned: timeless)
References
Details
(Keywords: assertion, crash, testcase, Whiteboard: [ccbr])
Attachments
(3 files)
3.37 KB,
text/plain
|
Details | |
8.76 KB,
patch
|
Details | Diff | Splinter Review | |
2.01 KB,
patch
|
benjamin
:
review-
|
Details | Diff | Splinter Review |
I was writing a xpcshell testcase for bug 380169, when I stumbled upon this crash. Apparently, if you fail to unregister a console listener for any reason (such as an exception being thrown and not caught), you will crash on shutdown.
Testcase coming up as an attachment in a few minutes.
Flags: in-testsuite?
Reporter | ||
Comment 1•18 years ago
|
||
violates API:
04 xpcom_core!nsProxyObjectManager::~nsProxyObjectManager(void)+0x31
Hold Monitor:
0b xpcom_core!nsProxyEventObject::Release(void)+0xa0
This has nothing to do w/ the error console, it's either a bug in POM/PEO or a bug in XPCOM Startup/Shutdown, both of which are the responsibility of XPCOM (well, it could be the fault of the Error Service, but that too is in XPCOM, the error console is some ui).
Assignee: js-console → nobody
Component: Error Console → XPCOM
QA Contact: error-console → xpcom
Assignee: nobody → timeless
Status: NEW → ASSIGNED
Attachment #264453 -
Flags: superreview?(darin.moz)
Attachment #264453 -
Flags: review?(ajvincent)
Reporter | ||
Comment 4•18 years ago
|
||
Comment on attachment 264453 [details] [diff] [review]
this seems to work
Why are you asking me to review? I don't know this code and have never touched anything close to it. I don't know what proxies mean in this context. Never mind how simple the patch is, I don't think I'm an appropriate reviewer.
Attachment #264453 -
Flags: review?(ajvincent) → review?(benjamin)
Reporter | ||
Comment 5•18 years ago
|
||
I do not crash with timeless's patch, it does indeed fix things.
Comment 6•17 years ago
|
||
Comment on attachment 264453 [details] [diff] [review]
this seems to work
The call to mProxyObject->LockedRemove(this) *must* be run within the POM monitor! In this case you're releasing the monitor before calling the destructor, which solves your bug but introduces unlocked access to the POM data structures.
Attachment #264453 -
Flags: superreview?(darin.moz)
Attachment #264453 -
Flags: review?(benjamin)
Attachment #264453 -
Flags: review-
Updated•17 years ago
|
Version: unspecified → Trunk
Updated•15 years ago
|
Whiteboard: [ccbr]
Reporter | ||
Comment 7•6 years ago
|
||
It's worth asking if anyone thinks this bug is still possible. It's been over a decade.
Flags: in-testsuite?
Comment 8•3 years ago
|
||
Hello Alex!
Is this issue still available? If so could you please provide some steps in order to reproduce it?
If the issue is not available anymore can we close it?
Flags: needinfo?(ajvincent)
Comment 9•3 years ago
|
||
nsProxyEventObject doesn't seem to exist any more, and I'm not sure I've even heard of it, so let's just go ahead and close this.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(ajvincent)
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•