521844 - 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&) ]

Status: RESOLVED DUPLICATE of bug 519719

(Core :: JavaScript Engine, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 1

[Rob Campbell [:rc] (:robcee)]

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.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 3

[Rob Campbell [:rc] (:robcee)]

and again, no other extensions installed?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

First bad revision is:
Changeset:  32084:9d625ed36560
User:       David Mandelin <[e-mail]>
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.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Full stack from GDB

Comment 7

[Tony Chung [:tchung]]

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

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

[Rob Campbell [:rc] (:robcee)]

anything to report here? Is this still crashing?

I tried this with Firebug 1.5b1 installed and did not crash.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

[Rob Campbell [:rc] (:robcee)]

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

[Blake Kaplan (:mrbkap) (inactive)]

I can't reproduce this with Firebug 1.4 and a debug 1.9.2 tree at revision c600af9cdd05.

Comment 13

[Rob Campbell [:rc] (:robcee)]

that's exciting. Henrik, can you still reproduce this on a current build in a fresh profile?

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Still crashes with yesterdays Namoroka nightly: bp-5f2b276a-7a15-4b7f-9440-e12bc2091030

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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

[timeless]

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.

Comment 17

[chris hofmann]

currently #68 top crash on 3.6b1.  any updates on who is working on this?

Comment 18

[David Mandelin [:dmandelin]]

Taking, but I will not be able to get to it for a bit. Anyone should feel free to steal.

Comment 19

[Carsten Book [:Tomcat]]

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

Comment 20

[David Mandelin [:dmandelin]]

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.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Yes, it's still crashing. Lemme create a testing profile. Seems like there is something other involved too.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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).

Comment 23

[Mike Shaver (:shaver emeritus)]

Does this happen with FB 1.4.5 (the latest)?  If not, I don't think it's a blocker.

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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.

Comment 25

[David Mandelin [:dmandelin]]

(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.

Comment 26

[David Mandelin [:dmandelin]]

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?

Comment 27

[Brendan Eich [:brendan]]

This looks like a dup of bug 519719, where jorendorff is on the case.

/be

Comment 28

[chris hofmann]

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

Comment 29

[David Mandelin [:dmandelin]]

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.

Comment 30

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 31

[chris hofmann]

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

[chris hofmann]

oops the link to the crash report should be 
http://crash-stats.mozilla.com/report/index/5ebab5d6-5d66-4894-9fe9-774cd2091119

Comment 33

[David Mandelin [:dmandelin]]

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.