403145 - Double-free crash [@ js_FinalizeStringRT] with level3/core/userdatahandler04.html

Status: RESOLVED DUPLICATE of bug 406800

(Core :: DOM: Core & HTML, defect, P2)

Description

[Bob Clary [:bc] (inactive)]

1. load url
2. pick userdatahandler04 
3. click load jsunit
4. let test run.
5. shutdown

*** glibc detected *** /work/mozilla/builds/1.9.0/mozilla/firefox-debug/dist/bin/firefox-bin: double free or corruption (!prev): 0x096eff28 ***

If you run the alltests, it will crash after the userdatahandler04 test with different stacks (depending on loader and mimetype) but which all have cycle collector and GC in them.

security sensitive for now. 

The individual test is located at <http://test.bclary.com/tests/w3.org/2001/DOM-Test-Suite/build/ecmascript/level3/core/userdatahandler04.html>

Comment 1

[Johnny Stenback (:jst)]

Bob, did this just start happening, or is this an old problem? Peter, care to look into this one?

Comment 2

[Johnny Stenback (:jst)]

peterv, see previous comment.

Comment 3

[Bob Clary [:bc] (inactive)]

(In reply to comment #1)
> Bob, did this just start happening, or is this an old problem? Peter, care to
> look into this one?
> 

2007-11-07-04 build does not show it, but 2007-11-08-04 build does. I looked at the check ins and the cause didn't stand out.

Comment 4

[Jeff Walden [:Waldo]]

Why aren't the DOM 3 tests already in dom/tests/mochitest?  Is it just that nobody's gotten around to putting in the effort to get them there?

Comment 5

[Peter Van der Beken [:peterv]]

Grr, at first I got a crash in a nodeinfo manager when following the steps to reproduce. Now I can't get it to crash at all.

(In reply to comment #4)
> Is it just that
> nobody's gotten around to putting in the effort to get them there?

AFAIK yes, same for Level 2 Events and HTML and Level 3 Events and XPath.

Comment 6

[Johnny Stenback (:jst)]

Here's a stack from that crash:

#7  <signal handler called>
#8  0x00110402 in __kernel_vsyscall ()
#9  0x00dba690 in raise () from /lib/libc.so.6
#10 0x00dbbf91 in abort () from /lib/libc.so.6
#11 0x00df29eb in __libc_message () from /lib/libc.so.6
#12 0x00dfaac1 in _int_free () from /lib/libc.so.6
#13 0x00dfe0f0 in free () from /lib/libc.so.6
#14 0x0027a80a in js_FinalizeStringRT (rt=0x9515b20, str=0xb1d55158, type=-5, 
    cx=0x99e67c8) at ../../../mozilla/js/src/jsstr.c:2679
#15 0x00201477 in js_GC (cx=0x99e67c8, gckind=GC_NORMAL)
    at ../../../mozilla/js/src/jsgc.c:2633
#16 0x001bbcaa in JS_GC (cx=0x99e67c8) at ../../../mozilla/js/src/jsapi.c:2383
#17 0x0302761c in nsXPConnect::Collect (this=0x94fe750)
    at ../../../../../mozilla/js/src/xpconnect/src/nsXPConnect.cpp:510
#18 0x00378fc3 in nsCycleCollector::Collect (this=0x94a1fe0, aTryCollections=5)
    at ../../../mozilla/xpcom/base/nsCycleCollector.cpp:2096
#19 0x00379095 in nsCycleCollector::Shutdown (this=0x94a1fe0)
    at ../../../mozilla/xpcom/base/nsCycleCollector.cpp:2251
#20 0x003790cc in nsCycleCollector_shutdown ()
    at ../../../mozilla/xpcom/base/nsCycleCollector.cpp:2669
...

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Peter, is this the same generic problem of running unlink in the middle of GC? Or would we always assert first if that did bad things?

Comment 8

[Daniel Veditz [:dveditz]]

Raising priority to make sure sg:critical bugs stay in the FF3 release timeframe

Comment 9

[Peter Van der Beken [:peterv]]

I'm going to mark this as a dupe of bug 406800. Reopen if the problem remains, I never managed to reliably reproduce this myself.

Comment 10

[Bob Clary [:bc] (inactive)]

still happens to me.

Comment 11

[Bob Clary [:bc] (inactive)]

(In reply to comment #10)
> still happens to me.
> 

wait. I missed the most recent patch. If I can't repro I'll dupe it again.

Comment 12

[Bob Clary [:bc] (inactive)]

Ok. After a new build I can't reproduce. Sorry about the reopen and thanks for the fix.