893890 - Crash [@ TryAttachCallStub] with setObjectMetadataCallback

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 18467a85acf6 (run with --ion-eager):


function test() {
    try {
        writeTestCaseResult();
    } catch(e) {}
}
function writeTestCaseResult( ) {
   return undefined.match(/foo/);
}
setObjectMetadataCallback(function(obj) { test(); });
x();

Comment 1

[Christian Holler (:decoder)]

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

Comment 2

[Christian Holler (:decoder)]

Needinfo from Brian because setObjectMetadataCallback is involved.

Comment 5

[Brian Hackett [Laid off!]]

Attachment: patch.txt

Bad things happen when we reenter JS while parsing/emitting scripts.

Comment 6

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fb48c7d58b8b

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/fb48c7d58b8b

Comment 8

[Scoobidiver (away)]

It's #2 top crasher in 24.0a2 on Mac OS X.

Comment 9

[Brian Hackett [Laid off!]]

setObjectMetadataCallback is a debugging hook which is not yet exposed to the browser at all.

Comment 10

[Christian Holler (:decoder)]

(In reply to Brian Hackett (:bhackett) from comment #9)
> setObjectMetadataCallback is a debugging hook which is not yet exposed to
> the browser at all.

Isn't it still possible that this bug is triggered also without setObjectMetadataCallback, just that the fuzzer hasn't found this case? (because it might be more complex).

Comment 11

[Brian Hackett [Laid off!]]

(In reply to Christian Holler (:decoder) from comment #10)
> (In reply to Brian Hackett (:bhackett) from comment #9)
> > setObjectMetadataCallback is a debugging hook which is not yet exposed to
> > the browser at all.
> 
> Isn't it still possible that this bug is triggered also without
> setObjectMetadataCallback, just that the fuzzer hasn't found this case?
> (because it might be more complex).

Well, this bug is about crashes that can happen when reentering JS in the parser/emitter.  This shouldn't be possible but could in principle happen.  It could be prevented entirely (we already do something similar when doing analysis/compilation) but it would be good to know if that is actually the culprit with these OS X (OS X only?) crashes.  Scoobidiver, can you point to some crash reports?  If the stack information is good enough it should be easy to see what's going on from them.

Comment 12

[Scoobidiver (away)]

(In reply to Brian Hackett (:bhackett) from comment #11)
> Scoobidiver, can you point to some crash reports? 
Here they are: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=js%3A%3AFunctionToString%28JSContext*%2C+JS%3A%3AHandle%3CJSFunction*%3E%2C+bool%2C+bool%29

Comment 13

[Brian Hackett [Laid off!]]

(In reply to Scoobidiver from comment #12)
> (In reply to Brian Hackett (:bhackett) from comment #11)
> > Scoobidiver, can you point to some crash reports? 
> Here they are:
> https://crash-stats.mozilla.com/report/
> list?product=Firefox&signature=js%3A%3AFunctionToString%28JSContext*%2C+JS%3A
> %3AHandle%3CJSFunction*%3E%2C+bool%2C+bool%29

This looks like a different issue, none of the crashes I see have parsing stuff on the stack.  All of them are NULL derefs under jsdScript::GetFunctionSource but it's not really obvious from the stacks which pointer is NULL.