280236 - coercing an array containing an nsXPCConstructor to a string results in an uncatchable error

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[timeless]

coercing an array containing an nsXPCConstructor to a string results in an
uncatchable error.

complete testcase:
try {
print(""+[Components.Constructor("@mozilla.org/supports-interface-pointer;1")]);
print ("\treached");
} catch (e) {
print ("\tcaught "+e);
} finally {
print ("\tfinally");
}

tested on mrbkap's trunk wXP xpcshell. output: none.
tested on mabus's trunk linux xpcshell. output: none.
tested on our w32 1.8a5 based xpcshell. output: none.
tested on linux 1.7.5 (viper) xpcshell. output:
	caught [Exception... "Cannot modify properties of a WrappedNative"  nsresult:
"0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame ::
typein :: <TOP_LEVEL> :: line 25"  data: no]
	finally

oddly enough. all of my trunk builds (opt, debug) - which have heavy xpconnect
modifications - work properly.

the expected output that follows is based on my trunk builds (with loads of
patches to xpcom/xpconnect/js) - the binaries were run both on my dev box and on
my laptop.
expected dbg output (pointer value will vary by platform, instance and stuff):
[object nsXPCConstructor @ 0xc05f88]
	reached
	finally

expected opt output:
[object nsXPCConstructor]
        reached
        finally

some analysis based on our 1.8a5 build:
            if (!JSVAL_IS_PRIMITIVE(val) &&
                !MarkSharpObjects(cx, JSVAL_TO_OBJECT(val), NULL)) {
00AE6F9C  test        al,7 
00AE6F9E  jne         MarkSharpObjects+18Dh (0AE6FB7h) 
00AE6FA0  test        eax,eax 
00AE6FA2  je          MarkSharpObjects+18Dh (0AE6FB7h) 
00AE6FA4  push        0    
00AE6FA6  and         eax,0FFFFFFF8h 
00AE6FA9  push        eax  
00AE6FAA  push        ebx  
00AE6FAB  call        MarkSharpObjects (0AE6E2Ah) 
00AE6FB0  add         esp,0Ch 
00AE6FB3  test        eax,eax 
00AE6FB5  je          MarkSharpObjects+1A2h (0AE6FCCh) 
        ok = JS_TRUE;
        for (i = 0, length = ida->length; i < length; i++) {
00AE6FB7  inc         dword ptr [i] 
00AE6FBA  mov         eax,dword ptr [i] 
00AE6FBD  add         dword ptr [ebp-10h],4 
00AE6FC1  cmp         eax,dword ptr [length] 
00AE6FC4  jl          MarkSharpObjects+85h (0AE6EAFh) 
                break;
            if (!JSVAL_IS_PRIMITIVE(val) &&
                !MarkSharpObjects(cx, JSVAL_TO_OBJECT(val), NULL)) {
00AE6FCA  jmp         MarkSharpObjects+1A4h (0AE6FCEh) 
                ok = JS_FALSE;
00AE6FCC  xor         esi,esi  ; next step is this, which will be this, which
will set ESI (ok) to 0 (JS_FALSE)
                break;
            }
        }

EAX = 00000000 EBX = 016E4F98 ECX = 00000000 EDX = 016E4F98 ESI = 00000001 EDI =
020FC548 
EIP = 00AE6FCC ESP = 0012EFF0 EBP = 0012F01C EFL = 00200246 

	val,x	0x0af9a280	long
-	(JSObject*)val	0x0af9a280 {map=0x0afa55f8 {nrefs=1 ops=0x00ab5cf8
XPC_WN_WithCall_JSOps nslots=5 ...} slots=0x0a61cb0c }	JSObject *
-	map	0x0afa55f8 {nrefs=1 ops=0x00ab5cf8 XPC_WN_WithCall_JSOps nslots=5 ...}
JSObjectMap *
	nrefs	1	long
+	ops	0x00ab5cf8 XPC_WN_WithCall_JSOps	JSObjectOps *
	nslots	5	unsigned long
	freeslot	4	unsigned long
+	slots	0x0a61cb0c	long *
	((JSObject*)val)->slots[-1]	5	long
-	((JSObject*)val)->slots,5x	0x0a61cb0c	long *
	[0]	0x0242f068	long
	[1]	0x0242f108	long
	[2]	0x0263a7ed	long
	[3]	0x0afa55c1	long
	[4]	0x80000001	long
+  (JSClass*)(((JSObject*)val)->slots[2]-1)  0x0263a7ec {name=0x0263a7c8
"nsXPCConstructor" flags=13 addProperty=0x00aa4af7
XPC_WN_CannotModifyPropertyStub(JSContext *, JSObject *, long, long *) ...} 
JSClass *
+  (JSObject*)(((JSObject*)val)->slots[1])  0x0242f108 {map=0x0243f520 {nrefs=1
ops=0x00ab5d58 XPC_WN_NoCall_JSOps nslots=710 ...} slots=0x02448be4 }  JSObject *
+  (JSObject*)(((JSObject*)val)->slots[0])  0x0242f068 {map=0x02441b78 {nrefs=1
ops=0x00b0f9a0 _js_ObjectOps nslots=27 ...} slots=0x02481c3c }  JSObject *
+  (JSClass*)(((JSObject*)(JSObject*)(((JSObject*)val)->slots[1]))->slots[2]-1)
 0x00a240b4 {name=0x00a54c58 "ChromeWindow" flags=13 addProperty=0x00aa5b33
XPC_WN_Helper_AddProperty(JSContext *, JSObject *, long, long *) ...}  JSClass *


>	js3250.dll!MarkSharpObjects(JSContext * cx=0x0af9a280, JSObject *
obj=0x0afe6338, JSIdArray * * idap=0x00000000)  Line 448	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x0afe6338, JSObject *
obj=0x0afbc7f0, JSIdArray * * idap=0x00000000)  Line 447 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x0afbc7f0, JSObject *
obj=0x024f6580, JSIdArray * * idap=0x00000000)  Line 447 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x024f6580, JSObject *
obj=0x0245d798, JSIdArray * * idap=0x00000000)  Line 447 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x0245d798, JSObject *
obj=0x0242f108, JSIdArray * * idap=0x00000000)  Line 447 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x0242f108, JSObject *
obj=0x0a516790, JSIdArray * * idap=0x00000000)  Line 447 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x0a516790, JSObject *
obj=0x09dd6c68, JSIdArray * * idap=0x0012f1dc)  Line 447 + 0x14	C
 	js3250.dll!js_EnterSharpObject(JSContext * cx=0x00000000, JSObject *
obj=0x09dd6c68, JSIdArray * * idap=0x00000000, unsigned short * * sp=0x0012f218)
 Line 498 + 0xd	C
 	js3250.dll!array_join_sub(JSContext * cx=0x016e4f98, JSObject *
obj=0x09dd6c68, JSString * sep=0x00b0e304, int literalize=0, long *
rval=0x0012f280, int localeString=0)  Line 341 + 0xe	C
 	js3250.dll!array_toString(JSContext * cx=0x016e4f98, JSObject *
obj=0x09dd6c68, unsigned int argc=0, long * argv=0x0a729240, long *
rval=0x0012f280)  Line 518 + 0x23	C
 	js3250.dll!js_Invoke(JSContext * cx=0x024f6580, unsigned int argc=1, unsigned
int flags=24071256)  Line 1293 + 0x11	C
 	js3250.dll!js_InternalInvoke(JSContext * cx=0x0a729230, JSObject *
obj=0x09dd6c68, long fval=37941856, unsigned int flags=0, unsigned int argc=0,
long * argv=0x00000000, long * rval=0x0012f3d8)  Line 1390 + 0xe	C
 	js3250.dll!js_TryMethod(JSContext * cx=0x016e4f98, JSObject * obj=0x09dd6c68,
JSAtom * atom=0x009a30c0, unsigned int argc=0, long * argv=0x00000000, long *
rval=0x0012f3d8)  Line 3645 + 0x15	C
 	js3250.dll!js_DefaultValue(JSContext * cx=0x016e4f98, JSObject *
obj=0x09dd6c68, JSType hint=JSTYPE_NUMBER, long * vp=0x0012f3fc)  Line 3093 + 0x18	C
 	js3250.dll!js_ValueToNumber(JSContext * cx=0x016e4f98, long v=165506152,
double * dp=0x0012f4d8)  Line 725 + 0x10	C
 	js3250.dll!js_Interpret(JSContext * cx=0x00000001, long * result=0x016f4c58) 
Line 3041 + 0x3e	C
 	js3250.dll!js_Invoke(JSContext * cx=0x024f6580, unsigned int argc=1, unsigned
int flags=24071256)  Line 1313 + 0xa	C
 	js3250.dll!js_Interpret(JSContext * cx=0x00000001, long * result=0x016f4c58) 
Line 3627	C
 	js3250.dll!js_Invoke(JSContext * cx=0x024f6580, unsigned int argc=1, unsigned
int flags=24071256)  Line 1313 + 0xa	C
 	js3250.dll!js_Interpret(JSContext * cx=0x00000001, long * result=0x016f4c58) 
Line 3627	C
 	js3250.dll!js_Invoke(JSContext * cx=0x024f6580, unsigned int argc=1, unsigned
int flags=24071256)  Line 1313 + 0xa	C
 	xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *
wrapper=0x0b558f2c, unsigned short methodIndex=25984, const nsXPTMethodInfo *
info=0x00000001, nsXPTCMiniVariant * nativeParams=0x016f4c58)  Line 1339 + 0x10	C++
 	xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=3, const
nsXPTMethodInfo * info=0x020418f0, nsXPTCMiniVariant * params=0x0012faf8) 
Line 450	C++
 	xpcom_core.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x0a9466c8, unsigned
int methodIndex=3, unsigned int * args=0x0012fbb4, unsigned int *
stackBytesToPop=0x0012fba4)  Line 117 + 0x12	C++
 	xpcom_core.dll!SharedStub()  Line 147	C++
 	appcomps.dll!nsBrowserStatusFilter::OnStateChange(nsIWebProgress *
aWebProgress=0x024e3f94, nsIRequest * aRequest=0x0a443f80, unsigned int
aStateFlags=786448, unsigned int aStatus=0)  Line 175 + 0x11	C++
 	docshell.dll!NSGetModule()  + 0x1037d	
 	docshell.dll!NSGetModule()  + 0x1094d	
 	docshell.dll!NSGetModule()  + 0x10ebe	
 	necko.dll!NSGetModule()  + 0x347f	
 	gklayout.dll!NSGetModule()  + 0x9c7e9	
 	xpcom_core.dll!PL_HandleEvent(PLEvent * self=0x0b5ba2f0)  Line 693	C
 	xpcom_core.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x009fea18)  Line
627 + 0x6	C
 	xpcom_core.dll!_md_TimerProc(HWND__ * hwnd=0x000f0248, unsigned int uMsg=275,
unsigned int idEvent=0, unsigned long dwTime=331463531)  Line 998 + 0xa	C
 	user32.dll!_InternalCallWinProc@20()  + 0x28	
 	user32.dll!_UserCallWinProc@24()  + 0xa1	
 	user32.dll!_DispatchMessageWorker@8()  + 0xcc6	
 	user32.dll!_DispatchMessageW@4()  + 0xf	
 	gkwidget.dll!nsAppShell::Run()  Line 159	C++
 	appcomps.dll!nsAppStartup::Run()  Line 216	C++
 	mozilla.exe!main1(int argc=2, char * * argv=0x002a4548, nsISupports *
nativeApp=0x00000000)  Line 1321 + 0x9	C++
 	mozilla.exe!main(int argc=2, char * * argv=0x002a4548)  Line 1813 + 0x13	C++
 	mozilla.exe!WinMain(HINSTANCE__ * __formal=0x00400000, HINSTANCE__ *
__formal=0x00400000, char * args=0x00152365, HINSTANCE__ * __formal=0x00400000)
 Line 1841 + 0x17	C++
 	mozilla.exe!WinMainCRTStartup()  Line 390 + 0x1b	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23	

by the time this unwinds, cx->throwing is 0 and ok is 0 (ok is one instruction
away from being 0). the haystack i had to go through cost me 12 hours.

Comment 1

[timeless]

notes: mabus has --disable-jsd, so we can't blame jsd (which is good, because i
want to blame xpconnect).

Comment 2

[timeless]

Attachment: fix

ok, so i had patches in my tree for this, how amusing/convenient. thanks to
mabus for testing.

the jsid bits aren't necessary for this bug, but since the task was to mark
xpconnect components as classinfo threadsafe, i feel it's ok to roll them in.

Comment 3

[timeless]

*** Bug 81879 has been marked as a duplicate of this bug. ***

Comment 4

[timeless]

Attachment: diff from current tree

Comment 5

[David Bradley]

Any reason not to implement GetClassID an no alloc versions? It seems that the
non-implementation pattern has been repeated, but I'm wondering if that's the
correct pattern. If most things don't implement should it even be part of the
nsIClassInfo interface?

Comment 6

[Brendan Eich [:brendan]]

(In reply to comment #5)
> Any reason not to implement GetClassID an no alloc versions? It seems that the
> non-implementation pattern has been repeated, but I'm wondering if that's the
> correct pattern. If most things don't implement should it even be part of the
> nsIClassInfo interface?

This method is used only by FastLoad.  It's not going away, but it is optional.
 If you are defining nsIClassInfo for a class that does not implement
nsISerializable, then you can stub this method with an error return, which has
traditionally been EAGAIN, er, NS_ERROR_NOT_AVAILABLE.

/be

Comment 7

[timeless]

mostly because i hadn't needed it and a bunch of these objects aren't
constructable, but some are, so i could add classids for those. i believe i
started with things that weren't and cookie cutter copied to things that
happened to be.

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 188494 [details] [diff] [review]
diff from current tree

Please re-request sr once this has r+.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 188494 [details] [diff] [review]
diff from current tree

Please re-request sr once this has r+.

Comment 10

[David Bradley]

Attachment: nsIClassInfo::GetInterfaces implementation pattern

While the patch appears to be correct, what strikes me is the reoccurring
pattern. Remember, anytime you use cut and paste stop and think ;-) There's a
fair bit of code duplicated there that really doesn't need to be.

The attached file is something I'd like to have considered added to the
nsIClassInfo works. It implements the most common pattern of the GetInterfaces
implementations. I have not compiled it, it was just an editor whack at what I
think is needed.

nsIClassInfo is frozen, does that prevent any changes to the interface file, or
just to the interface itself? In other words is the idl file frozen as well as
the interface? If not, I'd like to the see these or something like these macros
added so others don't have to duplicate this information. If both are frozen
can we put them somewhere where people can get at them. I'm expecting we're
going to see more and more components implement nsIClassInfo. So while this
isn't a big code size win here, it should add up as more things implement
nsIClassInfo.

Maybe the macro's and C function need to be put in another bug, that checked
in, and then this patch modified to use that.

I can do the work of getting the macro's in and the function cleaned up. I
would have done it now, but I wanted to get direction on where the macro's
should go before put in the effort of a formal patch.

Comment 11

[timeless]

*** Bug 333322 has been marked as a duplicate of this bug. ***

Comment 12

[timeless]

*** Bug 342423 has been marked as a duplicate of this bug. ***

Comment 13

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Patch v1.1

Per IRC discussion here is an updated patch without the GetInterfaces macros.

Comment 14

[David Bradley]

Comment on attachment 227120 [details] [diff] [review]
Patch v1.1

r=dbradley

The usual XPConnect style nits about removing spaces between statements (if,while) and the left paren.

Thanks for the update. Hopefully I'll get around to consolidating some of this code.

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

> nsIClassInfo is frozen, does that prevent any changes to the interface file, or
> just to the interface itself? 

I always think that %{C++} blocks in IDL files look ugly. Maybe it could be put into an nsClassInfoUtils.h, or where the isupports macros are.

Comment 16

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 227120 [details] [diff] [review]
Patch v1.1


Just wanted to verify that applying this patch quieted the warnings I reported in bug 342423. Do you want me to reattach with those style nits worked out?

Comment 17

[Johnny Stenback (:jst)]

Comment on attachment 227120 [details] [diff] [review]
Patch v1.1

- In js/src/xpconnect/src/xpccomponents.cpp
 
+// XXX Need to make a base class.
+

Is this really a useful comment to check in? How about filing a bug on this instead?
 - In js/src/xpconnect/src/xpcruntimesvc.cpp:

 nsJSRuntimeServiceImpl::GetRuntime(JSRuntime **runtime)
 {
     if(!runtime)
         return NS_ERROR_NULL_POINTER;
 
     if(!mRuntime)
     {
-        mRuntime = JS_NewRuntime(gGCSize);
+        char *jsrts = PR_GetEnv("JS_RUNTIME_SIZE");
+        uint32 size = jsrts ? atoi(jsrts) : 0;
+        if (size > 1) {
+            size *= 1024;
+        } else {
+            size = gGCSize;
+        }
+        mRuntime = JS_NewRuntime(size);
         if(!mRuntime)
             return NS_ERROR_OUT_OF_MEMORY;

This looks unrelated to this bug. If it's not, please explain why this matters, otherwise this seems like it would belong in a bug of it's own.

sr=jst with that.

> 
>         // Unconstrain the runtime's threshold on nominal heap size, to avoid
>         // triggering GC too often if operating continuously near an arbitrary
>         // finite threshold (0xffffffff is infinity for uint32 parameters).
>         // This leaves the maximum-JS_malloc-bytes threshold still in effect
>         // to cause period, and we hope hygienic, last-ditch GCs from within

Comment 18

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Patch v1.2

(In reply to comment #17)
> Is this really a useful comment to check in? How about filing a bug on this
> instead?

Gone.

> This looks unrelated to this bug. If it's not, please explain why this matters,
> otherwise this seems like it would belong in a bug of it's own.

Gone.

> sr=jst with that.

I also removed a wayward '#define DEBUG_xpc_hacker'.

Presuming r+/sr+ carrying over from attachment 227120 [details] [diff] [review].

Comment 19

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 229004 [details] [diff] [review]
Patch v1.2

Fixed on trunk.

Comment 20

[Ben Turner (not reading bugmail, use the needinfo flag!)]

This caused some tinderbox unhappiness so I backed it out. From the balsa log (see URL) this is what happened:

----------- Output from trace-malloc bloat test ------------- 
  Type Manifest File: /builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/.mozilla/firefox/vyfthk2c.default/xpti.dat
  *** Registering Apprunner components (all right -- a generic module!)
  WARNING: XPCOM objects created/destroyed from static ctor/dtor: 'gActivityTLS != BAD_TLS_INDEX && NS_PTR_TO_INT32(PR_GetThreadPrivate(gActivityTLS)) == 0', file /builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/xpcom/base/nsTraceRefcntImpl.cpp, line 1085
  WARNING: XPCOM objects created/destroyed from static ctor/dtor: 'gActivityTLS != BAD_TLS_INDEX && NS_PTR_TO_INT32(PR_GetThreadPrivate(gActivityTLS)) == 0', file /builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/xpcom/base/nsTraceRefcntImpl.cpp, line 1085
  ###!!! ASSERTION: new XPCPerThreadData() failed!: '0', file /builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp, line 545
  
  Program firefox-bin (pid = 10459) received signal 6.
  Stack:
  nsProfileLock::FatalSignalHandler(int)+0x0000014E [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxul.so +0x0003B25C]
  UNKNOWN [/lib/i686/libpthread.so.0 +0x000098D5]
  UNKNOWN [/lib/i686/libc.so.6 +0x0002E848]
  abort+0x0000015E [/lib/i686/libc.so.6 +0x0002FF82]
  PR_Assert+0x00000000 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libnspr4.so +0x00011737]
  UNKNOWN [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x001175FD]
  NS_DebugBreak_P+0x000002FE [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x001175CC]
  XPCPerThreadData::GetData()+0x0000016D [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libxpconnect.so +0x0009B2D7]
  nsXPCThreadJSContextStackImpl::GetStackForCurrentThread()+0x00000017 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libxpconnect.so +0x0009BACF]
  nsXPCThreadJSContextStackImpl::GetSafeJSContext(JSContext**)+0x00000055 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libxpconnect.so +0x0009ABB7]
  nsScriptSecurityManager::GetSafeJSContext()+0x0000008F [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libcaps.so +0x0001BF2B]
  nsScriptSecurityManager::Init()+0x0000001E [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libcaps.so +0x0002538C]
  nsScriptSecurityManager::GetScriptSecurityManager()+0x00000056 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libcaps.so +0x00025DA6]
  UNKNOWN [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libcaps.so +0x00030B32]
  UNKNOWN [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x0008E4E3]
  UNKNOWN [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x000F8EAD]
  UNKNOWN [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x000F9D0B]
  CallGetService(char const*, nsID const&, void**)+0x0000007C [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x00083A18]
  nsGetServiceByContractID::operator()(nsID const&, void**) const+0x00000036 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x00083F82]
  nsCOMPtr<nsIScriptSecurityManager>::assign_from_gs_contractid(nsGetServiceByContractID, nsID const&)+0x00000020 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libxpconnect.so +0x00080EC8]
  nsCOMPtr<nsIScriptSecurityManager>::nsCOMPtr(nsGetServiceByContractID)+0x00000036 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libxpconnect.so +0x0007F4A8]
  mozJSComponentLoader::ReallyInit()+0x00000122 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libxpconnect.so +0x000C2304]
  UNKNOWN [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libxpconnect.so +0x000C2789]
  nsFactoryEntry::GetFactory(nsIFactory**)+0x00000216 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x000FDB80]
  UNKNOWN [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x000F8E7D]
  CallCreateInstance(char const*, nsISupports*, nsID const&, void**)+0x00000083 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x00083B37]
  nsCreateInstanceByContractID::operator()(nsID const&, void**) const+0x00000041 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxpcom_core.so +0x00083D0B]
  nsCOMPtr<nsIObserver>::assign_from_helper(nsCOMPtr_helper const&, nsID const&)+0x00000028 [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libembedcomponents.so +0x0004D910]
  nsCOMPtr<nsIObserver>::operator=(nsCOMPtr_helper const&)+0x0000002D [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libembedcomponents.so +0x0004D715]
  UNKNOWN [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/libembedcomponents.so +0x0004D04D]
  XRE_main+0x0000120D [/builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/libxul.so +0x0002B603]
  main+0x00000044 [firefox-bin +0x00000628]
  __libc_start_main+0x00000093 [/lib/i686/libc.so.6 +0x0001C507]
  Sleeping for 300 seconds.
  Type 'gdb firefox-bin 10459' to attach your debugger to this thread.
----------- End Output from trace-malloc bloat test --------- 
Error: bloat test timed out after 240 seconds.

Comment 21

[timeless]

bsmedberg: help?

Comment 22

[Boris Zbarsky [:bzbarsky]]

IsValid() got changed to check mNativesLock, but I don't see where mNativesLock is allocated.  Given that, it makes sense that you're dying.

Comment 23

[u222634]

Attachment: Patch v1.3

Update to patch 1.2 , fixes crash on startup / exit.

Comment 24

[u222634]

New patch fixes the crash issues. However, it seems like mNativesLock isn't used anywhere other than IsValid(). Will it be used in the future? If not, it might be better for the patch to remove mNativesLock instead of allocating and deleting it properly.

Comment 25

[u222634]

Attachment: Patch v1.5 - Based on timeless's latest patch for this bug instead of v1.2

Comment 26

[u222634]

patch breaks windows build, revising...

Comment 27

[u222634]

Attachment: patch v1.6 - Builds on Win32, Mac PPC, Mac Intel, Linux, Linux x86-64

seems like the patch timeless had wasn't quite complete or had other pieces of patches. Here's a clean one made from v1.2 of the patch. Compiles on all platforms I had handy. :)

Comment 28

[Johnny Stenback (:jst)]

Comment on attachment 231710 [details] [diff] [review]
patch v1.6 - Builds on Win32, Mac PPC, Mac Intel, Linux, Linux x86-64

r+sr=jst.

For the record, the only difference between this patch and v1.2 besides whitespace and comments is the removal of mNativesLock (declaration and use of uninitialized member).

And also, this doesn't apply cleanly to the trunk, gMainThread for instance is no longer a member of XPCPerThreadData, and there's some differences in xpccomponents.cpp since this patch was made that make part of those changes not apply cleanly.

Comment 29

[Andrew Schultz]

the checkin here caused Rlk regressions on nye (636->804) and balsa (1.77K->2.30K)

Comment 30

[Phil Ringnalda (:philor)]

Neverthestill, seems to have stuck for 2.5 years now.