530567 - Crash opening new window on OSX [@ nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&)][@ nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | nsScriptSecurityManager::doGetObjectPrincipal(JSObject*)]

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The number 16 topcrash on 3.6b3 is currently [1]

nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&)

Given how generic that signature is, there's probably several crashes lumped into one here.

However, looking at the comments for the individual crashes[2], most of the OSX ones mention opening new windows. So there seems like some OSX crash involving opening new windows is a big contributor to this signature.

The stack is pretty big, so it's quite possible that the problem isn't at the top of the crash, but rather somewhere much earlier. Will look more in detail. 

[1] http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.6b3/7
[2] http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=nsCOMPtr_base%3A%3Aassign_from_qi%28nsQueryInterface%2C%20nsID%20const%26%29&version=Firefox%3A3.6b3

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Looked over this crashstack with Luke

http://crash-stats.mozilla.com/report/index/50553afc-1828-4317-888e-a9de32091119

Basically we're starting to run a XBL constructor (frame 25). At some point during this we start tracing (frame 16) and then fall off trace (frame 15). In the process of falling off trace we end up calling into the debug hooks (frame 13).

However there is a known bug on calling the debug hooks while falling off trace causing crashes. This is bug 519719 which has been fixed on the tracemonkey branch.

So with a bit of luck this bug will be fixed once that bug lands on trunk and 1.9.2.

Comment 2

[chris hofmann]

The generic signature makes it a bit hard to sort this out, but 

70% of all the crashes we see for these signatures are on b3  , and only ~14%  are 3.5.5 (data from 2009 11 25).  That would make it a definite volume regression and should block 3.6 
 
distribution of all versions where the nsScriptSecurityManager::doGetObjectPrincipal crash was found on 20091125-crashdata.csv
122     0.701149        3.6b3
24      0.137931        3.5.5

If we have fixes for this we should definitely figure out risk and how to get them landed.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

See comment 1. This is likely fixed on the trace-monkey branch. Don't know if that has been merged to 1.9.2 yet?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I've been assuming that this was the same as bug 521844 (which was duped to bug 519719); I had thought that would be one of the JS fixes we'd get for 3.6b4, but it looks like it hasn't even hit mozilla-central yet.

Comment 5

[Jesse Ruderman]

I chatted with a user who is hitting a lot of nsScriptSecurityManager crashes, with several signatures.  One is topcrash #14 and another is topcrash #17 for Firefox 3.6 Beta 4.  Add the percentages together and it becomes topcrash #4.

bp-d2cb81bd-26b7-44f7-8395-ad5252091127
bp-d63657be-7aeb-4c50-8c45-2c5a32091127
bp-43f736b8-cb59-4c39-8fcc-f44dc2091127

[@nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ]

[@JS_ObjectIsFunction ] called by nsScriptSecurityManager::GetFunctionObjectPrincipal

[@nsScriptSecurityManager::doGetObjectPrincipal(JSObject*) ]

Comment 7

[Marcia Knous [:marcia]]

The bug noted in Comment 6 has a set of STR, and the reporter includes the fact his home directory is not on the system drive. His home
directory is /Volumes/Macintosh HD/Users/chris/ and /Users/chris is symlinked
to it. And it seems he can repro the issue consistently.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I think this should be fixed now that bug 519719 is. If anyone can reproduce using a build with that patch in, please reopen this bug or file a new one.