Closed
Bug 674843
Opened 13 years ago
Closed 13 years ago
TM: Assertion failure: (ptrBits & 0x7) == 0 or Crash [@ js::gc::ArenaHeader::allocated]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
mozilla8
Tracking | Status | |
---|---|---|
firefox8 | --- | fixed |
firefox9 | --- | fixed |
firefox10 | --- | fixed |
firefox11 | --- | fixed |
status1.9.2 | --- | unaffected |
People
(Reporter: decoder, Assigned: luke)
References
Details
(4 keywords, Whiteboard: [sg:critical][js-triage-done][qa!])
Crash Data
Attachments
(2 files)
1.63 KB,
application/javascript
|
Details | |
1.93 KB,
patch
|
Waldo
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•13 years ago
|
||
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 | ||
Comment 2•13 years ago
|
||
This should be fixed on beta/aurora.
Updated•13 years ago
|
Whiteboard: js-triage-needed → js-triage-done
Updated•13 years ago
|
Attachment #549143 -
Flags: review?(jwalden+bmo) → review+
Assignee | ||
Comment 3•13 years ago
|
||
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?
Assignee | ||
Comment 4•13 years ago
|
||
Whiteboard: js-triage-done → [js-triage-done][inbound]
Assignee | ||
Comment 5•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Whiteboard: [js-triage-done][inbound] → [js-triage-done]
Target Milestone: --- → mozilla8
Assignee | ||
Updated•13 years ago
|
status1.9.2:
--- → unaffected
Updated•13 years ago
|
Blocks: 644074
status-firefox10:
--- → fixed
status-firefox11:
--- → fixed
status-firefox8:
--- → fixed
status-firefox9:
--- → fixed
Keywords: regression
Whiteboard: [js-triage-done] → [sg:critical][js-triage-done]
Whiteboard: [sg:critical][js-triage-done] → [sg:critical][js-triage-done][qa+]
Comment 7•13 years ago
|
||
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?
Reporter | ||
Comment 8•13 years ago
|
||
(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 :)
Assignee | ||
Comment 9•13 years ago
|
||
Not only has the tracer been removed, but also the Invoke gatling gun. Nothing to verify.
Comment 10•13 years ago
|
||
QA- given comment 9.
Whiteboard: [sg:critical][js-triage-done][qa+] → [sg:critical][js-triage-done][qa-]
Comment 11•13 years ago
|
||
Thanks Luke. Given the platform field, is this issue really Linux64 only or does it span all platforms?
Comment 12•13 years ago
|
||
(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+]
Reporter | ||
Comment 13•13 years ago
|
||
(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.
Updated•13 years ago
|
Group: core-security
Comment 14•13 years ago
|
||
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!
Reporter | ||
Comment 15•13 years ago
|
||
(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 :)
Comment 16•13 years ago
|
||
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
Updated•13 years ago
|
Whiteboard: [sg:critical][js-triage-done][qa+] → [sg:critical][js-triage-done][qa!]
Updated•13 years ago
|
Keywords: verified-beta
Reporter | ||
Comment 17•12 years ago
|
||
Automatically extracted testcase for this bug was committed:
https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•