Closed Bug 182572 Opened 22 years ago Closed 22 years ago

nsProxyObjectManager::GetProxy() memory corruption

Categories

(Core :: XPCOM, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: gnufnork, Assigned: dougt)

Details

(Keywords: crash)

Attachments

(1 file, 1 obsolete file)

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
Attached patch Patch for xpcom/proxy/ (obsolete) — Splinter Review
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)
does it also happen with latest nightly build ?
http://ftp.mozilla.org/pub/mozilla/nightly/latest
(and eventually 1.2)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash, patch
I haven't tried an nightly build yet - but yes, it happens with 1.2
Attached patch patch v.2Splinter Review
based on previous patch.
Attachment #107735 - Attachment is obsolete: true
Comment on attachment 108092 [details] [diff] [review]
patch v.2

r=dougt
Attachment #108092 - Flags: superreview?(alecf)
Attachment #108092 - Flags: review+
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+
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.

Attachment

General

Created:
Updated:
Size: