980941 - Assertion failure: *this->getTail() != nullptr, at jit/shared/IonAssemblerBufferWithConstantPools.h:1039

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 529b86b92b1d (x86 ARM simulator build, run with --fuzzing-safe --ion-eager):


x = gczeal(2);    
for each(let a in 'b') {}
try { f2(); } catch(exc1) {}
oomAfterAllocations(1);
var i = 349818;

Comment 1

[Christian Holler (:decoder)]

This is an OOM issue, but fixing this makes testing on the simulator build easier :)

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Cannot process bug: Error: Unsupported architecture "ARM" required by bug

Comment 3

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, failed due to error: Error: Unsupported architecture "ARM" required by bug

Comment 4

[Douglas Crosher [:dougc]]

Looks like general issues in OOM paths.  Have seen other failure paths without --ion-parallel-compile=off.  Causes a different failure in the reworked code in bug 972710.

Comment 5

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/5ad5f92387a2
user:        Jan de Mooij
date:        Mon Apr 21 15:36:33 2014 -0700
summary:     Bug 998596 - Add ARM simulator status to getBuildConfiguration. r=terrence

This iteration took 1939.576 seconds to run.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Douglas Crosher [:dougc] from comment #4)
> Looks like general issues in OOM paths.  Have seen other failure paths
> without --ion-parallel-compile=off.  Causes a different failure in the
> reworked code in bug 972710.

> The first good revision is:
> changeset:   https://hg.mozilla.org/mozilla-central/rev/5ad5f92387a2

This likely regressed before this changeset, but I'll move on since :dougc has taken a look.

Comment 7

[Douglas Crosher [:dougc]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #6)
> (In reply to Douglas Crosher [:dougc] from comment #4)
> > Looks like general issues in OOM paths.  Have seen other failure paths
> > without --ion-parallel-compile=off.  Causes a different failure in the
> > reworked code in bug 972710.
> 
> > The first good revision is:
> > changeset:   https://hg.mozilla.org/mozilla-central/rev/5ad5f92387a2
> 
> This likely regressed before this changeset, but I'll move on since :dougc
> has taken a look.

This is a good test for oom issues. It still crashes even with the asm buffer simplifications in bug 1026919. The latest crash is:

Assertion failure: [unhandlable oom] LifoAlloc::allocInfallible, at js/src/jscntxt.cpp:1427
Hit MOZ_CRASH() at js/src/jscntxt.cpp:1428

Program received signal SIGSEGV, Segmentation fault.
0x08478359 in js::CrashAtUnhandlableOOM (reason=reason@entry=0x87e37c2 "LifoAlloc::allocInfallible") at js/src/jscntxt.cpp:1428
1428	    MOZ_CRASH();
Missing separate debuginfos, use: debuginfo-install glibc-2.17-20.fc19.i686 libgcc-4.8.2-7.fc19.i686 libstdc++-4.8.2-7.fc19.i686 nspr-4.10.5-1.fc19.i686
(gdb) back
#0  0x08478359 in js::CrashAtUnhandlableOOM (reason=reason@entry=0x87e37c2 "LifoAlloc::allocInfallible") at js/src/jscntxt.cpp:1428
#1  0x0826e44f in js::LifoAlloc::allocInfallible (this=0xf7a2d130, n=44) at js/src/ds/LifoAlloc.h:279
#2  0x083b69e2 in allocateInfallible (bytes=44, this=<optimized out>) at js/src/jit/IonAllocPolicy.h:37
#3  operator new (alloc=..., nbytes=44) at js/src/jit/IonAllocPolicy.h:178
#4  allocate (this=0xffffc2a8) at js/src/jit/IonAllocPolicy.h:205
#5  js::jit::MoveResolver::addMove (this=this@entry=0xffffc050, from=..., to=..., type=js::jit::MoveOp::GENERAL) at js/src/jit/MoveResolver.cpp:28
#6  0x084593e0 in js::jit::MacroAssemblerARMCompat::passSoftFpABIArg (this=this@entry=0xffffb918, from=..., type=type@entry=js::jit::MoveOp::GENERAL)
    at js/src/jit/arm/MacroAssembler-arm.cpp:3824
#7  0x0845954b in passABIArg (type=js::jit::MoveOp::GENERAL, from=..., this=0xffffb918) at js/src/jit/arm/MacroAssembler-arm.cpp:3836
#8  js::jit::MacroAssemblerARMCompat::passABIArg (this=this@entry=0xffffb918, reg=reg@entry=...) at js/src/jit/arm/MacroAssembler-arm.cpp:3847
...

If the intention is for the compiler to fail gracefully on oom then why would there be a allocateInfallible method? Something to explore.

Comment 8

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 1735ff2bb23e).

Comment 9

[Florian Bender]

(In reply to Christian Holler (:decoder) from comment #8)
> JSBugMon: The testcase found in this bug no longer reproduces (tried
> revision 1735ff2bb23e).

Closing then.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

If we don't know which patch fixed the bug, WFM is the correct resolution.