Closed Bug 584495 Opened 9 years ago Closed 9 years ago

Assertion JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL) in test_access_control.html, test_prompt.html, test_prompt_async.html, test_CrossSiteXHR_origin.html, test_getauthenticationinfo.html, test_hanging.html followed by timeouts, failures, and crashes

Categories

(Core :: JavaScript Engine, defect, critical)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta4+

People

(Reporter: khuey, Assigned: gal)

References

Details

(Keywords: intermittent-failure, Whiteboard: , fixed-in-tracemonkey)

Attachments

(1 file)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1280952462.1280954168.11128.gz&fulltext=1

Assertion failure: JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL), at /builds/slave/mozilla-central-linux-debug/build/js/src/xpconnect/src/xpcjsruntime.cpp:383

Followed by a lot of test failures and then a crash.
That totally sounds like me. When did this start?
Assignee: general → gal
blocking2.0: --- → ?
http://hg.mozilla.org/mozilla-central/rev/a0694218d21e is the first changeset it showed up on, but it definitely looks intermittent, so I would guess it's from the latest TM merge.
Assertion failure: JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL)
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1280957594.1280958575.30547.gz
OS: Linux → All
Summary: [Linux] Assertion JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL) in test_access_control.html followed by the end of the world → Assertion JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL) in test_access_control.html, test_prompt.html followed by the end of the world
I'm going to turn this into a generic bug for tracking test failures that happen with this assertion.
This should definitely block IMO, we're hitting this a lot on Tinderbox and it seems to end in a random crash every time.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1280957983.1280959042.32690.gz
Summary: Assertion JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL) in test_access_control.html, test_prompt.html followed by the end of the world → Assertion JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL) in test_access_control.html, test_prompt.html, test_prompt_async.html followed by timeouts, failures, and crashes
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1280954358.1280955302.15854.gz
Summary: Assertion JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL) in test_access_control.html, test_prompt.html, test_prompt_async.html followed by timeouts, failures, and crashes → Assertion JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL) in test_access_control.html, test_prompt.html, test_prompt_async.html, test_CrossSiteXHR_origin.html followed by timeouts, failures, and crashes
I still haven't seen a crash stack that is really related to this issue. Any chance of grabbing one of those?
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1281030456.1281033367.16970.gz
WINNT 5.2 mozilla-central debug test mochitests-4/5 on 2010/08/05 10:47:36
s: win32-slave16

Assertion failure: JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL), at e:/builds/moz2_slave/mozilla-central-win32-debug/build/js/src/xpconnect/src/xpcjsruntime.cpp:383
...
ERROR TEST-UNEXPECTED-FAIL | /tests/modules/plugin/test/test_getauthenticationinfo.html | Test timed out.
...
TEST-UNEXPECTED-FAIL | /tests/modules/plugin/test/test_hanging.html | application timed out after 330 seconds with no output
Summary: Assertion JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL) in test_access_control.html, test_prompt.html, test_prompt_async.html, test_CrossSiteXHR_origin.html followed by timeouts, failures, and crashes → Assertion JS_HAS_OPTION(acx, JSOPTION_UNROOTED_GLOBAL) in test_access_control.html, test_prompt.html, test_prompt_async.html, test_CrossSiteXHR_origin.html, test_getauthenticationinfo.html, test_hanging.html followed by timeouts, failures, and crashes
Attached patch patchSplinter Review
We seem to lose the flag somewhere along the way in an unclear manner. The JS context flag handling in Gecko is extremly sketchy and spread out over 20 files. This fight isn't worth it. Its not not a performance problem to reset the flag every time we CC.
Attachment #463691 - Flags: review?(brendan)
Comment on attachment 463691 [details] [diff] [review]
patch

I haven't looked, so talk is cheap, but it seems as though it should be "easy" to spot the bug by inspecting all the JS_{Set,Toggle}Options uses. But we need to stop the assertbotching.

/be
Attachment #463691 - Flags: review?(brendan) → review+
I did that. Its not easy. The code is rather bizarre and the flags are cached in various ways in various places and then re-applied. I will add an assert in JSAPI that stops if the flag is ever unset, which should catch the place that does this, but I do that after landing this.
Filed a follow-up bug as bug 585221.
Whiteboard: [orange] → [orange], fixed-in-tracemonkey
blocking2.0: ? → beta4+
didn't compile. backed out.

http://hg.mozilla.org/tracemonkey/rev/5a254bcd79f2
Whiteboard: [orange], fixed-in-tracemonkey → [orange]
relanded

http://hg.mozilla.org/tracemonkey/rev/d3719a8716f5
Whiteboard: [orange] → [orange], fixed-in-tracemonkey
Duplicate of this bug: 584354
http://hg.mozilla.org/mozilla-central/rev/d3719a8716f5
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Duplicate of this bug: 593968
Whiteboard: [orange], fixed-in-tracemonkey → , fixed-in-tracemonkey
You need to log in before you can comment on or make changes to this bug.