334834 - Find why old XXXMLM assert in JS_InitClass fails

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[tor]

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

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: another stack for the same assertion

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

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 3

[Uri Bernstein]

I got the same thing on OS X, after pulling the source from CVS.

Marking as "blocker", since it obviously blocks any development.

Comment 4

[Robert Kaiser]

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.

Comment 5

[Robert Kaiser]

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)

Comment 6

[Igor Bukanov]

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

Comment 7

[Brendan Eich [:brendan]]

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

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

(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.

Comment 9

[Brendan Eich [:brendan]]

Attachment: fix

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

Comment 10

[Brendan Eich [:brendan]]

Attachment: slightly more minimal fix

Comment 11

[Brendan Eich [:brendan]]

Fixed.

/be