Last Comment Bug 674843 - TM: Assertion failure: (ptrBits & 0x7) == 0 or Crash [@ js::gc::ArenaHeader::allocated]
: TM: Assertion failure: (ptrBits & 0x7) == 0 or Crash [@ js::gc::ArenaHeader::...
Status: VERIFIED FIXED
[sg:critical][js-triage-done][qa!]
: assertion, regression, testcase, verified-beta
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- critical (vote)
: mozilla8
Assigned To: Luke Wagner [:luke]
:
: Jason Orendorff [:jorendorff]
Mentors:
: 676760 (view as bug list)
Depends on:
Blocks: langfuzz 644074 676486
  Show dependency treegraph
 
Reported: 2011-07-28 02:32 PDT by Christian Holler (:decoder)
Modified: 2013-01-19 14:00 PST (History)
13 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
fixed
fixed
fixed
unaffected


Attachments
Test case for shell (run with -j -m) (1.63 KB, application/javascript)
2011-07-28 02:32 PDT, Christian Holler (:decoder)
no flags Details
fix (1.93 KB, patch)
2011-07-28 09:32 PDT, Luke Wagner [:luke]
jwalden+bmo: review+
Details | Diff | Splinter Review

Description Christian Holler (:decoder) 2011-07-28 02:32:26 PDT
Created attachment 549047 [details]
Test case for shell (run with -j -m)

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.
Comment 1 Luke Wagner [:luke] 2011-07-28 09:32:40 PDT
Created attachment 549143 [details] [diff] [review]
fix

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.
Comment 2 Luke Wagner [:luke] 2011-07-28 09:36:37 PDT
This should be fixed on beta/aurora.
Comment 3 Luke Wagner [:luke] 2011-08-01 15:26:12 PDT
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?
Comment 5 Luke Wagner [:luke] 2011-08-03 10:23:07 PDT
http://hg.mozilla.org/mozilla-central/rev/8bff20b3f8db
Comment 6 Luke Wagner [:luke] 2011-08-05 09:27:45 PDT
*** Bug 676760 has been marked as a duplicate of this bug. ***
Comment 7 Henrik Skupin (:whimboo) 2011-12-16 06:17:19 PST
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?
Comment 8 Christian Holler (:decoder) 2011-12-16 06:40:21 PST
(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 :)
Comment 9 Luke Wagner [:luke] 2011-12-16 11:42:53 PST
Not only has the tracer been removed, but also the Invoke gatling gun.  Nothing to verify.
Comment 10 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-12-16 11:59:56 PST
QA- given comment 9.
Comment 11 Henrik Skupin (:whimboo) 2011-12-16 12:27:47 PST
Thanks Luke. Given the platform field, is this issue really Linux64 only or does it span all platforms?
Comment 12 Henrik Skupin (:whimboo) 2011-12-16 12:38:41 PST
(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.
Comment 13 Christian Holler (:decoder) 2011-12-16 13:09:21 PST
(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.
Comment 14 Mihaela Velimiroviciu (:mihaelav) 2012-01-24 08:23:56 PST
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!
Comment 15 Christian Holler (:decoder) 2012-01-24 09:37:36 PST
(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 Remus Pop (:RemusPop) 2012-01-25 02:51:47 PST
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.
Comment 17 Christian Holler (:decoder) 2013-01-19 14:00:44 PST
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929

Note You need to log in before you can comment on or make changes to this bug.