The attached test asserts on mozilla-central revision d066929dd830 (run with options -j -m). Stepping through the assertions will cause a crash: Program received signal SIGSEGV, Segmentation fault. 0x0000000000413b6e in js::gc::ArenaHeader::allocated (this=0x7fca00180000) at ./jsgc.h:261 261 return thingKind < FINALIZE_LIMIT; (gdb) bt 16 #0 0x0000000000413b6e in js::gc::ArenaHeader::allocated (this=0x7fca00180000) at ./jsgc.h:261 #1 0x0000000000413b92 in js::gc::ArenaHeader::getThingKind (this=0x7fca00180000) at ./jsgc.h:271 #2 0x00000000004b7588 in js::gc::GetGCThingTraceKind (thing=0x7fca00180202) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgcinlines.h:110 #3 0x00000000004c64fc in js::gc::MarkKind (trc=0x7fffdeba5180, thing=0x7fca00180202, kind=0) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgcmark.cpp:332 #4 0x000000000042e3c8 in JS_CallTracer (trc=0x7fffdeba5180, thing=0x7fca00180202, kind=0) at /home/decoder/LangFuzz/mozilla-central/js/src/jsapi.cpp:2184 #5 0x00000000004a2a08 in exn_trace (trc=0x7fffdeba5180, obj=0x7fcaadb00598) at /home/decoder/LangFuzz/mozilla-central/js/src/jsexn.cpp:417 #6 0x00000000004c7467 in ScanObject (gcmarker=0x7fffdeba5180, obj=0x7fcaadb00598) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgcmark.cpp:628 #7 0x00000000004c7cc3 in js::GCMarker::drainMarkStack (this=0x7fffdeba5180) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgcmark.cpp:791 #8 0x00000000004b4e7f in MarkAndSweep (cx=0x2400dd0, comp=0x0, gckind=GC_NORMAL, gcTimer=@0x7fffdeba53d0) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgc.cpp:2273 #9 0x00000000004b5632 in GCCycle (cx=0x2400dd0, comp=0x0, gckind=GC_NORMAL, gcTimer=@0x7fffdeba53d0) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgc.cpp:2641 #10 0x00000000004b5917 in js_GC (cx=0x2400dd0, comp=0x0, gckind=GC_NORMAL) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgc.cpp:2727 #11 0x00000000004b3111 in RunLastDitchGC (cx=0x2400dd0) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgc.cpp:1349 #12 0x00000000004b5fdb in js::gc::RunDebugGC (cx=0x2400dd0) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgc.cpp:2902 #13 0x000000000054e928 in NewGCThing<js::Shape> (cx=0x2400dd0, thingKind=13, thingSize=64) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgcinlines.h:203 #14 0x000000000054e3c4 in js_NewGCShape (cx=0x2400dd0) at /home/decoder/LangFuzz/mozilla-central/js/src/jsgcinlines.h:255 #15 0x000000000054cffe in js::PropertyTree::newShape (this=0x24016c0, cx=0x2400dd0) at /home/decoder/LangFuzz/mozilla-central/js/src/jspropertytree.cpp:70 (More stack frames follow...) (gdb) x /4i $pc 0x413b6e <_ZNK2js2gc11ArenaHeader9allocatedEv+12>: mov 0x14(%rax),%eax 0x413b71 <_ZNK2js2gc11ArenaHeader9allocatedEv+15>: cmp $0x11,%eax 0x413b74 <_ZNK2js2gc11ArenaHeader9allocatedEv+18>: setbe %al 0x413b77 <_ZNK2js2gc11ArenaHeader9allocatedEv+21>: leaveq (gdb) info reg rax rax 0x7fca00180000 140505561694208 Bisect shows: Changeset 68865:e9da34dfa8c5: bad The first bad revision is: changeset: 68865:e9da34dfa8c5 parent: 68610:28bc239d3d9d user: Luke Wagner date: Wed Apr 13 09:27:37 2011 -0700 summary: Bug 644074 - Simplify and consolidate VM stack code into js/src/vm/Stack* S-s because of possibly gc-related memory corruption.
There are two bugs which together conspire to make this a crash: - StackIter isn't correctly censoring pushed-but-not-active InvokeSessionGuard frames - InvokeSessionGuard::start is leaving pushed-but-not-active frame args uninitialized This fixes them both. I'm going to file a bug to consider ripping out the InvokeSessionGuard; its just too unnatural and this isn't the first bug with it.
Assignee: general → luke
Status: NEW → ASSIGNED
Attachment #549143 - Flags: review?(jwalden+bmo)
This should be fixed on beta/aurora.
Attachment #549143 - Flags: review?(jwalden+bmo) → review+
So I don't know whether to request approval for aurora/beta. This is technically exploitable (trash values viewed as jsvals), but it requires some pretty big coincidences to even observe weirdness, much less crash. So it comes down to: what is our policy for this class of bugs? In 2 weeks, this will be released, should we wait 14 weeks for it to bubble from m-c to release? Land on aurora and wait 8 weeks?
Whiteboard: js-triage-done → [js-triage-done][inbound]
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [js-triage-done][inbound] → [js-triage-done]
Target Milestone: --- → mozilla8
Whiteboard: [sg:critical][js-triage-done] → [sg:critical][js-triage-done][qa+]
Luke and Christian, how can I verify this on nightly? There is no -j option available anymore. Do I have to use another option instead?
(In reply to Henrik Skupin (:whimboo) from comment #7) > Luke and Christian, how can I verify this on nightly? There is no -j option > available anymore. Do I have to use another option instead? I assume there is no way to test this on nightly as the test in comment 0 only worked with TM which has been removed in nightly. Even if the underlying bug is not TM specific, there is no easy way to derive a test that doesn't require TM anymore. Maybe Luke can confirm this :)
Not only has the tracer been removed, but also the Invoke gatling gun. Nothing to verify.
QA- given comment 9.
Whiteboard: [sg:critical][js-triage-done][qa+] → [sg:critical][js-triage-done][qa-]
Thanks Luke. Given the platform field, is this issue really Linux64 only or does it span all platforms?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #10) > QA- given comment 9. The answer from Luke only applies to trunk but not the branches. We still have to verify the fix for beta and aurora.
Whiteboard: [sg:critical][js-triage-done][qa-] → [sg:critical][js-triage-done][qa+]
(In reply to Henrik Skupin (:whimboo) from comment #11) > Thanks Luke. Given the platform field, is this issue really Linux64 only or > does it span all platforms? I can't tell you for this specific bug, but in general I set the OS/Architecture to the combination I have been using for the testcase. Some tests only work under 64 bit (even if the underlying issue is also on 32 bit). That combination is sometimes relevant to be able to reproduce, but it does not necessarily indicate the bug is restricted to that.
Running the following command on Ubuntu 11.04 32 bit: ./js -m -j testcase where: - js is the jsshell from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/08/2011-08-03-03-07-53-mozilla-central/ or http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/08/2011-08-04-03-07-32-mozilla-central/ - testcase is a file containing the test case from comment #0 results in testcase:58: ReferenceError: gczeal is not defined. Can you please suggest other environment/setup which is valid to run the test? Thank you!
(In reply to Mihaela Velimiroviciu [QA] from comment #14) > results in testcase:58: ReferenceError: gczeal is not defined. The testcase will only work in builds of the JS shell that have gczeal enabled (e.g. debug builds). If you want to run this test, then I guess you will have to build JS debug shells for the revisions you would like to test. See also https://developer.mozilla.org/En/SpiderMonkey/Build_Documentation under "Advanced" build (just ignore the "build-release" block and go for the debug build there). Let me know if you need further help with this :)
I only tested on beta, which was aurora as per comment 12. Former beta got into release. I got the beta source with the latest revision (mozilla-beta-9be810857183) and built the js debug shell. After running the testcase no error messages appear, so marking this as VERIFIED. Built on Ubuntu 11.04 x86, autoconf v 2.13.
Status: RESOLVED → VERIFIED
Whiteboard: [sg:critical][js-triage-done][qa+] → [sg:critical][js-triage-done][qa!]
Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
You need to log in before you can comment on or make changes to this bug.