862343 - Opt-only crash [@ js::Invoke] with ParallelArray and gczeal

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on baseline compiler branch revision 5fd27c1b3943 (run with --ion-eager):


gczeal(2,1);
function testMonitorIntrinsic() {
  var N = 2;
  var p = new ParallelArray([N,N], function () 0);
  for (var i = 0; i < 3; i++) {
    for (var j = 0; j < 2; j++) {
      p.get(i).get(j);
    }
  }
}
testMonitorIntrinsic();

Comment 1

[Christian Holler (:decoder)]

This was reported using the wrong reporting script. Will provide the details in a few.

Comment 2

[Christian Holler (:decoder)]

This was found on the fuzzing machine that is testing the patch in bug 858381 and it doesn't reproduce on trunk so I assume it's a regression from that patch.

It was found on m-c revision 4f364593f8bf + the patch and reproduces only in an optimized 32 bit build (with --disable-debug).

Waldo, want to take a look?

Comment 3

[Jeff Walden [:Waldo]]

I keep getting this when I run this:

[jwalden@find-waldo-now src]$ gcc-dbg/js --ion-eager -f /tmp/pa.js 
/tmp/pa.js:7:6 TypeError: p.get(...) is undefined

This is a Linux64 threadsafe with-system-nspr build, which isn't quite the setup mentioned here, but I'd think to either get a completely successful result or the crash.  I'm *assuming* the error isn't something I should be seeing, but I could be wrong about that.

Anyway, I dunno what's up yet.  I paged nmatsakis on IRC, maybe he can help a little here with what should be happening.

I rechecked the one bit of JIT code that might affect this, and I may see an issue there.  On the other hand, I don't quite see how that issue would lead to a crash, just wrong behavior, so I dunno.

Comment 4

[Christian Holler (:decoder)]

Yea I was not able to reproduce the crash on 64 bit at all. And on 32 bit opt, it disappeared when removing your patch.

Comment 5

[Jeff Walden [:Waldo]]

No issue in the parallel-affected JIT code -- Object.defineProperty isn't callable in the parallel case, so we bail back to sequential and never hit the concern.  Last patch in bug 858381 adds an assert and test for the case, just to be safe.

I guess I can try building a 32-bit threadsafe shell and see if that gets me anywhere here.

Comment 6

[Jeff Walden [:Waldo]]

Yeah, I really can't reproduce this.  My steps to build, in js/src:

[jwalden@find-waldo-now src]$ hg up -r 4f364593f8bf
[jwalden@find-waldo-now src]$ hg qimport https://bugzilla.mozilla.org/attachment.cgi?id=737741 -n [jwalden@find-waldo-now src]$ rollup.diff
[jwalden@find-waldo-now src]$ hg qpu
[jwalden@find-waldo-now src]$ autoconf-2.13
[jwalden@find-waldo-now src]$ mkdir rollup
[jwalden@find-waldo-now src]$ cd rollup
[jwalden@find-waldo-now src]$ ../configure --disable-debug --enable-optimize --enable-valgrind --enable-threadsafe --with-system-nspr --enable-gczeal
[jwalden@find-waldo-now src]$ make -s -j4 1>/dev/null 2>&1
[jwalden@find-waldo-now src]$ cd ..
[jwalden@find-waldo-now src]$ cat /tmp/fail.js 
gczeal(2,1);
function testMonitorIntrinsic() {
  var N = 2;
  var p = new ParallelArray([N,N], function () 0);
  for (var i = 0; i < 3; i++) {
    for (var j = 0; j < 2; j++) {
      p.get(i).get(j);
    }
  }
}
testMonitorIntrinsic();
[jwalden@find-waldo-now src]$ rollup/js --ion-eager -f /tmp/fail.js 
/tmp/fail.js:7:6 TypeError: p.get(...) is undefined

What am I doing differently from your setup?

Comment 7

[Jeff Walden [:Waldo]]

Er, sec, I forgot the 32-bitness here.  Retrying with that...

Comment 8

[Jeff Walden [:Waldo]]

No, still same results with that.  Only change is to the configure invocation line:

PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig CC="gcc -m32" CXX="g++ -m32" AR=ar ../configure --target=i686-pc-linux --disable-debug --enable-optimize --enable-valgrind --enable-threadsafe --with-system-nspr --enable-gczeal

Halp!  :-)

Comment 9

[Christian Holler (:decoder)]

My builds for fuzzing are always non-threadsafe builds. Please just try this:

CC="gcc -m32" CXX="g++ -m32" AR=ar ../configure --target=i686-pc-linux --disable-debug --enable-optimize --enable-valgrind --enable-gczeal

If we still cannot reproduce this then, then I suggest closing it as WFM because I haven't seen this issue popping up on trunk.