The default bug view has changed. See this FAQ.

Crash [@ mozilla::PodCopy<int>] with OOM

RESOLVED FIXED in Firefox 44

Status

()

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

People

(Reporter: decoder, Assigned: lth)

Tracking

(Blocks: 3 bugs, {crash, regression, testcase})

Trunk
mozilla44
ARM
Linux
crash, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42 affected, firefox44 fixed)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
The following testcase crashes on mozilla-central revision 2ddec2dedced (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-simulator=arm --enable-debug, run with --fuzzing-safe --thread-count=2 --arm-hwcap=vfp):

oomTest(((function() {
  try {
    gczeal(2)(uneval(this))
  } catch(e) {}
})));
function oomTest(f) {
    var i = 1;
    do {
        try {
            oomAtAllocation(i);
            f();
        } catch (e) {}
        more = resetOOMFailure();
        i++;
    } while(more);
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
mozilla::PodCopy<int> (aDst=0x0, aSrc=0xf7a9c090, aNElem=7) at ../../dist/include/mozilla/PodOperations.h:107
#0  mozilla::PodCopy<int> (aDst=0x0, aSrc=0xf7a9c090, aNElem=7) at ../../dist/include/mozilla/PodOperations.h:107
#1  0x086d2f3d in insertEntry (lifoAlloc=..., off=..., data=0xffffa4ec "4\"\240", <incomplete sequence \367>, num=1, this=0xffffac08) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:225
#2  js::jit::AssemblerBufferWithConstantPools<1024u, 4u, js::jit::Instruction, js::jit::Assembler>::insertEntryForwards (this=this@entry=0xffffabb8, numInst=numInst@entry=1, numPoolEntries=numPoolEntries@entry=1, inst=inst@entry=0xffffa4c0 "", data=data@entry=0xffffa4ec "4\"\240", <incomplete sequence \367>) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:555
#3  0x086904ce in js::jit::AssemblerBufferWithConstantPools<1024u, 4u, js::jit::Instruction, js::jit::Assembler>::allocEntry (this=this@entry=0xffffabb8, inst=inst@entry=0xffffa4c0 "", data=data@entry=0xffffa4ec "4\"\240", <incomplete sequence \367>, pe=pe@entry=0x0, markAsBranch=markAsBranch@entry=false, numPoolEntries=1, numInst=1) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:592
#4  0x086906f8 in js::jit::Assembler::as_Imm32Pool (this=this@entry=0xffffa9bc, dest=dest@entry=..., value=value@entry=4154466868, c=c@entry=js::jit::Assembler::Always) at js/src/jit/arm/Assembler-arm.cpp:1815
#5  0x08697a4b in js::jit::MacroAssemblerARM::ma_movPatchable (this=0xffffa9bc, imm_=imm_@entry=..., dest=dest@entry=..., c=c@entry=js::jit::Assembler::Always, rs=js::jit::Assembler::L_LDR) at js/src/jit/arm/MacroAssembler-arm.cpp:446
#6  0x08698067 in ma_movPatchable (rs=<optimized out>, c=js::jit::Assembler::Always, dest=..., imm=..., this=0xffffa9bc) at js/src/jit/arm/MacroAssembler-arm.cpp:455
#7  js::jit::MacroAssemblerARM::ma_call (this=this@entry=0xffffa9bc, dest=dest@entry=...) at js/src/jit/arm/MacroAssembler-arm.cpp:3705
#8  0x086adea4 in js::jit::MacroAssemblerARMCompat::callWithABI (this=this@entry=0xffffa9bc, fun=0xf7a02234, fun@entry=0x85bd2c0 <AssumeUnreachable_(char const*)>, result=result@entry=js::jit::MoveOp::GENERAL) at js/src/jit/arm/MacroAssembler-arm.cpp:4116
#9  0x0862201d in callWithABI<void*> (result=js::jit::MoveOp::GENERAL, fun=<optimized out>, this=0xffffa9bc) at js/src/jit/MacroAssembler.h:1008
#10 js::jit::MacroAssembler::assumeUnreachable (this=this@entry=0xffffa9bc, output=output@entry=0x8b2ac68 "BaselineFrame shouldn't override pc when executing JIT code") at js/src/jit/MacroAssembler.cpp:1806
#11 0x0871f5b5 in js::jit::BaselineCompilerShared::callVM (this=this@entry=0xffffa9b0, fun=..., phase=js::jit::BaselineCompilerShared::POST_INITIALIZE) at js/src/jit/shared/BaselineCompiler-shared.cpp:74
#12 0x084a2e8b in callVMNonOp (phase=<optimized out>, fun=..., this=0xffffa9b0) at js/src/jit/shared/BaselineCompiler-shared.h:154
#13 js::jit::BaselineCompiler::emitStackCheck (this=this@entry=0xffffa9b0, earlyCheck=earlyCheck@entry=false) at js/src/jit/BaselineCompiler.cpp:573
#14 0x084ce5e8 in js::jit::BaselineCompiler::emitPrologue (this=this@entry=0xffffa9b0) at js/src/jit/BaselineCompiler.cpp:430
#15 0x084f539b in js::jit::BaselineCompiler::compile (this=this@entry=0xffffa9b0) at js/src/jit/BaselineCompiler.cpp:98
#16 0x084f691e in js::jit::BaselineCompile (cx=cx@entry=0xf7a20200, script=0xf574b160, forceDebugInstrumentation=false) at js/src/jit/BaselineJIT.cpp:263
#17 0x084f7051 in CanEnterBaselineJIT (cx=cx@entry=0xf7a20200, script=..., script@entry=..., osrFrame=osrFrame@entry=0x0) at js/src/jit/BaselineJIT.cpp:302
#18 0x084f7427 in js::jit::CanEnterBaselineMethod (cx=cx@entry=0xf7a20200, state=...) at js/src/jit/BaselineJIT.cpp:370
#19 0x082ef32f in js::RunScript (cx=cx@entry=0xf7a20200, state=...) at js/src/vm/Interpreter.cpp:647
#20 0x082efb7c in js::Invoke (cx=cx@entry=0xf7a20200, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:738
#21 0x082f0c13 in js::Invoke (cx=cx@entry=0xf7a20200, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0xf59ffec8, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:775
#22 0x084f1c6e in js::jit::DoCallFallback (cx=cx@entry=0xf7a20200, frame=frame@entry=0xf59ffef8, stub_=stub_@entry=0xf7a21110, argc=argc@entry=0, vp=vp@entry=0xf59ffeb8, res=res@entry=...) at js/src/jit/BaselineIC.cpp:9859
#23 0x08735756 in js::jit::Simulator::softwareInterrupt (this=0xf7a7f000, instr=0xf7a02e04) at js/src/jit/arm/Simulator-arm.cpp:2171
#24 0x08735986 in js::jit::Simulator::decodeType7 (this=0xf7a7f000, instr=0xf7a02e04) at js/src/jit/arm/Simulator-arm.cpp:3270
#25 0x08733c25 in js::jit::Simulator::instructionDecode (this=this@entry=0xf7a7f000, instr=instr@entry=0xf7a02e04) at js/src/jit/arm/Simulator-arm.cpp:4189
#26 0x087374fc in execute<false> (this=0xf7a7f000) at js/src/jit/arm/Simulator-arm.cpp:4244
#27 js::jit::Simulator::callInternal (this=this@entry=0xf7a7f000, entry=entry@entry=0xf7fc8a30 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>) at js/src/jit/arm/Simulator-arm.cpp:4332
#28 0x08737981 in js::jit::Simulator::call (this=<optimized out>, entry=entry@entry=0xf7fc8a30 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>, argument_count=<optimized out>, argument_count@entry=8) at js/src/jit/arm/Simulator-arm.cpp:4415
#29 0x0846a4b9 in EnterBaseline (cx=cx@entry=0xf7a20200, data=...) at js/src/jit/BaselineJIT.cpp:124
#30 0x084dc469 in js::jit::EnterBaselineAtBranch (cx=0xf7a20200, fp=0xf56c1080, pc=0xf7a89a11 "う\232") at js/src/jit/BaselineJIT.cpp:228
#31 0x082ee161 in Interpret (cx=cx@entry=0xf7a20200, state=...) at js/src/vm/Interpreter.cpp:2031
#32 0x082ef249 in js::RunScript (cx=cx@entry=0xf7a20200, state=...) at js/src/vm/Interpreter.cpp:661
#33 0x082f9505 in js::ExecuteKernel (cx=cx@entry=0xf7a20200, script=..., script@entry=..., scopeChainArg=..., thisv=..., newTargetValue=..., type=type@entry=js::EXECUTE_GLOBAL, evalInFrame=evalInFrame@entry=..., result=result@entry=0x0) at js/src/vm/Interpreter.cpp:902
#34 0x082f9920 in js::Execute (cx=cx@entry=0xf7a20200, script=script@entry=..., scopeChainArg=..., rval=rval@entry=0x0) at js/src/vm/Interpreter.cpp:936
#35 0x0872fe04 in ExecuteScript (cx=cx@entry=0xf7a20200, scope=..., script=script@entry=..., rval=rval@entry=0x0) at js/src/jsapi.cpp:4334
#36 0x0872fff6 in JS_ExecuteScript (cx=cx@entry=0xf7a20200, scriptArg=scriptArg@entry=...) at js/src/jsapi.cpp:4365
#37 0x0806b499 in RunFile (compileOnly=false, file=0xf7ae59e0, filename=0xffffd0b4 "min.js", cx=0xf7a20200) at js/src/shell/js.cpp:458
#38 Process (cx=cx@entry=0xf7a20200, filename=0xffffd0b4 "min.js", forceTTY=forceTTY@entry=false) at js/src/shell/js.cpp:576
#39 0x080cac70 in ProcessArgs (op=0xffffcd60, cx=<optimized out>) at js/src/shell/js.cpp:5771
#40 Shell (envp=<optimized out>, op=0xffffcd60, cx=<optimized out>) at js/src/shell/js.cpp:6040
#41 main (argc=5, argv=0xffffceb4, envp=0xffffcecc) at js/src/shell/js.cpp:6384
eax	0x0	0
ebx	0x9749434	158635060
ecx	0xf7a9c098	-139870056
edx	0xf7a290d0	-140341040
esi	0x4	4
edi	0xf7a9c094	-139870060
ebp	0xffffa3f8	4294943736
esp	0xffffa3d0	4294943696
eip	0x866a2e0 <mozilla::PodCopy<int>(int*, int const*, size_t)+128>
=> 0x866a2e0 <mozilla::PodCopy<int>(int*, int const*, size_t)+128>:	mov    %edx,(%eax)
   0x866a2e2 <mozilla::PodCopy<int>(int*, int const*, size_t)+130>:	jbe    0x866a2f8 <mozilla::PodCopy<int>(int*, int const*, size_t)+152>


This is likely a null-deref, so not marking s-s.
(Reporter)

Updated

2 years ago
Blocks: 912928
(Assignee)

Comment 1

2 years ago
Missing null pointer check, easy fix.
(Assignee)

Updated

2 years ago
Assignee: nobody → lhansen
Status: NEW → ASSIGNED
(Assignee)

Comment 2

2 years ago
Created attachment 8662330 [details] [diff] [review]
bug1186982-oomcheck.patch

Attempts to guard against and propagate OOM within the buffer code, and then capture it at the call site.  ARM64 will need the similar capture fix, I will file a separate bug.
Attachment #8662330 - Flags: review?(hv1989)
(Assignee)

Updated

2 years ago
See Also: → bug 1205621
Attachment #8662330 - Flags: review?(hv1989) → review+
(Assignee)

Comment 3

2 years ago
Grumble.  I'm now running into occasional assertions in CallJSNative where cx->isExceptionPending is set but the native function did not return false.  Presumably the OOM flag is not being picked up everywhere it needs to be.
(Assignee)

Comment 4

2 years ago
(In reply to Lars T Hansen [:lth] from comment #3)
> Grumble.  I'm now running into occasional assertions in CallJSNative where
> cx->isExceptionPending is set but the native function did not return false. 
> Presumably the OOM flag is not being picked up everywhere it needs to be.

This is a bug in the HashTable code, it drops an OOM condition on the floor in checkUnderloaded().  It either needs to propagate that - looks hairy and maybe pointless - or it needs to reset the exception.  Will file a bug for that; can't land this until that's been fixed.
(In reply to Lars T Hansen [:lth] from comment #4)
> This is a bug in the HashTable code, it drops an OOM condition on the floor
> in checkUnderloaded().  

I filed bug 1207519 for that this morning.
(Assignee)

Comment 6

2 years ago
(In reply to Jon Coppeard (:jonco) from comment #5)
> (In reply to Lars T Hansen [:lth] from comment #4)
> > This is a bug in the HashTable code, it drops an OOM condition on the floor
> > in checkUnderloaded().  
> 
> I filed bug 1207519 for that this morning.

Most excellent.
Depends on: 1207519
(Assignee)

Comment 7

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/10db467779a053321e9f4a0e6ee8079ddc480752
Bug 1186982 - check for allocation failure.  r=h4writer
Backed out for SM orange: https://treeherder.mozilla.org/logviewer.html#?job_id=14974498&repo=mozilla-inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/8799f0dcfe76
Flags: needinfo?(lhansen)
(Assignee)

Comment 9

2 years ago
(In reply to Wes Kocher (:KWierso) from comment #8)
> Backed out for SM orange:
> https://treeherder.mozilla.org/logviewer.html#?job_id=14974498&repo=mozilla-
> inbound
> 
> https://hg.mozilla.org/integration/mozilla-inbound/rev/8799f0dcfe76

Noted.
Flags: needinfo?(lhansen)
(Assignee)

Comment 10

2 years ago
It looks like all the failures are with --ion-eager --ion-offthread-compile=off.  This suggests that there can be OOM failures at locations where the test case may not be prepared to handle them, so this could just be the test cases needing work.  For example, in the present test case, wrapping a try/catch around the do-while loop gets rid of the crash.

(ni? jonco because of relevance to bug 1209001, decoder because this problem will show up elsewhere too, given the fuzzing pattern that's being used.)
Flags: needinfo?(jcoppeard)
Flags: needinfo?(choller)
(Assignee)

Comment 11

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/212f49a401b2fe47c6f46c774a214063f2f21246
Bug 1186982 - propagate OOM failures.  r=h4writer
Back out for SM failures: https://hg.mozilla.org/integration/mozilla-inbound/rev/21ac28a08b35

https://treeherder.mozilla.org/logviewer.html#?job_id=15003926&repo=mozilla-inbound
Flags: needinfo?(lhansen)
(Assignee)

Updated

2 years ago
Flags: needinfo?(lhansen)
(Assignee)

Comment 13

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/bc20a0abec612f7cdb6ce52b6393f7d4232c32f8
Bug 1186982 - propagate OOM failures (no test case).  r=h4writer
(In reply to Lars T Hansen [:lth] from comment #10)
> This suggests that there can be OOM failures
> at locations where the test case may not be prepared to handle them

Yes, an issue like this came up before in bug 1203814.  The original oomTest() function has been fixed but the fuzzers still come up with test cases involving the old one.

I tried changing the test code to |load(libdir + 'oomTest.js')| and use the fixed version however there are still failures.
Flags: needinfo?(jcoppeard)
https://hg.mozilla.org/mozilla-central/rev/bc20a0abec61
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
(Reporter)

Updated

2 years ago
Flags: needinfo?(choller)
Perhaps this test case can be committed now that we have fixed all the OOM bugs?
(Assignee)

Updated

2 years ago
Blocks: 1215090
(Assignee)

Comment 17

2 years ago
(In reply to Jakob Stoklund Olesen [:jolesen] from comment #16)
> Perhaps this test case can be committed now that we have fixed all the OOM
> bugs?

"all the OOM bugs" :)

Filed the landing of the TC separately as bug 1215090, as the problem had to do with sporadic failures, needs thorough vetting.
You need to log in before you can comment on or make changes to this bug.