If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Crash [@ ResolveModule] with OOM and wasm

RESOLVED FIXED in Firefox 48

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: decoder, Unassigned)

Tracking

(Blocks: 2 bugs, {assertion, testcase})

Trunk
mozilla48
x86
Linux
assertion, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox48 fixed)

Details

(Whiteboard: [jsbugmon:update], crash signature)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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

2 years ago
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]

Comment 1

2 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
Looking.
Created attachment 8742369 [details]
MozReview Request: Bug 1263870: Check allocation in WasmAstModule::declare; r?luke

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

a year ago
Attachment #8742369 - Flags: review?(luke) → review+
Comment on attachment 8742369 [details]
MozReview Request: Bug 1263870: Check allocation in WasmAstModule::declare; r?luke

https://reviewboard.mozilla.org/r/47165/#review43711

Comment 5

a year ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/c2239c623e86

Comment 6

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/c2239c623e86
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox48: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.