Closed
Bug 1263870
Opened 8 years ago
Closed 8 years ago
Crash [@ ResolveModule] with OOM and wasm
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla48
Tracking | Status | |
---|---|---|
firefox48 | --- | fixed |
People
(Reporter: decoder, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: assertion, testcase, Whiteboard: [jsbugmon:update])
Crash Data
Attachments
(1 file)
The following testcase crashes on mozilla-central revision 29d5a4175c8b (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-debug, run with --fuzzing-safe --ion-offthread-compile=off): oomTest(function() { g = newGlobal().eval("( wasmTextToBinary('(module (func) (export \"\" 0))'));"); }); Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x08230090 in ResolveModule (lifo=..., module=module@entry=0xeca2a010, error=error@entry=0xffffabb0) at js/src/asmjs/WasmTextToBinary.cpp:3565 #0 0x08230090 in ResolveModule (lifo=..., module=module@entry=0xeca2a010, error=error@entry=0xffffabb0) at js/src/asmjs/WasmTextToBinary.cpp:3565 #1 0x08232f21 in js::wasm::TextToBinary (text=text@entry=0xeca29540 u"(module (func) (export \"\" 0))", bytes=bytes@entry=0xffffac00, error=error@entry=0xffffabb0) at js/src/asmjs/WasmTextToBinary.cpp:4225 #2 0x0886850b in WasmTextToBinary (cx=0xf7a79020, argc=1, vp=0xf42270b8) at js/src/builtin/TestingFunctions.cpp:535 #3 0x0871e30a in js::CallJSNative (cx=0xf7a79020, native=0x8868360 <WasmTextToBinary(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235 #4 0x0871a79d in js::Invoke (cx=0xf7a79020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:476 #5 0x0870a38a in Interpret (cx=cx@entry=0xf7a79020, state=...) at js/src/vm/Interpreter.cpp:2807 #6 0x0871a51f in js::RunScript (cx=cx@entry=0xf7a79020, state=...) at js/src/vm/Interpreter.cpp:426 #7 0x0871d30d in js::ExecuteKernel (cx=cx@entry=0xf7a79020, script=..., script@entry=..., scopeChainArg=..., newTargetValue=..., evalInFrame=evalInFrame@entry=..., result=0xffffb580) at js/src/vm/Interpreter.cpp:682 #8 0x084c5d2b in EvalKernel (cx=cx@entry=0xf7a79020, args=..., evalType=evalType@entry=INDIRECT_EVAL, caller=caller@entry=..., scopeobj=..., scopeobj@entry=..., pc=pc@entry=0x0) at js/src/builtin/Eval.cpp:332 #9 0x084c6541 in js::IndirectEval (cx=0xf7a79020, argc=1, vp=0xffffb580) at js/src/builtin/Eval.cpp:421 #10 0x0871e30a in js::CallJSNative (cx=0xf7a79020, native=0x84c6470 <js::IndirectEval(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235 #11 0x0871a79d in js::Invoke (cx=0xf7a79020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:476 #12 0x0871bf4a in js::Invoke (cx=cx@entry=0xf7a79020, thisv=..., fval=..., argc=1, argv=0xffffbaa0, rval=...) at js/src/vm/Interpreter.cpp:528 #13 0x0863c272 in js::DirectProxyHandler::call (this=this@entry=0x98dbef4 <js::CrossCompartmentWrapper::singleton>, cx=cx@entry=0xf7a79020, proxy=..., proxy@entry=..., args=...) at js/src/proxy/DirectProxyHandler.cpp:77 #14 0x0864361d in js::CrossCompartmentWrapper::call (this=0x98dbef4 <js::CrossCompartmentWrapper::singleton>, cx=0xf7a79020, wrapper=..., args=...) at js/src/proxy/CrossCompartmentWrapper.cpp:291 #15 0x0864041a in js::Proxy::call (cx=cx@entry=0xf7a79020, proxy=proxy@entry=..., args=...) at js/src/proxy/Proxy.cpp:390 #16 0x086404ba in js::proxy_Call (cx=0xf7a79020, argc=1, vp=0xffffba90) at js/src/proxy/Proxy.cpp:682 #17 0x0871e30a in js::CallJSNative (cx=0xf7a79020, native=0x8640440 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235 #18 0x0871a79d in js::Invoke (cx=cx@entry=0xf7a79020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:476 #19 0x0827fc23 in js::jit::DoCallFallback (cx=0xf7a79020, frame=0xffffbad8, stub_=0xf7a91108, argc=1, vp=0xffffba90, res=...) at js/src/jit/BaselineIC.cpp:6115 #20 0xf7fcedce in ?? () #21 0xf7a91108 in ?? () #22 0xf7fc8c5c in ?? () #23 0x0825cd1a in EnterBaseline (cx=0xf7a91108, cx@entry=0xf7a79020, data=...) at js/src/jit/BaselineJIT.cpp:150 #24 0x0827ab9e in js::jit::EnterBaselineMethod (cx=cx@entry=0xf7a79020, state=...) at js/src/jit/BaselineJIT.cpp:188 #25 0x0871a5bb in js::RunScript (cx=cx@entry=0xf7a79020, state=...) at js/src/vm/Interpreter.cpp:416 #26 0x0871a7fa in js::Invoke (cx=0xf7a79020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:494 #27 0x0871bf4a in js::Invoke (cx=cx@entry=0xf7a79020, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0x0, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:528 #28 0x08556d30 in JS_CallFunction (cx=cx@entry=0xf7a79020, obj=..., fun=fun@entry=..., args=..., rval=rval@entry=...) at js/src/jsapi.cpp:2865 #29 0x0886737b in OOMTest (cx=0xf7a79020, argc=1, vp=0xf4227058) at js/src/builtin/TestingFunctions.cpp:1311 [...] #42 main (argc=4, argv=0xffffcce4, envp=0xffffccf8) at js/src/shell/js.cpp:7443 eax 0x0 0 ebx 0x98a9314 160076564 ecx 0xeca2a010 -324886512 edx 0x0 0 esi 0x0 0 edi 0xeca2a010 -324886512 ebp 0xffffaa38 4294945336 esp 0xffffa880 4294944896 eip 0x8230090 <ResolveModule(js::LifoAlloc&, (anonymous namespace)::WasmAstModule*, JS::UniqueChars*)+688> => 0x8230090 <ResolveModule(js::LifoAlloc&, (anonymous namespace)::WasmAstModule*, JS::UniqueChars*)+688>: mov (%eax),%edx 0x8230092 <ResolveModule(js::LifoAlloc&, (anonymous namespace)::WasmAstModule*, JS::UniqueChars*)+690>: mov 0x4(%eax),%eax
Updated•8 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Comment 1•8 years ago
|
||
JSBugMon: Bisection requested, result: === Treeherder Build Bisection Results by autoBisect === The "good" changeset has the timestamp "20160125120427" and the hash "de1139d08196dff16e5d4394f4825feba873b027". The "bad" changeset has the timestamp "20160125121325" and the hash "da0f696b3cae671bfc96af326b45f9be247e2ee9". Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=de1139d08196dff16e5d4394f4825feba873b027&tochange=da0f696b3cae671bfc96af326b45f9be247e2ee9
Comment 2•8 years ago
|
||
Looking.
Comment 3•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/47165/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/47165/
Attachment #8742369 -
Flags: review?(luke)
Updated•8 years ago
|
Attachment #8742369 -
Flags: review?(luke) → review+
Comment 4•8 years ago
|
||
Comment on attachment 8742369 [details] MozReview Request: Bug 1263870: Check allocation in WasmAstModule::declare; r?luke https://reviewboard.mozilla.org/r/47165/#review43711
Comment 6•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c2239c623e86
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in
before you can comment on or make changes to this bug.
Description
•