953289 - Crash [@ JitActivationIterator] or Opt-Crash [@ markIfUnmarked]

Status: RESOLVED DUPLICATE of bug 980630

(Core :: JavaScript Engine: JIT, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 451f47a70238 (run with --fuzzing-safe):


function Foo() {
  var y = 0;
  for (var i = 0; i < 100; new ArrayBuffer(8192)) { y++ }
}
try {
for (var i = (1); i < 100; i++) {
  var x = new Foo();
}
} catch(exc1) {}
const BUF_64KB = new ArrayBuffer(64 * 1024);

Comment 1

[Christian Holler (:decoder)]

Attachment: [crash-signature] Machine-readable crash signature

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, failed due to error (try manually).

Comment 3

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/9c90bda44992
user:        Brian Hackett
date:        Thu Aug 15 07:33:30 2013 -0700
summary:     Bug 864220 - Use mprotect to trigger interrupts in Ion compiled code, r=luke,jandem.

Brian, is bug 864220 a possible regressor?

Comment 4

[Andrew McCreight (out until 2026) [:mccr8]]

Since bhackett is on vacation, do you think the regression in comment 3 is right, jandem?  Thanks.

Setting to sec-high because of the opt crashes on a non-zero value.

Comment 5

[Luke Wagner [:luke]]

I wasn't able to reproduce a crash on debug or opt 32-bit linux shells on cset 5163bf6b21b2.  This seems oom-related.  Are you running the test on 32 or 64-bit hardware?

Comment 6

[Jan de Mooij [:jandem]]

On OS X, malloc is printing messages to stderr. I agree with Luke that this is likely OOM. decoder, you've been fixing OOM bugs lately, would it be possible to get a stack trace of the allocation that fails?

Comment 7

[Christian Holler (:decoder)]

I'm running 32-bit non-threadsafe builds for this. Here is the last allocation that fails (m-c rev 80a27198344a):

Breakpoint 1, js_ReportOutOfMemory (cxArg=0x92d2e68) at js/src/jscntxt.cpp:356
356     js_ReportOutOfMemory(ThreadSafeContext *cxArg)
#0  js_ReportOutOfMemory (cxArg=0x92d2e68) at js/src/jscntxt.cpp:356
#1  0x0858e1a6 in AllocateArrayBufferContents (maybecx=<optimized out>, nbytes=8192, oldptr=0x0) at js/src/vm/TypedArrayObject.cpp:253
#2  0x08597029 in js::ArrayBufferObject::allocateSlots (this=0xfe37b160, maybecx=0x92d2e68, bytes=8192, clear=true) at js/src/vm/TypedArrayObject.cpp:276
#3  0x085e8e2d in js::ArrayBufferObject::create (cx=0x92d2e68, nbytes=8192, clear=true) at js/src/vm/TypedArrayObject.cpp:648
#4  0x085ed6a4 in js::ArrayBufferObject::class_constructor (cx=0x92d2e68, argc=1, vp=0xffffbf94) at js/src/vm/TypedArrayObject.cpp:220
#5  0xf7b11733 in ?? ()


I went through that call stack, and the OOM is propagated as expected, up to and including [@ js::ArrayBufferObject::class_constructor]. From there, it's JIT code calling as it seems. Is the JIT code maybe not checking the return value here? I'm curious how to figure out what's wrong in this case (as I try to learn more about fixing OOM errors).

Comment 8

[Jan de Mooij [:jandem]]

Attachment: Patch

I can't reproduce this crash on OS X, but I did see something suspicious when I stepped through this in lldb. decoder, can you see if this helps? Probably not but worth a try.

Comment 9

[Christian Holler (:decoder)]

Comment on attachment 8359723 [details] [diff] [review]
Patch

As discussed on IRC, unfortunately this doesn't fix it.

Comment 10

[Jan de Mooij [:jandem]]

Attachment: Comments

This is a TI OOM problem. Brian, I added two comments that show where the problems are, can you take this from here?

Comment 11

[Christian Holler (:decoder)]

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

Comment 12

[Christian Holler (:decoder)]

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

The first good revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/357895a6aaac
user:        Jon Coppeard
date:        Wed Feb 05 14:09:41 2014 +0000
summary:     Bug 965745 - Always patch loop backedges in Ion if interrupt flag is set r=jandem

This iteration took 364.238 seconds to run.

Comment 13

[Brian Hackett [Laid off!]]

This should be fixed by bug 980630, though on this path we'll just MOZ_CRASH().

Comment 14

[Christian Holler (:decoder)]

Can we avoid to MOZ_CRASH() due to OOM without outputting a proper message before that? In GGC, there are a few places where OOM cannot be handled, and we output an OOM assertion message before the crash. That way, it's easier for automation, like fuzzing, to distinguish these conditions from others.

Comment 15

[Brian Hackett [Laid off!]]

Sure, but can you add that comment to bug 980630?  It's kind of dumb if MOZ_CRASH() doesn't print anything before crashing.

Comment 16

[Andrew McCreight (out until 2026) [:mccr8]]

Duping per comment 13.