Closed
Bug 521844
Opened 15 years ago
Closed 15 years ago
Crash when detaching a tab after the window has been restored and with Firebug installed [@ nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ][@nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) ]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 519719
People
(Reporter: whimboo, Assigned: dmandelin)
References
Details
(Keywords: crash, regression, topcrash, Whiteboard: [firebug-blocks][crashkill])
Crash Data
Attachments
(1 file)
(deleted),
text/plain
|
Details |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20091011 Namoroka/3.6b1pre ID:20091011033822 With Firebug 1.4.2 installed builds on 1.9.2 always crash when doing the following steps: 1. Open at least two tabs 2. Close the window 3. Restore the window 4. Detach one of the tabs After step 4 it will take 2-3 seconds then the browser crashes in the following stack: bp-bf2368af-e6a8-4b5b-837c-4fd852091012 (First 10 frames only) 0 XUL nsScriptSecurityManager::doGetObjectPrincipal caps/src/nsScriptSecurityManager.cpp:2353 1 XUL nsScriptSecurityManager::GetFunctionObjectPrincipal caps/src/nsScriptSecurityManager.cpp:2144 2 XUL nsScriptSecurityManager::GetPrincipalAndFrame caps/src/nsScriptSecurityManager.cpp:2214 3 XUL nsScriptSecurityManager::GetSubjectPrincipal caps/src/nsScriptSecurityManager.cpp:2287 4 XUL nsScriptSecurityManager::SubjectPrincipalIsSystem caps/src/nsScriptSecurityManager.cpp:1871 5 XUL XPCThrower::ThrowExceptionObject js/src/xpconnect/src/xpcthrower.cpp:293 6 XUL XPCThrower::BuildAndThrowException js/src/xpconnect/src/xpcthrower.cpp:256 7 XUL XPCThrower::Throw js/src/xpconnect/src/xpcthrower.cpp:57 8 XUL XPC_WN_JSOp_ThisObject js/src/xpconnect/src/xpcwrappednativejsops.cpp:1435 9 libmozjs.dylib js_ComputeGlobalThis js/src/jsobj.h:335 10 libmozjs.dylib JS_GetFrameThis js/src/jsdbgapi.cpp:1144 This regression has been started between the builds 091001 and 091002. There are a lot of tracemonkey merges. I will do a hg bisect. http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=810bdf2e81f1&tochange=2a496c6df8c2
Flags: blocking1.9.2?
Comment 1•15 years ago
|
||
do you have any other extensions installed? What URLs were you loading in the testcase? Does Firebug have to be enabled in either of the tabs. I tried reproducing using Firebug 1.5a26 but was unable to cause a crash. I would also recommend updating to Firebug 1.4.3 to see if this still happens. The activation code changed between 1.4.2 and 1.4.3.
Updated•15 years ago
|
Whiteboard: [firebug-p1][firebug-blocks]
Reporter | ||
Comment 2•15 years ago
|
||
Running the latest 1.5 alpha version works fine and no crash happens. Upgrading to 1.4.3 still crashes the browser. Rob, it doesn't matter which content is loaded inside the tabs. It always crashes.
Reporter | ||
Comment 4•15 years ago
|
||
Missed that, sorry. Only Nightly Tester Tools to make it compatible. I'm still running the bisect. So expect a result later today. I will also come up shortly with a full GDB stack.
Reporter | ||
Comment 5•15 years ago
|
||
First bad revision is: Changeset: 32084:9d625ed36560 User: David Mandelin <dmandelin@mozilla.com> Date: Thu Aug 27 15:40:37 2009 -0700 Summary: Bug 505591: trace JSOP_NAME for returned closures, r=dvander Interestingly the range is different from my testing with nightly builds in comment 1.
Blocks: 505591
Keywords: regressionwindow-wanted
Reporter | ||
Comment 6•15 years ago
|
||
Comment 7•15 years ago
|
||
i hit this also just now; Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20091013 Namoroka/3.6b1pre. http://crash-stats.mozilla.com/report/index/a6edb9cf-eda8-484e-b9cc-095952091013. I have a crapload of extensions though. noticeably, Firefox 1.4.3b1 See my pastebin. http://pastebin.mozilla.org/676446
Reporter | ||
Comment 8•15 years ago
|
||
I hit the same bug some minutes ago just by trying to paste some content into the comment field on Bugzilla. Not reproducible until now.
Comment 9•15 years ago
|
||
anything to report here? Is this still crashing? I tried this with Firebug 1.5b1 installed and did not crash.
Reporter | ||
Comment 10•15 years ago
|
||
No, it doesn't crash with Firebug 1.5b1 installed. Worth fixing in any way? Extensions shouldn't crash the browser even when they are not compatible with the Firefox version.
Comment 11•15 years ago
|
||
certainly worth looking into. Firebug 1.4x isn't really considered as compatible with Firefox 3.6 yet, but we were planning on running some compatibility tests. We need to look at this.
Comment 12•15 years ago
|
||
I can't reproduce this with Firebug 1.4 and a debug 1.9.2 tree at revision c600af9cdd05.
Comment 13•15 years ago
|
||
that's exciting. Henrik, can you still reproduce this on a current build in a fresh profile?
Updated•15 years ago
|
Flags: blocking1.9.2? → blocking1.9.2+
Reporter | ||
Comment 14•15 years ago
|
||
Still crashes with yesterdays Namoroka nightly: bp-5f2b276a-7a15-4b7f-9440-e12bc2091030
Reporter | ||
Comment 15•15 years ago
|
||
(In reply to comment #12) > I can't reproduce this with Firebug 1.4 and a debug 1.9.2 tree at revision > c600af9cdd05. Oh, install 1.4.2. Probably that's the reason?
Comment 16•15 years ago
|
||
so, gdb clearly fingers jsClass as null, if you can reproduce this with gdb, please add printfs or something to find out how jsClass becomes null.
Updated•15 years ago
|
Summary: Crash when detaching a tab after the window has been restored and with Firebug installed [@nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ] → Crash when detaching a tab after the window has been restored and with Firebug installed [ @nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ]
Assignee | ||
Comment 18•15 years ago
|
||
Taking, but I will not be able to get to it for a bit. Anyone should feel free to steal.
Assignee: general → dmandelin
Comment 19•15 years ago
|
||
topcrash #23 for 3.6 Beta 1 so far http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6b1&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsScriptSecurityManager%3A%3AdoGetObjectPrincipal%28JSObject*%29
Summary: Crash when detaching a tab after the window has been restored and with Firebug installed [ @nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ] → Crash when detaching a tab after the window has been restored and with Firebug installed [@nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ]
Whiteboard: [firebug-p1][firebug-blocks] → [firebug-p1][firebug-blocks][crashkill]
Assignee | ||
Comment 20•15 years ago
|
||
I hate to have to ask this again, but is this still happening? I just went through the STR with yahoo and google in the 2 tabs with today's 1.9.2 nightly and Firebug 1.4.2, and did not get a crash.
Reporter | ||
Comment 21•15 years ago
|
||
Yes, it's still crashing. Lemme create a testing profile. Seems like there is something other involved too.
Reporter | ||
Comment 22•15 years ago
|
||
David, here I have the ultimate steps to reproduce the problem which I have checked with a fresh profile: 1. Install Firebug 1.4.2 (with disabled version check) 2. Enable the script panel of Firebug 3. Close the window (there are already 2 open tabs) 4. Redo the closing of the window 5. Drag a tab to its content area After step 5 you have to see the crash (fingers crossed).
Does this happen with FB 1.4.5 (the latest)? If not, I don't think it's a blocker.
Reporter | ||
Comment 24•15 years ago
|
||
(In reply to comment #23) > Does this happen with FB 1.4.5 (the latest)? If not, I don't think it's a > blocker. Tested and also happens with Firebug 1.4.5 installed. Chris, do we know if we are also crashing for people who don't have Firebug installed? Would be good to know if Firebug is the one and only add-on which causes this crash.
Assignee | ||
Comment 25•15 years ago
|
||
(In reply to comment #22) > David, here I have the ultimate steps to reproduce the problem which I have > checked with a fresh profile: Thanks. That crashes it for me. Enabling the script panel was what I think I was missing before.
Assignee | ||
Comment 26•15 years ago
|
||
dvander and I think this is caused by the way the tracer calls into the debugger when leaving trace. It calls cx->debugHooks->callHook in SynthesizeFrame, but the frame does not have its proper argv values filled in yet (that happens immediately after the call to SynthesizeFrame). Thus, the functions the debugger hook call end up operating on junk argv data, so we crash. Brendan, any advice here? Is there a natural place the debugger hook call should be moved to?
Updated•15 years ago
|
Whiteboard: [firebug-p1][firebug-blocks][crashkill] → [firebug-p1][firebug-blocks][crashkill] DUPEME
Comment 28•15 years ago
|
||
this signature appears for mac and windows, the other one is mac only. if we combine lets test cross platform. the number of firefox versions where the signature is seen is also more broad than bug 519719. signature list 100 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) 1 @0x0 | nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) os breakdown 19 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Mac OS X 10.5.8 9L30 17 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Mac OS X 10.6.2 10C540 14 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Windows NT 5.1.2600 Service Pack 3 14 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Mac OS X 10.5.8 9L31a 9 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Windows NT 5.1.2600 Service Pack 2 8 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Mac OS X 10.6.1 10B504 7 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Windows NT 6.0.6001 Service Pack 1 4 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Windows NT 6.1.7600 2 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Windows NT 6.1.7100 1 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Windows NT 6.1.7201 1 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Windows NT 6.0.6002 Service Pack 2 1 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Windows NT 6.0.6000 1 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Windows NT 5.1.2600 Service Pack 1 1 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Mac OS X 10.4.11 8S165 1 nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Linux 0.0.0 Linux 2.6.31.6-acer-aspire-one #1 SMP Wed Nov 11 17:43:16 CET 2009 i686 GNU/Linux 1 @0x0 | nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) Mac OS X 10.6.2 10C540 distribution of all versions where the nsScriptSecurityManager::doGetObjectPrincipal crash was found on 20091112-crashdata.csv 54 Firefox 3.6b2 18 Firefox 3.6b1 18 Firefox 3.5.5 6 Firefox 3.0.15 2 Firefox 3.5.3 1 Firefox 3.6b3pre 1 Firefox 3.5.4 1 Firefox 3.5.2
OS: Mac OS X → All
Assignee | ||
Comment 29•15 years ago
|
||
The cause is the same as for bug 519719, so I'm going to assume it's the same for now, and then recheck this test case when that bug is fixed.
Depends on: 519719
Reporter | ||
Comment 30•15 years ago
|
||
David, on Linux I always run into this crash when switching between the normal and Private Browsing mode. Once you stop the PB mode and press the shortcut again before all your windows (>1) have been restored, the browser will crash in this stack. See bp-e8de973a-1569-4057-8700-e9faf2091120
Summary: Crash when detaching a tab after the window has been restored and with Firebug installed [@nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ] → Crash when detaching a tab after the window has been restored and with Firebug installed [@ nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ]
Comment 31•15 years ago
|
||
One interesting detailed comment for this signature that might lead to a good reduced test case.. 20091119-crashdata.csv: nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) http://www.swrasl.org/Table/Book-Nominees/ http://crash-stats.mozilla.com/report/inde/5ebab5d6-5d66-4894-9fe9-774cd2091119 Firefox 3.6b3 20091115172407 1.9.2 Mac OS X 10.6.2 10C540 x86 0xffffffffffffff34 This seems to happen every time there is a call to an external link that tries to open up a new window. I know my system has submitted several incidents (using the same email address as a reference)...these crashes all seem to be when I either right+click and try to open a link in a new window, or in this incident, it was a link on a web page that the target was a new window. | | Thanks!!
Comment 32•15 years ago
|
||
oops the link to the crash report should be http://crash-stats.mozilla.com/report/index/5ebab5d6-5d66-4894-9fe9-774cd2091119
Assignee | ||
Comment 33•15 years ago
|
||
OK. A fix to bug 519719 went into TM on 11/20. I just tested and found that the STR in comment 22 cause a crash with the 11/20 build (thus not having the fix to bug 519719), but work in the 11/22 build, so I'm going to dup against bug 519719. That fix has landed to TM. It hasn't made it to m-c or 1.9.2 yet but it should get landed there as it has already been marked blocking 1.9.2.
Whiteboard: [firebug-p1][firebug-blocks][crashkill] DUPEME → [firebug-p1][firebug-blocks][crashkill]
Updated•15 years ago
|
Summary: Crash when detaching a tab after the window has been restored and with Firebug installed [@ nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ] → Crash when detaching a tab after the window has been restored and with Firebug installed [@ nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ][@nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) ]
Updated•15 years ago
|
Whiteboard: [firebug-p1][firebug-blocks][crashkill] → [firebug-blocks][crashkill]
Updated•13 years ago
|
Crash Signature: [@ nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ]
[@nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) ]
You need to log in
before you can comment on or make changes to this bug.
Description
•