nsProxyObjectManager::GetProxy() memory corruption

RESOLVED FIXED

Status

()

Core
XPCOM
--
critical
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: W.J. van der Laan, Assigned: dougt)

Tracking

({crash})

Trunk
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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

16 years ago
Created attachment 107735 [details] [diff] [review]
Patch for xpcom/proxy/

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

16 years ago
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
(Reporter)

Comment 3

16 years ago
I haven't tried an nightly build yet - but yes, it happens with 1.2
(Assignee)

Comment 4

16 years ago
Created attachment 108092 [details] [diff] [review]
patch v.2

based on previous patch.
Attachment #107735 - Attachment is obsolete: true
(Assignee)

Comment 5

16 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

16 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

16 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
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.