Closed Bug 1004480 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: JavaScript Engine, defect, critical)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1004527
Tracking Status
firefox31 --- disabled
firefox32 + fixed
firefox-esr31 --- disabled

People

(Reporter: decoder, Unassigned)

References

Details

(5 keywords, Whiteboard: [jsbugmon:update][adv-main32+])

Crash Data

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")];
}
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.
Crash Signature: [@ argumentsVarIndex]
Keywords: crash, sec-critical
Whiteboard: [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
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
More fallout from shu's patch, setting needinfo :)
Flags: needinfo?(shu)
Fixed by bug in 1004527
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(shu)
Resolution: --- → DUPLICATE
Duplicate of bug: 1004527
s/bug in/patch in/
[Tracking Requested - why for this release]:

Are we going to backport this to ESR31 since it is a sec-critical?
Whiteboard: [jsbugmon:update] → [jsbugmon:update][adv-main32+]
Well, esr31.1 has been built and QA has already signed off...
Next one?
TypedObject is Nightly-only, so there's no need to backport to ESR or anywhere.
Group: core-security
You need to log in before you can comment on or make changes to this bug.