Closed
Bug 182572
Opened 22 years ago
Closed 22 years ago
nsProxyObjectManager::GetProxy() memory corruption
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: gnufnork, Assigned: dougt)
Details
(Keywords: crash)
Attachments
(1 file, 1 obsolete file)
2.42 KB,
patch
|
dougt
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020930 Build Identifier: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020930 I am using proxy thread in an project using the xpcom core and mozilla embedding, which started to exhibit strange failures and crashes. In gdb, I got the following stackdump after segfaulting (this or worse, sometimes the bug triggered Invalid Instruction after jumping in the heap) from /usr/lib/libxpcom.so #1 0x400cfe4a in nsProxyObject::~nsProxyObject() () from /usr/lib/libxpcom.so #2 0x400d0475 in nsProxyObject::Post(unsigned, nsXPTMethodInfo*, nsXPTCMiniVariant*, nsIInterfaceInfo*) () from /usr/lib/libxpcom.so #3 0x400c9037 in PL_HandleEvent () from /usr/lib/libxpcom.so #4 0x400c8f48 in PL_ProcessPendingEvents () from /usr/lib/libxpcom.so #5 0x400ca0a6 in nsEventQueueImpl::ProcessPendingEvents() () I traced the bug to the HandleDestructorEvent, post message with delete seemed to caus the segfault in some cases. After a day long of debugging the cause turned out to be really stupid (and luckily trivial to fix) It is in nsProxyObjectManager::GetProxy() . An object gets created, a proxy is made for it and afterwards the real object is deleted. *OOPS* I'll attach an patch. Reproducible: Sometimes Steps to Reproduce: 1. Use nsProxyObjectManager::GetProxy 2. unref the returned object Actual Results: Segfault Expected Results: Give me an happy proxy object
Reporter | ||
Comment 1•22 years ago
|
||
This fixes the bug, I gave encountered no segfaults and strange memory probemds afterwards. (note that the nsProxyCreateInstance will now get deleted in the target thread instead of the caller, but, this isn't a problem since the destructor does nothing and the whole object is meant to run in the target thread)
Comment 2•22 years ago
|
||
does it also happen with latest nightly build ? http://ftp.mozilla.org/pub/mozilla/nightly/latest (and eventually 1.2)
Reporter | ||
Comment 3•22 years ago
|
||
I haven't tried an nightly build yet - but yes, it happens with 1.2
Assignee | ||
Comment 4•22 years ago
|
||
based on previous patch.
Attachment #107735 -
Attachment is obsolete: true
Assignee | ||
Comment 5•22 years ago
|
||
Comment on attachment 108092 [details] [diff] [review] patch v.2 r=dougt
Attachment #108092 -
Flags: superreview?(alecf)
Attachment #108092 -
Flags: review+
Comment 6•22 years ago
|
||
Comment on attachment 108092 [details] [diff] [review] patch v.2 sr=alecf though our convention is that the creator does the addref, not the constructor.. if the creator uses nsCOMPtrs then the Release happens when the nsCOMPtr goes away.. (I realize you're not changing that code, but thought I'd mention it..)
Attachment #108092 -
Flags: superreview?(alecf) → superreview+
Assignee | ||
Comment 7•22 years ago
|
||
Thanks for the patch. I checked it into the trunk. It will be part of 1.3a. alec - i went ahead and fixed up that addref via constructor thang. Checking in nsProxyObjectManager.cpp; /cvsroot/mozilla/xpcom/proxy/src/nsProxyObjectManager.cpp,v <-- nsProxyObjectManager.cpp new revision: 1.51; previous revision: 1.50 done
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•