601299 - "Assertion failure: hasfp()" [@ JSContext::regExpStatics]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

Attachment: testcase (asserts fatally when loaded)

Assertion failure: hasfp(), at js/src/jscntxtinlines.h:59
Might be a regression from bug 571355.

Comment 1

[Jesse Ruderman]

In an opt build, I get a null deref [@ __ZL18regexp_compile_subP9JSContextP8JSObjectjPN2js5ValueES5_].

Comment 2

[Jesse Ruderman]

Another way to reproduce is to paste this into xpcshell:

new new XPCSafeJSObjectWrapper(/x/)

Comment 3

[Jesse Ruderman]

Thet xpcshell testcase no longer does anything (XPCSafeJSObjectWrapper is not defined), but the browser testcase still hits the assertion failure.

Comment 4

[Chris Leary [:cdleary] (not checking bugmail)]

Attachment: WIP: use JS_GetGlobalForScopeChain

Makes sense, fast native executed from browser as a callback. I remember deliberately not relying on cx->globalObject, but I guess you have to in these kinds of situations. Need to test before requesting review.

Comment 5

[Chris Leary [:cdleary] (not checking bugmail)]

Attachment: use JS_GetGlobalForScopeChain

It works when I test it manually -- I can't figure out what the mochitest TEST_PATH is to get it run with the make target though... is there a rule of thumb for how to find that?

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 485971 [details] [diff] [review]
use JS_GetGlobalForScopeChain

If you want, you could create an internal (js_*) API to do this since I think this is the second time that we've had to use this external API in js/src. r=me either way.

Comment 7

[Chris Leary [:cdleary] (not checking bugmail)]

http://hg.mozilla.org/tracemonkey/rev/07bc530476c5

Followup bug for cleanup is bug 607724.

Comment 8

[Chris Leary [:cdleary] (not checking bugmail)]

Fix for bad mochitest: http://hg.mozilla.org/tracemonkey/rev/e99b3aca8eda

Comment 9

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/07bc530476c5