864227 - Crash [@ JSScript::enclosingScriptsCompiledSuccessfully]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

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

Attachment: stack

The upcoming attached testcase asserts js debug shell on m-c changeset e818c908825a with --baseline-eager --ion-parallel-compile=on --thread-count=14 -a "--execute=mjitChunkLimit(74)" --ion-eager -D -e maxRunTime=6000 -f at JSScript::enclosingScriptsCompiledSuccessfully

This is a very unreliable testcase and difficult to reduce.

LD=ld CROSS_COMPILE=1 MOZILLA_CENTRAL_PATH=<your path> CXX="clang++ -Qunused-arguments -arch i386" RANLIB=ranlib CC="clang -Qunused-arguments -arch i386" AS=$CC AR=ar STRIP="strip -x -S" HOST_CC="clang -Qunused-arguments" HOST_CXX="clang++ -Qunused-arguments" sh ./configure --target=i386-apple-darwin9.2.0 --enable-macos-target=10.5 --enable-optimize --enable-debug --enable-profiling --enable-gczeal --enable-debug-symbols --enable-methodjit --enable-type-inference --disable-tests --enable-more-deterministic --enable-threadsafe  --with-ccache

--with-system-nspr may be needed, as I removed my own configuration parameters to NSPR locally from the command above.

s-s pending further analysis, it does not look dangerous but I'll differ to a second opinion here.

Comment 2

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   127114:fb49fab1d534
user:        Jan de Mooij
date:        Tue Dec 04 09:53:38 2012 +0100
summary:     Bug 816985 part 2 - Compile GETGNAME. r=djvj

jandem, is bug 816985 a likely regressor? (I might try another run of bisection just in case this isn't a likely regressor)

Comment 3

[Christian Holler (:decoder)]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 4

[Jan de Mooij [:jandem]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #2)
> jandem, is bug 816985 a likely regressor? (I might try another run of
> bisection just in case this isn't a likely regressor)

Very unlikely, it's probably just because we compile more now and this influences GC or memory allocation or something.

Brian, the stack shows the PC counts mechanism and enclosingScriptsCompiledSuccessfully, are you aware of any known issues there?

Comment 5

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

I looked out for this specific exit code (139) displayed by this issue here, not sure if it helps:

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   127440:492e87516012
parent:      127437:d4656be59219
parent:      126103:5b7ed1616c62
user:        Jan de Mooij
date:        Mon Mar 25 10:27:13 2013 +0100
summary:     Merge from mozilla-inbound.

This iteration took 340.961 seconds to run.

Oops! We didn't test rev d4656be59219, a parent of the blamed revision! Let's do that now.
Rev d4656be59219: Updating... Compiling... Testing... good (Exit code 0)
As expected, the parent's label is the opposite of the blamed rev's label.

Oops! We didn't test rev 5b7ed1616c62, a parent of the blamed revision! Let's do that now.
Rev 5b7ed1616c62: Updating... Compiling... Testing... good (Exit code 0)
As expected, the parent's label is the opposite of the blamed rev's label.

The bug was introduced by a merge (it was not present on either parent).
I don't know which patches from each side of the merge contributed to the bug. Sorry.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Gentle nudge. Not sure if anyone has insights here... ?

Comment 7

[Andrew McCreight [:mccr8]]

This is a crash in a shell-only function, which possibly makes this not a security problem, but it is hard to know for sure.

Comment 8

[Daniel Veditz [:dveditz]]

For lack of better information, I'm going to assume accessing address 0xdadadade means a use-after-free of some kind.

Comment 9

[Brian Hackett [Laid off!]]

enclosingScriptsCompiledSuccessfully is only used by some debugging functions that are only exposed in the shell and with gdb.

Comment 10

[Andrew McCreight [:mccr8]]

I'm just going to open this up because it is shell-only.  JS_DumpCompartmentBytecode is just iterating over a bunch of scripts in the heap, so it could be tripping over all sorts of things.

Comment 11

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

I haven't seen this since, and there is no nice reduced testcase to land, and this seems to only involve a shell-only function, so marking in-testsuite- and setting WFM.