Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Description • 15 years ago

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

	Rob Campbell [:rc] (:robcee)
	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.

	Henrik Skupin [:whimboo][⌚️UTC+2] 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.

	Rob Campbell [:rc] (:robcee)
	Comment 3 • 15 years ago

and again, no other extensions installed?

	Henrik Skupin [:whimboo][⌚️UTC+2] 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.

	Henrik Skupin [:whimboo][⌚️UTC+2] 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.

	Tony Chung [:tchung]
	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

	Henrik Skupin [:whimboo][⌚️UTC+2] 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.

	Rob Campbell [:rc] (:robcee)
	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.

	Henrik Skupin [:whimboo][⌚️UTC+2] 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.

	Rob Campbell [:rc] (:robcee)
	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.

	Blake Kaplan (:mrbkap) (inactive)
	Comment 12 • 15 years ago

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

	Rob Campbell [:rc] (:robcee)
	Comment 13 • 15 years ago

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

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 14 • 15 years ago

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

	Henrik Skupin [:whimboo][⌚️UTC+2] 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?

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

	chris hofmann
	Comment 17 • 15 years ago

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

	David Mandelin [:dmandelin] 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.

	Carsten Book [:Tomcat]
	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

	David Mandelin [:dmandelin] 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.

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 21 • 15 years ago

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

	Henrik Skupin [:whimboo][⌚️UTC+2] 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).

	Mike Shaver (:shaver -- probably not reading bugmail closely)
	Comment 23 • 15 years ago

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

	Henrik Skupin [:whimboo][⌚️UTC+2] 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.

	David Mandelin [:dmandelin] 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.

	David Mandelin [:dmandelin] 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?

	Brendan Eich [:brendan]
	Comment 27 • 15 years ago

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

/be

	chris hofmann
	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

	David Mandelin [:dmandelin] 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.

	Henrik Skupin [:whimboo][⌚️UTC+2] 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

	chris hofmann
	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!!

	chris hofmann
	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

	David Mandelin [:dmandelin] 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.