XPConnect uses nsScriptSecurityManager off the main thread [@ nsScriptSecurityManager::CheckPropertyAccessImpl(unsigned int, nsAXPCNativeCallContext*, JSContext*, JSObject*, nsISupports*, nsIURI*, nsIClassInfo*, char const*, int, void**) ]

RESOLVED FIXED

Status

()

Core
XPConnect
--
critical
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: mrbkap, Assigned: Justin Lebar (not reading bugmail))

Tracking

({verified1.9.1, verified1.9.2})

unspecified
x86
Windows 7
verified1.9.1, verified1.9.2
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+, blocking1.9.2 .11+, status1.9.2 .11-fixed, blocking1.9.1 .14+, status1.9.1 .14-fixed)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

7 years ago
We've seen a couple reports where extensions that run JS code that deals with XPConnect off the main thread end up calling into nsScriptSecurityManager and then crashing (http://crash-stats.mozilla.com/report/index/2dcc69c6-ff24-4d30-9594-ba34f2100517 is one example).

We need to figure out why XPConnect is getting a hold of the main thread's security manager on these other threads. Without this, any extension that runs JS off the main thread (even if it's careful about what objects it uses off the main thread) risks crashing.

Comment 1

7 years ago
http://mxr.mozilla.org/mozilla-central/ident?i=GetSecurityManager

All of the magic wrapper code uses this which accesses a global

1048 XPCConvert::NativeInterface2JSObject(XPCLazyCallContext& lccx,
1244         if(NS_SUCCEEDED(rv) && wrapper)
1255             if (allowNativeWrapper &&
1256                 !xpc_SameScope(wrapper->GetScope(), xpcscope, &sameOrigin))
1309                 if(!JS_IsSystemObject(ccx, flat))
1329                         nsIScriptSecurityManager *ssm =
1330                             XPCWrapper::GetSecurityManager();
(Reporter)

Comment 2

7 years ago
Surprisingly, that's not actually the problem (I have no clue why, I suspect it might be because it's impossible for !xpc_SameScope to be true off the main thread). The problem shown in the crash report in comment 0 is that the "default" security manager for a not-main thread is not null, which is definitely a bug.
(Reporter)

Updated

7 years ago
Assignee: nobody → justin.lebar+bug
(Assignee)

Comment 3

7 years ago
For my reference, these are my notes from talking with mrbkap about how to reproduce this issue:

From chrome, using nsIThreadManager, dispatch a runnable to some other code I own.

Touch xpconnect. Create an object using Components.classes.(some threadsafe interface), then touch it in a way that isn't quickstubbed.

Maybe crashes in nsScriptSecurityManager (somewhere), due to bug in GetDefaultSecurityManager.
 * Could put NS_ABORT_IF_FALSE(IsMainThread) in nsScriptSecurityManager::CanAccess
(Assignee)

Comment 4

7 years ago
Created attachment 474904 [details] [diff] [review]
Testcase

Testcase.  The new browser test triggers an assertion I added to GetDefaultSecurityManager and kills the browser.
(Assignee)

Comment 5

7 years ago
Created attachment 474934 [details] [diff] [review]
Patch v1

Returns null when we're not the main thread.
Attachment #474904 - Attachment is obsolete: true
Attachment #474934 - Flags: review?(mrbkap)

Comment 6

7 years ago
qref, perhaps?
OS: Mac OS X → Windows 7
(Assignee)

Comment 7

7 years ago
Created attachment 474954 [details] [diff] [review]
Patch v1.1

Ack, sorry.  qref'ed.
Attachment #474934 - Attachment is obsolete: true
Attachment #474954 - Flags: review?(mrbkap)
Attachment #474934 - Flags: review?(mrbkap)
(Reporter)

Updated

7 years ago
Attachment #474954 - Flags: review?(mrbkap) → review+
(Assignee)

Comment 8

7 years ago
Blake, since this is crashing plugins, should this block?

Comment 9

7 years ago
Yes please. Firefox crashes every few minutes and that really gets my goat.
(Reporter)

Comment 10

7 years ago
Yeah, I think so.
blocking1.9.2: --- → ?
(Assignee)

Updated

7 years ago
blocking2.0: --- → ?

Updated

7 years ago
blocking2.0: ? → betaN+

Comment 11

7 years ago
Could you please manage fixing this already in the next release? Current Firefox is nearly unusable because of so many crashes (mainly invoked by Yoono which I don't want to miss) and I don't want to switch back to 3.6.4 (should be Xulrunner 1.9.2.4, right?) where the problem didn't exist.
Duplicate of this bug: 597287

Updated

7 years ago
Summary: XPConnect uses nsScriptSecurityManager off the main thread → XPConnect uses nsScriptSecurityManager off the main thread [@ nsScriptSecurityManager::CheckPropertyAccessImpl(unsigned int, nsAXPCNativeCallContext*, JSContext*, JSObject*, nsISupports*, nsIURI*, nsIClassInfo*, char const*, int, void**) ]
blocking1.9.2: ? → needed
status1.9.2: --- → wanted

Comment 14

7 years ago
We want this on the branch but wouldn't block a release on it, as it looks like there are only ~1000 crashes total per release. Please ask for approval on the patch when ready and we'll get it in the current in-flight update.
(Assignee)

Updated

7 years ago
Attachment #474954 - Flags: approval1.9.2.11?
blocking1.9.1: --- → needed
status1.9.1: --- → wanted

Comment 15

7 years ago
Is there a possibility of our own code calling nsScriptSecurityManager off the main thread and thus this fix would cause issues?
(Assignee)

Comment 17

7 years ago
http://hg.mozilla.org/mozilla-central/rev/46310d87f848
(Assignee)

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Comment 18

7 years ago
Whoops; didn't mean to resolve this, since we still need to land on branches.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 19

7 years ago
Does this same fix apply to 1.9.1? We have it marked needed there as well. Approving for 1.9.2.11. Please ask for approval for 1.9.1.14 if it is needed there as well.

Updated

7 years ago
Attachment #474954 - Flags: approval1.9.2.11? → approval1.9.2.11+
We use the status1.9.x fields to track branch status
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED

Updated

7 years ago
blocking1.9.1: needed → .14+
blocking1.9.2: needed → .11+
IOW change status1.9.2 from "wanted" to ".11-fixed" when you land, and similarly for the 1.9.1 branch
Fixed on branches.

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/89508ed59ad9
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3affdd6e23e8
status1.9.1: wanted → .14-fixed
status1.9.2: wanted → .11-fixed
Verified for 1.9.1 and 1.9.2 based on passing unit test.
Keywords: verified1.9.1, verified1.9.2
You need to log in before you can comment on or make changes to this bug.