1366884 - Crash [@ ??]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

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

The following testcase crashes on mozilla-central revision cc65f9233e5b (build with --32 --disable-profiling, run with --fuzzing-safe --ion-aa=flow-insensitive --no-incremental-gc --gc-zeal=4 --no-threads --baseline-eager --ion-offthread-compile=off --ion-osr=off --ion-check-range-analysis -e maxRunTime=12000 -f):

See attachment.

Backtrace:

#0  0xf73d6516 in ?? () from /lib32/libc.so.6
#1  0x086ba90d in js::AsmJSMetadata::getFuncName (this=0xf1cd8400, maybeBytecode=0x0, funcIndex=0, name=0xffc01da0) at js/src/wasm/AsmJS.cpp:374
#2  0x086fa221 in js::wasm::Instance::getFuncName (name=0xffc01da0, funcIndex=<optimized out>, this=<optimized out>) at js/src/wasm/WasmInstance.cpp:764
#3  js::wasm::Instance::getFuncAtom (funcIndex=<optimized out>, cx=0xf7138800, this=<optimized out>) at js/src/wasm/WasmInstance.cpp:771
#4  js::wasm::FrameIterator::functionDisplayAtom (this=0xffc02340) at js/src/wasm/WasmFrameIterator.cpp:177
#5  0x085e82c3 in js::FrameIter::functionDisplayAtom (this=<optimized out>) at js/src/vm/Stack.cpp:834
/snip

For detailed crash information, see attachment.

Emanuel mentions that we should set this s-s as a start.

Comment 1

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

Attachment: Detailed Crash Information

Comment 2

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

Attachment: Testcase

Comment 3

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

Attachment: runtimeFlags.txt

Comment 4

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

Attachment: bbtestcase.js

Replace the link at the top of the testcase to point to your local m-c repo.

Comment 5

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

Attachment: corefile

Comment 6

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

Attachment: Updated debug stack

Compilation parameters:

CC="gcc -m32 -msse2 -mfpmath=sse" CXX="g++ -m32 -msse2 -mfpmath=sse" AR=ar PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig sh ./configure --target=i686-pc-linux --enable-debug --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"

Comment 7

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

We figured this might be related to bug 1329499, and setting needinfo? from Emanuel as a start.

Comment 8

[Emanuel Hoogeveen [:ehoogeveen]]

No luck reproducing this locally so far, using the original binary that Gary sent me and the testcase from comment #4 :( I've been letting it run in a loop under gdb, so it's probably run a few thousand times by now. I even cloned m-c to the location the testcase expects to set things up as similarly as possible.

Gary, could you try to reproduce this on different hardware? Even though the machine is new, this *is* probably the most direct check for bad RAM we have in SpiderMonkey (or Gecko), so we might be unlucky. The fact that this is happening in the shell and with --no-threads makes me more suspicious.

Comment 9

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

It originally happened on an EC2 instance, which I reproduced (intermittently) locally.

Comment 10

[Emanuel Hoogeveen [:ehoogeveen]]

Unfortunately I don't have any idea about this other than hardware failure; we've only seen these crashes in the wild on Windows, where there's a 50/50 split between corruption in the temporary buffer and the new buffer, strongly indicating hardware failure. I also wasn't able to reproduce this locally after letting it run overnight. If you could run a memcheck on the local machine that would be great.

Comment 11

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

I ran memcheck 7 (free version) off a USB stick, which showed no errors. Jan, do you happen to have other ideas?

Comment 12

[Christian Holler (:decoder)]

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #8)
> I've been letting it run in a > loop under gdb, [...]

Have you tried this without GDB? We have quite a few bugs that will never reproduce in GDB since GDB changes the memory layout and timing of the process.

Comment 13

[Emanuel Hoogeveen [:ehoogeveen]]

Thanks for the tip, I'll try without gdb tomorrow. And thanks for running that memcheck, Gary!

Comment 14

[Benjamin Bouvier [:bbouvier] (inactive)]

From the signature, it seems very likely to be a duplicate of bug 1367871; I'll try to reproduce manually.

Comment 15

[Benjamin Bouvier [:bbouvier] (inactive)]

Oops, nevermind me, didn't see the updated backtrace in comment 6.

Comment 16

[Emanuel Hoogeveen [:ehoogeveen]]

No luck reproducing without gdb either I'm afraid.

Comment 17

[Jan de Mooij [:jandem]]

Gary, the runtimeFlags.txt attachment does not match the flags in comment 0. Which flags should I use?

Also, how hard is it to repro this for you? I tried it a few times but it doesn't fail here either.

Comment 18

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

I think the runtimeFlags.txt one is more correct, however it's been awhile, I need to recheck but am on a trip.

If it still repros for me, we can follow up end-June at the SF all hands.

Comment 19

[Jan de Mooij [:jandem]]

OK, clearing NI as I can't repro this.

Comment 20

[Daniel Veditz [:dveditz]]

See also bug 1371283 for a reliable testcase, but the signature is so generic that it could be something completely different.

Comment 21

[Daniel Veditz [:dveditz]]

restoring ni? for gary to recheck whether this still repros for him.

Comment 22

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

Yes, this still reproduces for me on the original m-c rev cc65f9233e5b and as well as mozilla-central tip currently at rev 92dc60b522d8.

I'll try to get hold of some JIT folks next week at the SF All-Hands to debug this.

Comment 23

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

Unfortunately the crash disappeared for me now, having it reproduced initially (and also in gdb) - Jan told me f2f to try it in rr but once I got rr working, it no longer reproduced. I subsequently tried for 3 hours yesterday but to no avail.

The current coredumps don't offer enough information other than just memory corruption, so I guess there's nothing we can do here.

-> WORKSFORME (unless other folks think otherwise)