1004480 - Assertion failure: data.s.payload.why == why, at js/Value.h:1095 or Crash [@ argumentsVarIndex]

Status: RESOLVED DUPLICATE of bug 1004527

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision b227a707080f (run with --fuzzing-safe):


setJitCompilerOption("ion.usecount.trigger", 30);
var PointType = TypedObject.uint16.array(3);
var VecPointType = PointType.array(3);
  for (var i = 0; i < 5000; i += 10) {
    var vec = new VecPointType();
    var i0 = i % 3;
    vec[i0][new Function("ABCDEFGHIJK", "1234")];
}

Comment 1

[Christian Holler (:decoder)]

Crash trace:


Program received signal SIGSEGV, Segmentation fault.
argumentsVarIndex (bindings=..., cx=0x9217208) at js/src/jsscript.cpp:71
71          while (bi->name() != arguments)
(gdb) bt
#0  argumentsVarIndex (bindings=..., cx=0x9217208) at js/src/jsscript.cpp:71
#1  js::SetFrameArgumentsObject (cx=0x9217208, frame=..., script=..., argsobj=0xf6643910) at js/src/jsscript.cpp:3481
#2  0x0836a18f in JSScript::argumentsOptimizationFailed (cx=0x9217208, script=...) at js/src/jsscript.cpp:3572
#3  0x081b3a5b in GetElemOptimizedArguments (done=<synthetic pointer>, res=..., rref=..., lref=..., frame=..., cx=0x9217208) at js/src/vm/Interpreter-inl.h:416
#4  js::jit::DoGetElemFallback (cx=0x9217208, frame=0xffffbecc, stub_=0x92e04b8, lhs=..., rhs=..., res=...) at js/src/jit/BaselineIC.cpp:4021
#5  0xf7aeaaeb in ?? ()
#6  0xf7ae585a in ?? ()
(gdb) x /i $pc
=> 0x8369d62 <js::SetFrameArgumentsObject(JSContext*, js::AbstractFramePtr, JS::Handle<JSScript*>, JSObject*)+66>:      mov    (%esi,%edx,4),%eax
(gdb) info reg esi edx eax
esi            0x92c5a28        153901608
edx            0x1c176  115062
eax            0x0      0


The crash above only reproduced in a less-reduced version of the test, that was very fragile. The assertion seemed to be much more stable. Marking s-s and sec-critical based due to possible memory corruption.

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
=== Tinderbox Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20140424014842" and the hash "25dd3d17a19a".
The "bad" changeset has the timestamp "20140424020245" and the hash "079f4f0ed6a6".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=25dd3d17a19a&tochange=079f4f0ed6a6

Comment 3

[Christian Holler (:decoder)]

More fallout from shu's patch, setting needinfo :)

Comment 4

[Shu-yu Guo [:shu]]

Fixed by bug in 1004527

Comment 5

[Shu-yu Guo [:shu]]

s/bug in/patch in/

Comment 6

[Al Billings [:abillings - ex-MoCo]]

[Tracking Requested - why for this release]:

Are we going to backport this to ESR31 since it is a sec-critical?

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Well, esr31.1 has been built and QA has already signed off...
Next one?

Comment 8

[Andrew McCreight [:mccr8]]

TypedObject is Nightly-only, so there's no need to backport to ESR or anywhere.