521753 - threadsafety problems in move player extension causing Firefox 3.5.* crashes

Status: RESOLVED WORKSFORME

(Firefox :: Extension Compatibility, defect, P2)

Description

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

The extension with ID "[e-mail]", which I assume is what one gets from http://www.movenetworks.com/install-move-player (but haven't verified this yet), appears to be causing Firefox 3.5.* crashes at the following signatures:
  nsCycleCollectingAutoRefCnt::decr(nsISupports*)
  nsEventListenerManager::Release()
  KiFastSystemCallRet (pure virtual function call)
  nsPresContext::Release()
  nsDOMEvent::Release()
  nsTextNode::Release()
  etc.

Crashes at these signatures are likely due to a bug in the code in that
extension:  they show up when code does reference-counting of main-thread-only
objects on other threads.  I haven't yet tested the extension, but this seems likely to be the case.

This is easy for the developers of the extension to detect if they compile a
debug build of Firefox and test the extension in that debug build:  then they
will see assertion dialogs whenever they violate the threadsafety invariants
(with an option to drop into the debugger).  We should contact them somehow so
they can fix the extension; we may also want to consider blocklisting.

Comment 1

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

(In reply to comment #0)
> This is easy for the developers of the extension to detect if they compile a
> debug build of Firefox and test the extension in that debug build:  then they
> will see assertion dialogs whenever they violate the threadsafety invariants
> (with an option to drop into the debugger).  We should contact them somehow so
> they can fix the extension; we may also want to consider blocklisting.

Instructions for doing this are at:
https://developer.mozilla.org/En/Simple_Firefox_build
https://developer.mozilla.org/en/Windows_Build_Prerequisites
They probably want to do a build from the 1.9.1 release branch (which
corresponds to Firefox 3.5); that's pulled from the hg repository at
http://hg.mozilla.org/releases/mozilla-1.9.1/

The key is that they want to do a build with --enable-debug and
--disable-optimize, which means adding these two lines:
ac_add_options --disable-optimize
ac_add_options --enable-debug
when creating the "mozconfig" file as instructed in the first link above.

Comment 2

[Peter Clegg]

Move Networks is aware of and are looking into possible causes of this issue.  We have built a debug version of FF for Mac and did not get assertion dialogs for violating thread safety.  Working on a Windows version today (11/3/09).
Contact information for communication is: [e-mail]

Comment 3

[Damon Sicore (:damons)]

Thanks a bunch, Peter, for taking the time to comment.  It's really important for us to start this process.  If you need any help at all, please don't hesitate to ask here.  We're really focusing on these issues, and we will respond.

Comment 4

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

On Mac, the assertions will show up on standard output (if you're not starting FirefoxDebug from within Terminal, you can see them in Console); on Windows they'll show up as dialogs.

Comment 5

[Jarom Loveridge]

Using debug builds of Firefox I have not received any errors with our latest version of the Move plug-in surrounding adding or removing of event listeners. On Windows I have noticed that on destroy of the plug-in we generate an assertion stating: Invalid window handle: 'Error'. This does not appear to be a fatal issue as Ignoring it does allow Firefox to continue working. I have assigned resolution of that issue to one of our plug-in developers. We will continue running systems using debug builds of Firefox on multiple customer sites to ensure that we don't encounter any other items that might be causing this issue.

Comment 6

[Damon Sicore (:damons)]

dbaron, could the Invalid window handle be a sign of a problem that would cause this crash?

Comment 7

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

I don't think so.

That said, looking at the current crash data I'm not seeing moveplayer in the correlations for the crashes mentioned in comment 0; it's possible this has gone away somehow.

Comment 8

[Jarom Loveridge]

Identified and corrected the source of the Invalid window handle message. New player build is scheduled for the end of next week. It will undergo heavy testing within debug builds of Firefox on both Windows and Mac. Any items found in testing with the debug version of FF will be corrected before final builds of the player on 13 November 2009.

Comment 9

[Jarom Loveridge]

Incidentally an item we have encountered with Firefox on Mac is that refreshing navigator.plugins sometimes results in the final Plugin entry is undefined. This is especially likely if a new plug-in is installed within an iframe of a parent window. Within the iframe the plug-in is detected as expected but the same is not always the case with the parent window.

Comment 10

[Sheila Mooney]

Dbaron, is this still a problem? Can you update the signature field?

Comment 11

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

In Firefox 4 we changed (see bug 549743) the situation that crashed intermittently due to threadsafety problems to crash 100% of the time (with a runtime threading check in release builds) so that extensions would not release software with this problem.  So this is probably now fixed; if it weren't we'd be seeing a lot more crashes.