781343 - "Assertion failure: !cx->isExceptionPending(),"

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

Attachment: stack

try {
    Object.defineProperty(this, "o", {
        enumerable: true,
        get: function() {
            e;
        }
    });
    for each(var x in this) {}
} catch (e) {}
function a() {}
a([1].filter(x))

asserts js debug shell on m-c changeset 4e3fb1f9f72a without any CLI arguments at Assertion failure: !cx->isExceptionPending(),

Setting [fuzzblocker] not because this happens often, but because it happens intermittently with somewhat-tough-to-reduce testcases so having such a small testcase is even more rare.

Comment 1

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

(not sure about this bisection - bug 729369 might just be exposing a latent bug)

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   88389:cfa346e78b0d
user:        Bill McCloskey
date:        Tue Mar 06 11:38:44 2012 -0800
summary:     Bug 729369 - Expose the same set of SpiderMonkey testing APIs to debug shell and debug browser chrome (r=Waldo)

Comment 2

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

I used the following configure command:

sh ../configure --target=i386-apple-darwin8.0.0 --disable-optimize --enable-debug --enable-methodjit --enable-type-inference --enable-more-deterministic --disable-tests --enable-valgrind

Comment 3

[Jason Orendorff [:jorendorff]]

SM doesn't build for me with the given ../configure command line. I have to add CROSS_COMPILE=1 and some other bits and pieces.

And the bug doesn't reproduce for me, either with tip or with the revision specified in comment 0. Does it still reproduce, Gary? I'm a little confused, because the stack says that the function we were calling was 'Notes', but notes isn't mentioned in the testcase.

Comment 4

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

Attachment: stack

Try:

LD=ld CROSS_COMPILE=1 CC="clang -Qunused-arguments -fcolor-diagnostics -arch i386" RANLIB=ranlib CXX="clang++ -Qunused-arguments -fcolor-diagnostics -arch i386" AS=$CC AR=ar STRIP="strip -x -S" HOST_CC="clang -Qunused-arguments -fcolor-diagnostics" HOST_CXX="clang++ -Qunused-arguments -fcolor-diagnostics" sh ./configure --target=i386-apple-darwin9.2.0 --enable-macos-target=10.5 --disable-optimize --enable-debug --enable-methodjit --enable-type-inference --enable-more-deterministic --disable-tests --enable-valgrind

I still reproduce with m-c changeset 8b46964e55c9, updating the stack.

Comment 5

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

(In reply to Gary Kwong [:gkw, :nth10sd] from comment #2)
> I used the following configure command:
> 
> sh ../configure --target=i386-apple-darwin8.0.0 --disable-optimize
> --enable-debug --enable-methodjit --enable-type-inference
> --enable-more-deterministic --disable-tests --enable-valgrind

It appears I left out the environment variables needed to trigger a 32-bit js shell build. Oops.

Comment 6

[Steve Fink [:sfink] [:s:]]

I saw this twice in a try server push: https://tbpl.mozilla.org/?tree=Try&rev=0962adf50428

2 runs of the jsreftests hit it, 12 other runs were fine.

My stacks were under SendToGenerator() for the test js1_8_5/extensions/recursion.js, which is a little different. Given that it was a recursion test, I thought maybe there was an OOM at the wrong time and added a shell test function oomTrigger(n) that would fail the nth memory allocation after you called it (using the same JSContext). But I wasn't able to reproduce it with or without calls to oomTrigger, so I gave up.

Comment 7

[Steve Fink [:sfink] [:s:]]

Well, ok, 6 of the other 12 were opt builds, so they don't count.

Comment 8

[Steve Fink [:sfink] [:s:]]

Maybe add a printout of what exception is being thrown when we hit this?

Comment 9

[Jason Orendorff [:jorendorff]]

Attachment: v1

Turns out to be a trivial shell-only bug.

Comment 10

[Jason Orendorff [:jorendorff]]

Steve, this assertion means a JSNative returned true but there was an exception pending. You can see which native by looking at the 'native' argument in frame 0.

Comment 11

[Jason Orendorff [:jorendorff]]

Attachment: Part 2 - Common up some stuff in shell/js.cpp, v1

While I'm hanging out in here...

Comment 12

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

The bug that the patch in comment 9 fixes, goes all the way back to hg changeset 1 (and prior), which means it's ancient.

Comment 13

[Steve Fink [:sfink] [:s:]]

(In reply to Jason Orendorff [:jorendorff] from comment #10)
> Steve, this assertion means a JSNative returned true but there was an
> exception pending. You can see which native by looking at the 'native'
> argument in frame 0.

Yes, I know. Perhaps my failure is not the same, but it happened in the browser, not the shell. And I only have the tbpl output from the minidump stack trace, so I can't look to see what native it is.

Gary also told me that a simple |notes(1)| from the shell also triggers this, but that appears to be because if ValueToScript returns NULL, it may or may not have thrown an exception. Which also seems bad.

Comment 14

[Jason Orendorff [:jorendorff]]

(In reply to Steve Fink [:sfink] from comment #13)
> Gary also told me that a simple |notes(1)| from the shell also triggers
> this, but that appears to be because if ValueToScript returns NULL, it may
> or may not have thrown an exception. Which also seems bad.

It looks to me like if ValueToScript returns NULL, an exception is definitely pending.

Comment 15

[Jim Blandy :jimb]

Comment on attachment 659898 [details] [diff] [review]
Part 2 - Common up some stuff in shell/js.cpp, v1

Review of attachment 659898 [details] [diff] [review]:
-----------------------------------------------------------------

Absolutely lovely. Warms my heart.

Comment 16

[Jason Orendorff [:jorendorff]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7ff900d42c59
https://hg.mozilla.org/integration/mozilla-inbound/rev/2e685a0f1027

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/7ff900d42c59
https://hg.mozilla.org/mozilla-central/rev/2e685a0f1027

Comment 18

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

I am glad this was fixed, because this would mask another bug 791445 of the same assert.

Comment 19

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

jorendorff, do you mind asking for approval on aurora 17 branch (which is going to be an ESR)? It will help with fuzzing on that future ESR branch. Thank you!

Comment 20

[Jason Orendorff [:jorendorff]]

Comment on attachment 659894 [details] [diff] [review]
v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
  bug 729369
User impact if declined:
  This patch will help with fuzzing on Aurora.  The only impact of declining
  this would be less security testing.
Testing completed (on m-c, etc.):
  on m-c.
Risk to taking this patch (and alternatives if risky):
  Minimal (this code is not part of the browser).
String or UUID changes made by this patch:
  None.
Other notes:
  Will not be requesting approval for part 2, which is just code cleanup.

Comment 21

[Alex Keybl [:akeybl]]

Comment on attachment 659894 [details] [diff] [review]
v1

[Triage Comment]
Low risk change in support of fuzzing.

Comment 22

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/eb69897f7d24

Comment 23

[Manuela Muntean [Away]]

I've tried several times, but I can't reproduce this bug. I will keep on trying on a different machine.

Comment 24

[Manuela Muntean [Away]]

Setting this to "qa?" and removing "verifyme" for the time being.

Could I get some more info on how to reproduce this bug please?

Comment 25

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

You'll have to compile a shell from m-c changeset 4e3fb1f9f72a in comment 0, using the configure options in comment 2 to get a 32-bit shell to get it to reproduce.

Comment 26

[Manuela Muntean [Away]]

While trying to build Firefox on Ubuntu 12.04 (which is up-to-date), I get the following error:

http://pastebin.mozilla.org/1929133

Could you please help me solve this?

Comment 27

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

> Could you please help me solve this?

You need to first install "ia32-libs gcc-multilib g++-multilib" via apt-get, I think.

Comment 28

[Manuela Muntean [Away]]

Even after using the command you suggested:

  sudo apt-get install ia32-libs-multiarch gcc-multilib g++-multilib  

(only using "ia32-libs" didn't seem to work), I still receive the same error as in comment 26, when running the configure command in comment 2.