seamonkey built from the trunk on the morning of 4/20 dies on startup with an assert in JS_InitClass. Stack: Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 1076277632 (LWP 13985)] JS_Assert (s=0x40205197 "!OBJ_GET_PROTO(cx, ctor)", file=0x40202b1c "/home/tor/moz/trunk/mozilla/js/src/jsapi.c", ln=2181) at /home/tor/moz/trunk/mozilla/js/src/jsutil.c:62 62 abort(); Current language: auto; currently c (gdb) where #0 JS_Assert (s=0x40205197 "!OBJ_GET_PROTO(cx, ctor)", file=0x40202b1c "/home/tor/moz/trunk/mozilla/js/src/jsapi.c", ln=2181) at /home/tor/moz/trunk/mozilla/js/src/jsutil.c:62 #1 0x4013c9c3 in JS_InitClass (cx=0x96bbe08, obj=0x96b7278, parent_proto=0x96b72b0, clasp=0x40218d00, constructor=0x40174f12 <Function>, nargs=1, ps=0x40218ca0, fs=0x40218d60, static_ps=0x0, static_fs=0x0) at /home/tor/moz/trunk/mozilla/js/src/jsapi.c:2181 #2 0x40176043 in js_InitFunctionClass (cx=0x96bbe08, obj=0x96b7278) at /home/tor/moz/trunk/mozilla/js/src/jsfun.c:2047 #3 0x4013ab62 in js_InitFunctionAndObjectClasses (cx=0x96bbe08, obj=0x96b7278) at /home/tor/moz/trunk/mozilla/js/src/jsapi.c:1133 #4 0x4013af5a in JS_InitStandardClasses (cx=0x96bbe08, obj=0x96b7278) at /home/tor/moz/trunk/mozilla/js/src/jsapi.c:1173 #5 0x40a04bd6 in _newJSDContext (jsrt=0x9524878, callbacks=0x0, user=0x0) at /home/tor/moz/trunk/mozilla/js/jsd/jsd_high.c:142 #6 0x40a04e11 in jsd_DebuggerOnForUser (jsrt=0x9524878, callbacks=0x0, user=0x0) at /home/tor/moz/trunk/mozilla/js/jsd/jsd_high.c:196 #7 0x40a027bb in JSD_DebuggerOnForUser (jsrt=0x9524878, callbacks=0x0, user=0x0) at /home/tor/moz/trunk/mozilla/js/jsd/jsdebug.c:52 #8 0x40a10fe7 in jsdService::OnForRuntime (this=0x96a4a70, rt=0x9524878) at /home/tor/moz/trunk/mozilla/js/jsd/jsd_xpc.cpp:2484 #9 0x40a0dc62 in jsdASObserver::Observe (this=0x96d2658, aSubject=0x0, aTopic=0x4011614e "end", aData=0x4011f84e) at /home/tor/moz/trunk/mozilla/js/jsd/jsd_xpc.cpp:3311 #10 0x400b10e2 in NS_CreateServicesFromCategory ( category=0x401160cd "xpcom-autoregistration", origin=0x0, observerTopic=0x4011614e "end") at /home/tor/moz/trunk/mozilla/xpcom/components/nsCategoryManager.cpp:896 #11 0x400bc137 in nsComponentManagerImpl::AutoRegister (this=0x9522460, aSpec=0x0) at /home/tor/moz/trunk/mozilla/xpcom/components/nsComponentManager.cpp:3352 #12 0x40056897 in NS_InitXPCOM3_P (result=0x0, binDirectory=0x0, appFileLocationProvider=0x0, staticComponents=0x0, componentCount=0) at /home/tor/moz/trunk/mozilla/xpcom/build/nsXPComInit.cpp:626 #13 0x0804ead1 in main (argc=1, argv=0xbfb884a4) at /home/tor/moz/trunk/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1684

This was just while browsing around in Firefox (mainly tinderbox and bugzilla, IIRC).

The assertion in question has been commented out for years, and was just uncommented in brendan's patch yesterday.

I got the same thing on OS X, after pulling the source from CVS. Marking as "blocker", since it obviously blocks any development.

Seeing this on today's seamonkey trunk debug build as well... according to comment #2 this seems to have been (indirectly) caused by checkin to bug 304376, so marking this dependency.

The assertion was commented out in this way until today: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsapi.c&rev=3.255#2118 Now it's uncommented again: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsapi.c&rev=3.256#2140 Actually, that assertion never had been uncommented, it was introduced in commented-out form in http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsapi.c&rev=3.8#964 3.8 <shaver> 1998-06-09 14:39 added JS_YieldRequest to API (me), and removed assertion in InitClass (mlm)

The same thing on Linux: so far clicking in gmail to open links in external windows gives the crash 100% reliably

I restored MLM's old commented-out version. Blake and I were convinced that we want this assertion. We probably do, but only after the bug it's barking about is found and fixed. This report can represent that bug. /be

(In reply to comment #7) > I restored MLM's old commented-out version. Blake and I were convinced that we > want this assertion. We probably do, but only after the bug it's barking about > is found and fixed. This report can represent that bug. For what it's worth. I looked at the assertion on startup some. I saw js_InitFunctionAndObjectClasses re-enter itself during a call to JS_InitStandardClasses. The fix for the lazy class init case (to avoid re-entering the caching stuff while resolving standard classes) only works for Function and Object because even though we do try to re-enter, we don't actually resolve the inner attempt since we're already resolving (we take the early out in js_GetClassObject). This only holds for the second iteration in the non-lazy case, so our Function object does get a prototype, and we botch the MLM assertion. I haven't looked at the botch while we're browsing yet.

Blake and I talked, and this is the solution: use cx->resolvingTable in both the lazy standard class init, and the eager (embedding calls JS_InitStandardClasses) cases, to ensure that js_InitFunctionAndObjectClasses does not nest. /be

Fixed. /be