Please note that I'm not sure if there can be done something within the JS engine to avoid the crash or if we need to make sure the addon is not enabled or blacklisted. Since Firefox 10 the gnome tracker addon for Firefox (http://projects.gnome.org/tracker/) is reenabled automatically when installed. It has maxVersion=6.0.* but is "only" using js-ctypes to call into its own libs and therefore the addon manager in Firefox decided it might be compatible. On some systems (I couldn't reproduce it myself) this leads to a crash of Firefox. Please check https://crash-stats.mozilla.com/report/index/1cf3d99e-8a27-4892-832a-1fe6f2120215 and the downstream bugreport https://bugzilla.novell.com/show_bug.cgi?id=746647

The stack at the linked bug suggests the closure info's wacky somehow: (gdb) bt #0 JS_SetContextThread (cx=0x0) at /usr/src/debug/mozilla/js/src/jsapi.cpp:6276 #1 0xb71f3037 in ScopedContextThread (cx=0x0, this=<synthetic pointer>) at /usr/src/debug/mozilla/js/src/ctypes/CTypes.cpp:71 #2 js::ctypes::CClosure::ClosureStub (cif=0xac1b8ce0, result=0xbfffc480, args=0xbfffc410, userData=0x9d34c580) at /usr/src/debug/mozilla/js/src/ctypes/CTypes.cpp:5418 userData is a ClosureInfo*. (Note that I'm assuming trunk code I'm reading to state this hasn't substantially changed since 10.) We extract the |cx| field from it to get a context -- which the stack points out is NULL. Anyway. The ctypes data is wacky, but who knows if ctypes is where the actual problem lies. Still, it seems like someone who knows ctypes is the right person to investigate this. ...bholley maybe?

I've managed to reproduce this. Looking into it.

Oh, so the extension isn't actually holding onto the closure it passes into native code. So the relevant data gets GCed, and it crashes. The culprit line is here: http://git.gnome.org/browse/tracker/tree/src/plugins/firefox/chrome/content/plugin.js#n49 The closure is constructed with |tracker.AsyncReadyCallback.ptr(callback_closure)|, which passes it directly into the native function without storing a reference to it. The best solution is probably to do something like: tracker.readyCallback = tracker.AsyncReadyCallback.ptr(callback_closure) tracker.connection_open_async(null, tracker.readyCallback, null); I've updated the docs to add an explicit warning to this effect: https://developer.mozilla.org/en/js-ctypes/js-ctypes_reference/Callbacks Wolfgang, can you take charge of coordinating with the gnome developers to get this fixed?

Gnome Tracker has been added to the compatibility override list, up to version 12.1, so that it doesn't appear as compatible in 10. I couldn't verify the version number of the currently available add-on, so if anyone from Gnome can clarify this for us, it would be greatly appreciated.

Current version of tracker (including the addon) is 0.13.1 (http://git.gnome.org/browse/tracker/commit/?id=31cfacc407048bb8314bbdb1213fb027db3ea387)

(In reply to Bobby Holley (:bholley) from comment #3) > Wolfgang, can you take charge of coordinating with the gnome developers to > get this fixed? Yes, I'll reach out to them.

If possible, let me know the version number of the fixed version once that is available.

> Alex Keybl [:akeybl] 2012-02-16 14:14:13 PST > tracking-firefox10: --- → + Just to be clear, the add-on code has always been wrong/broken. The fact that we crash now and didn't crash before probably just has to do with unrelated GC timing stuff.

(In reply to Bobby Holley (:bholley) from comment #8) > > Alex Keybl [:akeybl] 2012-02-16 14:14:13 PST > > tracking-firefox10: --- → + > > Just to be clear, the add-on code has always been wrong/broken. The fact > that we crash now and didn't crash before probably just has to do with > unrelated GC timing stuff. Thanks Bobby - I'm just tracking so that we keep tabs on the "fallout" from DTC.