525481 - (Assertion failure: "nsrcnotes == 1") Startup crash caused by fastload file [@mem_getbytes | JS_XDRBytes ]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

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

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091030 Minefield/3.7a1pre

I get a startup crash in fastload code. Deleting XPC/XUL.mfasl fixes it. The crash is reproducible. 

This is an opt build, so this stack isn't all that useful, and 64-bit builds don't have symbols on the server :/
(gdb) bt
#0  0x00007fdafc81569b in raise () from /lib/libpthread.so.0
#1  0x00007fdafb6548a0 in ?? () from /home/cbiesinger/firefox/libxul.so
#2  <signal handler called>
#3  0x00007fdaf7c66d01 in memcpy () from /lib/libc.so.6
#4  0x00007fdafaf517ec in ?? () from /home/cbiesinger/firefox/libmozjs.so
#5  0x00007fdafaf50afb in JS_XDRBytes () from /home/cbiesinger/firefox/libmozjs.so
#6  0x00007fdafaf472d3 in ?? () from /home/cbiesinger/firefox/libmozjs.so
#7  0x00007fdafaee85bd in ?? () from /home/cbiesinger/firefox/libmozjs.so
#8  0x00007fdafaf4762a in ?? () from /home/cbiesinger/firefox/libmozjs.so
#9  0x00007fdafaf50d20 in JS_XDRScript () from /home/cbiesinger/firefox/libmozjs.so
#10 0x00007fdafb6bb31e in ?? () from /home/cbiesinger/firefox/libxul.so
#11 0x00007fdafb6bcd5f in ?? () from /home/cbiesinger/firefox/libxul.so
#12 0x00007fdafb6bd9c6 in ?? () from /home/cbiesinger/firefox/libxul.so
#13 0x00007fdafbf145f5 in ?? () from /home/cbiesinger/firefox/libxul.so
#14 0x00007fdafbf16cbb in ?? () from /home/cbiesinger/firefox/libxul.so
#15 0x00007fdafbf17ba4 in ?? () from /home/cbiesinger/firefox/libxul.so
#16 0x00007fdafbeea36e in ?? () from /home/cbiesinger/firefox/libxul.so
#17 0x00007fdafbee9904 in ?? () from /home/cbiesinger/firefox/libxul.so
#18 0x00007fdafbcf1d75 in ?? () from /home/cbiesinger/firefox/libxul.so
#19 0x00007fdafb64da5c in XRE_main () from /home/cbiesinger/firefox/libxul.so
#20 0x0000000000401bc0 in ?? ()
#21 0x00007fdaf7c081c4 in __libc_start_main () from /lib/libc.so.6
#22 0x00000000004019b9 in ?? ()
#23 0x00007fff04c3f0f8 in ?? ()
#24 0x0000000000000000 in ?? ()


I'm going to attach my fastload files in a second.

Comment 1

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

Attachment: XPC.mfasl (gzipped)

This file is enough to trigger the crash, doesn't need XUL.mfasl

Comment 2

[(not currently active) Ted Mielczarek]

I think this might be the same crash:
http://crash-stats.mozilla.com/report/index/12d7497b-d66c-43ae-b731-89e4c2091030

Comment 3

[(not currently active) Ted Mielczarek]

Yeah, removing XPC.mfasl fixed my crash too.

Comment 4

[[e-mail]]

In my debug build, I hit the JS_ASSERT in js_NewScript (called from js_XDRScript) because length was 1 but the other values were bogus.

I didn't keep my XPC.mfl file from that build, although if necessary I have another crashing XPC.mfasl file that's not from a debuggable build.

Comment 5

[[e-mail]]

I now have an XPC.mfl and a debug build that crashes with it.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #2)
> I think this might be the same crash:
> http://crash-stats.mozilla.com/report/index/12d7497b-d66c-43ae-b731-89e4c2091030

I get the same crash on OS X with a more helpful stack: bp-818e8818-3bb5-43c6-967b-3a4fa2091101

First ten frames:
0  	 	@0xffff07d7  	
1 	libmozjs.dylib 	mem_getbytes 	js/src/jsxdrapi.cpp:129
2 	libmozjs.dylib 	JS_XDRBytes 	js/src/jsxdrapi.cpp:353
3 	libmozjs.dylib 	js_XDRScript 	js/src/jsscript.cpp:564
4 	libmozjs.dylib 	js_XDRFunctionObject 	js/src/jsfun.cpp:1657
5 	libmozjs.dylib 	js_XDRScript 	js/src/jsscript.cpp:642
6 	libmozjs.dylib 	JS_XDRScript 	js/src/jsxdrapi.cpp:684
7 	XUL 	mozJSComponentLoader::ReadScript 	js/src/xpconnect/loader/mozJSComponentLoader.cpp:455
8 	XUL 	mozJSComponentLoader::GlobalForLocation 	js/src/xpconnect/loader/mozJSComponentLoader.cpp:1200
9 	XUL 	mozJSComponentLoader::LoadModule 	js/src/xpconnect/loader/mozJSComponentLoader.cpp:703
10 	XUL 	nsFactoryEntry::GetFactory 	xpcom/components/nsComponentManager.cpp:3608

As given on bug 525693 it has been caused by one of the bugs in the tracemonkey merge:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ac98fd60de44&tochange=8af515171593

I will check with hg bisect to find the causing patch.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Starting my debug build will throw the following assertion which could be related to this crash:

Assertion failure: nsrcnotes == 1, at /Volumes/data/build/minefield/js/src/jsscript.cpp:1404

That line was added by Brendan's patch on bug 516827. I will do a check around this checkin.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #8)
> That line was added by Brendan's patch on bug 516827. I will do a check around
> this checkin.

I assumed this crash starts with the check-in of the mentioned patch on bug 516827.

Comment 10

[Jason Orendorff [:jorendorff]]

I bumped the XDR version number yesterday to try and fix this:

http://hg.mozilla.org/mozilla-central/rev/bde646815deb

17 crashes yesterday, none today so far.  I'll wait a few more hours before marking FIXED.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #10)
> 17 crashes yesterday, none today so far.  I'll wait a few more hours before
> marking FIXED.

I will check this fix once we have new trunk builds for OS X. Due to bug 470450 the build process failed in make_pkg.

Comment 13

[philippe (part-time)]

(In reply to comment #10)
> I bumped the XDR version number yesterday to try and fix this:
> 
> http://hg.mozilla.org/mozilla-central/rev/bde646815deb

That doesn't seem to fix the problem here -- with my normal user profile. With a freshly built Minefield (@/rev/8ff817d76d2a) I still get the crash.

STR
1. launch fresh build. Success
2. Quit, then re-launch.

AR: browser loads, and within a few seconds, crashes. Removing XPC.mfasl resolves the issue.

I can't seem to repro the issue with a default profile. My normal profile has Firebug & Dom Inspector installed. If I remove every trace of Firebug out of my profile (and nuke extensions.cache and extensions.init files), then the crash goes away.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #13)
> I can't seem to repro the issue with a default profile. My normal profile has
> Firebug & Dom Inspector installed. If I remove every trace of Firebug out of my

Which version of Firebug are you using? I don't get a crash with  firebug-1.5X.0b1.xpi.

Comment 15

[philippe (part-time)]

firebug-1.5X.0b1.xpi

OS X 10.5.8 intel if it matters.

I put Firebug on the default profile, and started with the 11.02 build, then with the build in comment 13. Same story. I'll test again with the next nightly, once it is out (those builds are getting later and later...).

Comment 16

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I can also still reproduce the crash with Firebug 1.5X.0b1 + DOM Inspector 2.0.3
(Windows Vista)

See my comment here:
https://bugzilla.mozilla.org/show_bug.cgi?id=526214#c3

Honza

Comment 17

[philippe (part-time)]

With the 1104 OS X build, I still get the same crash on my 'normal' profile.
However, I did something else: created a brand new profile with the known broken 1102 build. Copied my important files (permissions.sqlite, 8 years worth of blocked adservers cookies), then installed Firebug and DomInspector and upgraded to the 1104 build.
No crashes so far. I'll need to verify this when I upgrade to the next nightly...

Comment 18

[Brendan Eich [:brendan]]

(In reply to comment #10)
> I bumped the XDR version number yesterday to try and fix this:
> 
> http://hg.mozilla.org/mozilla-central/rev/bde646815deb

The patch for bug 516827,

http://hg.mozilla.org/tracemonkey/rev/60ec3940a434

revised both JSXDR_BYTECODE_VERSION and JSXDR_MAGIC_SCRIPT_CURRENT. Now we have the former "one ahead" on m-c compared to tm, which could make for a bug where tm changes bump the subtrahend once and the conflict with m-c is resolved incorrectly, leaving m-c users without a needed invalidation.

Taking this bug. It's making me itchy.

/be

Comment 19

[Brendan Eich [:brendan]]

This bug is so dumb (i.e., I am so dumb). The emptyScript XDR optimization does not strictly decode according to what was encoded -- it uses a flag from the decode caller specifying whether it wants a mutable script. If we encode an empty script singleton but decode wanting a mutable script, we read junk words from the XDR stream. D'oh!

The encoder must not write the singleton shorthand if it is serializing a mutable empty script.

/be

Comment 20

[Brendan Eich [:brendan]]

It's not as simple as comment 19 suggests (maybe I'm less dumb but not really :-|) because we encode the empty script shorthand only with this assertion:

    if (length == 1) {
        if (xdr->mode == JSXDR_ENCODE) {
            JS_ASSERT(*scriptp == JSScript::emptyScript());
            return JS_TRUE;
        }

So it must be the case that encoder has the const shared singleton but decoder wants a mutable unshared empty script. I didn't expect that but it's a degree of freedom in the API. I will adjust js_XDRScript to cope.

/be

Comment 21

[Brendan Eich [:brendan]]

Thanks to neil for comment 4 which pointed the problem out directly.

/be

Comment 23

[Mike Shaver (:shaver emeritus)]

I don't think this needs to be sec-sensitive; I don't see a reason for it here, and the bug is trunk-only, unshipped, and requires control over the XDR data to exploit if that's even possible.  Brendan agrees, so opening.

Comment 24

[Brendan Eich [:brendan]]

Attachment: fix, with jsapi-test coverage

Comment 26

[Brendan Eich [:brendan]]

(Yes, I enabled JS_HAS_SCRIPT_OBJECT and JS_HAS_XDR_FREEZE_THAW and found some bitrotted code; fixed here while I was trying to use Script objects to test, even though I ended up writing a jsapi-test.)

Comment 27

[timeless]

brendan, not to be a nag, but in BEGIN_TEST(testXDR_bug525481), frozen = malloc(...) should really use JS_malloc(cx, ...) as JS_XDRDestroy uses cx->free.

this helps people who read sample code follow things and it also means that someone using the test against a spidermonkey linked with a different allocator don't die.

Comment 28

[Brendan Eich [:brendan]]

Timeless, no worries -- I copied that test from another such test. But cx->malloc seems possible since we are inside the public-API firewall. Jorendorff may have an opinion.

/be

Comment 29

[Brendan Eich [:brendan]]

Attachment: forgot an important change, caught be earlier XDR jsapi-test

The jsapi-tests rock!

I used JS_malloc per timeless's API nagging ;-).

/be

Comment 30

[Brendan Eich [:brendan]]

http://hg.mozilla.org/tracemonkey/rev/b40d8ad51e0e

/be

Comment 31

[[not reading bugmail]]

be, would this fix bug 525661 also?

Comment 34

[Brendan Eich [:brendan]]

Fixed on m-c to relieve SeaMonkey and other folks.

http://hg.mozilla.org/mozilla-central/rev/876ee5081604

/be

Comment 35

[Daniel Holbert [:dholbert]]

Looks like this checkin caused orange on the "Mochitests 4/5" column for all three platforms, both debug & opt.

The failure looks like this:
{
80 ERROR TEST-UNEXPECTED-FAIL | /tests/js/jsd/test/test_bug507448.html | [SimpleTest/SimpleTest.js, window.onerror] An error occurred - jsd.wrapValue(f).script is null at http://localhost:8888/tests/js/jsd/test/test_bug507448.html:54
TEST-UNEXPECTED-FAIL | automation.py | Exited with code -1073741819 during test run
TEST-UNEXPECTED-FAIL | automation.py | application crashed (minidump found)
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | missing output line for total leaks!
}

Linux:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257625724.1257626027.27212.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257623451.1257623569.32621.gz

Mac:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257625336.1257625548.21858.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257625830.1257625969.26557.gz

Windows:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257626169.1257626351.30577.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257626257.1257626689.1793.gz

Comment 36

[Robert Sayre]

erm yeah, we've got that on tracemonkey as well, same test. didn't spot it earlier, sorry.

Comment 40

[Ria Klaassen (not reading all bugmail)]

This bug is crashing some of my extensions e.g. Dictionary Search https://addons.mozilla.org/en-US/firefox/addon/68

Comment 41

[Jesper Hansen]

Reference bug for extensions and other things crashing due to this patch see bug 527261

Comment 42

[Henrik Skupin [:whimboo][⌚️UTC+1]]

No crash anymore with a trunk build on Linux and OS X like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091109 Minefield/3.7a1pre ID:20091109034249

Comment 43

[[e-mail]]

Fixed for me.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091109 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20091109043812

Comment 44

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/b40d8ad51e0e