612745 - Prevent cross-thread XPConnect access to nsIClassInfo::MAIN_THREAD_ONLY-flagged objects

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Brendan Eich [:brendan]]

Summary says it all.

/be

Comment 1

[Brendan Eich [:brendan]]

Attachment: minimal patch: enable XPC_CHECK_WRAPPER_THREADSAFETY

Seems to work, browsing with it.

/be

Comment 2

[Brendan Eich [:brendan]]

http://hg.mozilla.org/tracemonkey/rev/9bb386e639e5

/be

Comment 3

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/9bb386e639e5

Comment 4

[Peter Van der Beken [:peterv]]

I don't think that's a full fix, don't we need a similar check in ConstructSlimWrapper? Also, can we just remove XPC_CHECK_WRAPPER_THREADSAFETY if it'll always be defined anyway?

Comment 5

[Brendan Eich [:brendan]]

(In reply to comment #4)
> I don't think that's a full fix, don't we need a similar check in
> ConstructSlimWrapper?

Peter, can you file this one? Even better if you or a slimwrapper guru can fix. I'm overcommitted elsewhere.

> Also, can we just remove XPC_CHECK_WRAPPER_THREADSAFETY if it'll always be defined anyway?

Minimal change at this stage.

/be

Comment 6

[Brendan Eich [:brendan]]

Followup bugs: bug 618126 and bug 618128 (noted at https://wiki.mozilla.org/JavaScript/HandlingThreads).

/be

Comment 7

[Boris Zbarsky [:bzbarsky]]

So if I understand correctly, this prevents creating new wrappers for main-thread-only objects on a non-main thread, right?  If a wrapper for such an object is in the scope of a runnable closure passed to the background thread then this patch doesn't help, as far as I can tell.

It also doesn't help if the problem is the creation and/or refcounting of the C++ object, right?  Because all that happens long before we try to create a wrapper for it...