Closed Bug 544610 Opened 16 years ago Closed 9 years ago

crash [@ nsXPConnect::GetPrincipal(JSObject*, int)] | [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ]

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: wsmwk, Unassigned)

Details

(Keywords: crash, regression, Whiteboard: add-on: noscript [tbird crash])

Crash Data

crash [@ nsXPConnect::GetPrincipal(JSObject*, int)] thunderbird 3.2a1 #3 topcrash (lol) For Thunderbird this is a Trunk only crash, and doesn't exist prior to 3.1a1pre 20091221074205. For firefox it appears to be 3.6-only (only bp-c1d8fb53-429e-4a16-8c76-b95b82100124 has an email address). Either way, suggests the crash is a regression from 1.9.1 Hard to say it is gone. last FF build to crash 20100115144158 last TB build to crash 20100201033538 bp-44cb6174-c3b0-4f3e-8b6a-a731c2100201 thunderbird Switching tabs with search results bp-e9a33b77-cbd4-4aed-be17-dde852100201 (reports no extensions) composing a new email with background indexing active (for another folder) 0 thunderbird.exe nsXPConnect::GetPrincipal js/src/xpconnect/src/nsXPConnect.cpp:2731 1 thunderbird.exe nsScriptSecurityManager::doGetObjectPrincipal caps/src/nsScriptSecurityManager.cpp:2417 2 thunderbird.exe nsScriptSecurityManager::GetFunctionObjectPrincipal caps/src/nsScriptSecurityManager.cpp:2215 3 thunderbird.exe nsScriptSecurityManager::GetFramePrincipal caps/src/nsScriptSecurityManager.cpp:2238 4 thunderbird.exe nsScriptSecurityManager::GetPrincipalAndFrame caps/src/nsScriptSecurityManager.cpp:2283 5 thunderbird.exe nsScriptSecurityManager::GetSubjectPrincipal caps/src/nsScriptSecurityManager.cpp:2343 6 thunderbird.exe nsScriptSecurityManager::CheckPropertyAccessImpl caps/src/nsScriptSecurityManager.cpp:938 7 thunderbird.exe nsScriptSecurityManager::CheckPropertyAccess caps/src/nsScriptSecurityManager.cpp:563 8 thunderbird.exe nsScriptSecurityManager::CheckObjectAccess caps/src/nsScriptSecurityManager.cpp:546 9 mozjs.dll InitExnPrivate js/src/jsexn.cpp:284 10 thunderbird.exe nsScriptSecurityManager::QueryInterface caps/src/nsScriptSecurityManager.cpp:510 ---------------------------------------------------------------- Firefox seen ONLY in 1.9.2 branch, eg 3.6b3 20091115182845 bp-151ade17-c9e2-4b89-bbd5-735ce2091207 lines seem to vary slightly bp-c1d8fb53-429e-4a16-8c76-b95b82100124 (** this crash has an email address) Frame Module Signature [Expand] Source 0 xul.dll nsXPConnect::GetPrincipal js/src/xpconnect/src/nsXPConnect.cpp:2623 1 xul.dll nsScriptSecurityManager::doGetObjectPrincipal caps/src/nsScriptSecurityManager.cpp:2420 2 xul.dll nsScriptSecurityManager::CheckPropertyAccessImpl caps/src/nsScriptSecurityManager.cpp:738 3 xul.dll XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:2304 4 xul.dll XPC_WN_GetterSetter js/src/xpconnect/src/xpcwrappednativejsops.cpp:1784 5 js3250.dll js_Invoke js/src/jsinterp.cpp:1360 6 js3250.dll js_InternalInvoke js/src/jsinterp.cpp:1423 7 js3250.dll js_Interpret js/src/jsops.cpp:1505 8 js3250.dll js_Invoke js/src/jsinterp.cpp:1368 9 js3250.dll js_InternalInvoke js/src/jsinterp.cpp:1423 10 js3250.dll JS_CallFunctionValue js/src/jsapi.cpp:5112 11 xul.dll nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:2134 12 xul.dll nsGlobalWindow::RunTimeout dom/base/nsGlobalWindow.cpp:8075 13 xul.dll nsGlobalWindow::TimerCallback dom/base/nsGlobalWindow.cpp:8409
Component: General → XPConnect
Product: Thunderbird → Core
QA Contact: general → xpconnect
I see this crash on the Firefox trunk today: http://tinyurl.com/2fcyt68
Occurs for me on Minefield Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101013 Firefox/4.0b8pre. 100% reproducibility with this URL: http://arstechnica.com/web/news/2010/10/how-to-use-abuse-and-leave-facebook-groups.ars
Some testing reveals that this only occurs with HW acceleration off.
This is the #1 topcrash on trunk.
blocking2.0: --- → ?
Keywords: topcrash
URL where I get this crash: http://salsa.democracyinaction.org/dia/track.jsp?v=2&c=7penmdrZrnI0nmfqTcZk2ftmwXvUFjon Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101013 Firefox/4.0b8pre ID:20101013225426 Crash report: http://crash-stats.mozilla.com/report/index/bp-d50468ee-d5e8-4be4-859b-81bef2101014
This is caused by noscript and is new even tho it has the same old stack, you should blacklist noscript until a new ver is out or it will be a crash fest
For new i mean this happens with noscript after the brain transplant landing
OS: Windows Vista → All
Summary: crash [@ nsXPConnect::GetPrincipal(JSObject*, int)] → crash [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ XPCWrappedNative::GetObjectPrincipal ]
Summary: crash [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ XPCWrappedNative::GetObjectPrincipal ] → crash [@ nsXPConnect::GetPrincipal(JSObject*, int)]
This seems to be pretty much confirmed that it only happens if NoScript is installed. In which case, surely it's an invalid bug in which the responsibility isn't to patch Firefox but rather the extension? It has been reported. http://forums.informaction.com/viewtopic.php?f=7&t=5225 In the meantime I highly recommend all effected to disable NoScript until an update is available.
in crash bp-ef3a9cd7-5a5f-4724-bdf6-9878a2101011, is noscript in the extension list as {F8147CF4-B9E3-445B-AA87-081ED66548F8} v1.6.6 ?
Summary: crash [@ nsXPConnect::GetPrincipal(JSObject*, int)] → crash [@ nsXPConnect::GetPrincipal(JSObject*, int)] - [@ nsScriptSecurityManager::doGetObjectPrincipal] caused by noscript add-on
Whiteboard: add-on: noscript
blocking2.0: ? → beta7+
If you go to Correlations tab of crash reports in comment 10, only 73% of crashes have users with installed noscript and 89% of crashers have users with installed Adblock plus. So the title is wrong. Moreover, can you provide some crash reports with the new crash signature you introduced in the title ?
In that crash report, it is in the extension list with that version. (In reply to comment #13) > in crash bp-ef3a9cd7-5a5f-4724-bdf6-9878a2101011, is noscript in the extension > list as {F8147CF4-B9E3-445B-AA87-081ED66548F8} v1.6.6 ?
Please, see the discussion in bug 604368.
Status: NEW → RESOLVED
Closed: 15 years ago
OS: All → Windows 7
Resolution: --- → DUPLICATE
Summary: crash [@ nsXPConnect::GetPrincipal(JSObject*, int)] - [@ nsScriptSecurityManager::doGetObjectPrincipal] caused by noscript add-on → crash [@ nsXPConnect::GetPrincipal(JSObject*, int)]
(In reply to comment #14) > If you go to Correlations tab of crash reports in comment 10, only 73% of > crashes have users with installed noscript and 89% of crashers have users with > installed Adblock plus. I only checked thunderbird, and thunderbird isn't showing relevant corellations > So the title is wrong. If you mean the add-on bit about noscript? I defer to others judgement. but noscript is in every thunderbird crash that lists extensions except bp-fec4228e-87c3-4ed1-bd4d-fc6932100226 > Moreover, can you provide some crash reports with the new crash signature you > introduced in the title ? all stacks in comment 0, plus all the thunderbird crashes from that era[1], and all thunderbird crashes from the past month [2] Note: none of the thunderbird crashes are win7, they are all windows XP. So, I'm no clear that this is a dup from a thunderbird perspective. [1] http://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=nsXPConnect::GetPrincipal(JSObject*,%20int)&date=3/14/2010%2010:51:20&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsXPConnect::GetPrincipal(JSObject*,%20int) [2] http://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=nsXPConnect::GetPrincipal(JSObject*,%20int)&date=10/14/2010%2010:52:29&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsXPConnect::GetPrincipal(JSObject*,%20int)
isn't it the case, that the only way this can be a dup of bug 604368 is if comment 0 crashes is a core bug and weren't fixed, and bug 604368 is NOT a recent regression?
Whiteboard: add-on: noscript → add-on: noscript [tbird crash]
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Let's clear the situation here this bug was originally filled against thunderbird by you it has the same stack but it's not the same i guess because this started with today firefox build so probably it's not a dupe but two different bugs with the same stack
> Note: none of the thunderbird crashes are win7, they are all windows XP. So, > I'm no clear that this is a dup from a thunderbird perspective. Firefox crashes happen on Windows XP and Windows 7, but a bug can not be classified as Windows > all stacks in comment 0, plus all the thunderbird crashes from that era[1], and > all thunderbird crashes from the past month [2] Stack traces in comment 0 are about one kind of crash that does not exists anymore in Thunderbird. Stack traces from comment 1 are the same as in bug 604368. It is #1 top crasher in Firefox 4.0b8pre for the last week.
Thanks for the info. Actually I didn't compare any current firefox stacks to any thunderbird stacks. So comment 18 (which wasn't perfectly worded) was only an attempt to say the rationale for duping, from what was written in the comments, didn't totally add up for me since no one commented about thunderbird crashes. The entire history of the TB crashes: * comment 0 are all trunk, 14 in a short time span - likely the same trunk user * bp-71d585d7-c826-4be1-9889-548f32100822 on aug 22 with 20100802165400 v3.1.2. * rare v3.1.4 crashes in the past month http://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=nsXPConnect::GetPrincipal(JSObject*,%20int)&date=10/14/2010%2010:52:29&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsXPConnect::GetPrincipal(JSObject*,%20int That's it for thunderbird. no more. agree, yes, the v3.2 stack isn't the same as v3.1 eg. bp-7b5f43e4-4d3c-4248-aed0-568a42100304 v3.2a1pre Build ID 20100224032321 bp-71d585d7-c826-4be1-9889-548f32100822 v3.1.2 bp-ef3a9cd7-5a5f-4724-bdf6-9878a2101011 v3.1.4 (in the last month) as for the trunk crash, unless someone points me to a bug that probably fixed it I can't say it's gone - our experience is we don't have enough daily thunderbird trunk users to say when a crash goes away/gets fixed by examining trunk crash stats - even over a period of many months.
Status: REOPENED → NEW
Summary: crash [@ nsXPConnect::GetPrincipal(JSObject*, int)] → crash [@ nsXPConnect::GetPrincipal(JSObject*, int)] | [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ]
here is the profile of the crashes against firefox builds. still seeing a spike on builds from oct 13 date total count build, count build, 20101006 4 2 4.0b62010091408, 2 3.6.102010091412, 20101007 20101008 1 4.0b62010091408 1 , 20101009 1 3.6.102010091412 1 , 20101010 3 3.6.102010091412 3 , 20101011 69 4.0b8pre2010101105 69 , 20101012 104 52 4.0b8pre2010101204, 50 4.0b8pre2010101105, 2 3.6.102010091412, 20101013 105 67 4.0b8pre2010101204, 36 4.0b8pre2010101304, 1 4.0b7pre2010100204, 1 3.6.62010062523,
4 crashes in two days. I'm scared to open sites. For example, zive.cz suffers from this; I can't browse the site.
This bug is now only for Thunderbird crashes. If you want to give information on crashes with the same signature but a different stack trace, go to bug 604368.
blocking2.0: beta7+ → ---
Crash Signature: [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ]
I don't see any of this signature on Firefox or Thunderbird versions in the past 4 weeks. Resolving as works for me.
Status: NEW → RESOLVED
Crash Signature: [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ] → [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ]
Closed: 15 years ago → 14 years ago
Resolution: --- → WORKSFORME
I'm not sure exactly what you checked but ... there are still FF crashes with signature (though I didn't check the stacks) https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A9.0b3&version=Firefox%3A9.0b2&version=Firefox%3A9.0b1&version=Firefox%3A8.0.1&version=Firefox%3A8.0&version=Firefox%3A11.0a1&version=Firefox%3A10.0a2&query_search=signature&query_type=exact&query=nsXPConnect%3A%3AGetPrincipal%28JSObject*%2C%20int%29&reason_type=contains&date=11%2F29%2F2011%2017%3A21%3A35&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=nsXPConnect%3A%3AGetPrincipal%28JSObject*%2C%20int%29 and there are definitely still thunderbird crashes with similar stack. TB8 https://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=contains&query=nsXPConnect%3A%3AGetPrincipal&reason_type=contains&date=11%2F29%2F2011%2017%3A01%3A37&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&admin=1&signature=nsXPConnect%3A%3AGetPrincipal%28JSObject*%2C%20int%29 Mac signature nsXPConnect::GetPrincipal of which the top several frames are the same, except for the line number of frame 1 bp-bf827629-befd-4d9e-bbb2-449742111108
Status: RESOLVED → REOPENED
Crash Signature: [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ] → [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ] [@ nsXPConnect::GetPrincipal]
OS: Windows 7 → All
Resolution: WORKSFORME → ---
Wayne - Sorry, there must have been something wrong with my query. It's been reopened and closed a bunch of times. So 2 questions? Is this going to get fixed? Do we actively want people trying to fix this as a priority - meaning is the volume significant enough.
(In reply to Sheila Mooney from comment #27) > reopened and closed a bunch of times. So 2 questions? > Is this going to get fixed? do you mean for thunderbird? not crashing for me, so in short I don't know - don't the cause, and we don't have steps > Do we actively want people trying to fix this as a priority - meaning > is the volume significant enough. not a priority - less than a dozen thunderbird crashes in a month I don't think the noscript whiteboard notation applies for thunderbird users
Crash Signature: [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ] [@ nsXPConnect::GetPrincipal] → [@ n(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ] [@ nsXPConnect::GetPrincipal]
I will remove the top crash keyword for now but leave it open.
Keywords: topcrash
Crash Signature: [@ n(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ] [@ nsXPConnect::GetPrincipal] → [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ] [@ nsXPConnect::GetPrincipal]
Crash Signature: [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ] [@ nsXPConnect::GetPrincipal] → [@ nsXPConnect::GetPrincipal(JSObject*, int)] [@ nsXPConnect::GetPrincipal(JSObject*, int) | nsScriptSecurityManager::doGetObjectPrincipal ] [@ nsXPConnect::GetPrincipal] [@ nsXPConnect::GetPrincipal | nsScriptSecurityManager::doGetObjectPrincipal ]
I'm marking this bug as WORKSFORME as bug crashlog signature didn't appear from a long time (over half year).
Status: REOPENED → RESOLVED
Closed: 14 years ago → 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.