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

RESOLVED DUPLICATE of bug 519719

Status

()

defect
--
critical
RESOLVED DUPLICATE of bug 519719
10 years ago
8 years ago

People

(Reporter: whimboo, Assigned: dmandelin)

Tracking

({crash, regression, topcrash})

1.9.2 Branch
x86
All
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [firebug-blocks][crashkill], crash signature)

Attachments

(1 attachment)

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?
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.
Whiteboard: [firebug-p1][firebug-blocks]
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.
and again, no other extensions installed?
Keywords: crash
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.
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.
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
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.
anything to report here? Is this still crashing?

I tried this with Firebug 1.5b1 installed and did not crash.
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.
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.
I can't reproduce this with Firebug 1.4 and a debug 1.9.2 tree at revision c600af9cdd05.
that's exciting. Henrik, can you still reproduce this on a current build in a fresh profile?
Flags: blocking1.9.2? → blocking1.9.2+
Still crashes with yesterdays Namoroka nightly: bp-5f2b276a-7a15-4b7f-9440-e12bc2091030
(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

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

Comment 17

10 years ago
currently #68 top crash on 3.6b1.  any updates on who is working on this?
Keywords: topcrash

Updated

10 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

10 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
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

10 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.
Yes, it's still crashing. Lemme create a testing profile. Seems like there is something other involved too.
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.
(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

10 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

10 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?
This looks like a dup of bug 519719, where jorendorff is on the case.

/be
Whiteboard: [firebug-p1][firebug-blocks][crashkill] → [firebug-p1][firebug-blocks][crashkill] DUPEME

Comment 28

10 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

10 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
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

Updated

10 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*) ]

Comment 31

10 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!!
Assignee

Comment 33

10 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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
No longer depends on: 519719
Resolution: --- → DUPLICATE
Duplicate of bug: 519719

Updated

10 years ago
Whiteboard: [firebug-p1][firebug-blocks][crashkill] DUPEME → [firebug-p1][firebug-blocks][crashkill]
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

9 years ago
Whiteboard: [firebug-p1][firebug-blocks][crashkill] → [firebug-blocks][crashkill]
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.