After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 670251 - firefox addon crashes Firefox
firefox addon crashes Firefox
Status: RESOLVED FIXED
Product: tracker
Classification: Core
Component: Miners
0.13.x
Other Linux
: Normal critical
: ---
Assigned To: tracker-general
Jamie McCracken
Depends on:
Blocks:
 
 
Reported: 2012-02-16 22:01 UTC by Wolfgang Rosenauer
Modified: 2012-03-08 11:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Wolfgang Rosenauer 2012-02-16 22:01:54 UTC 
While the addon is marked only compatible up to 6.0.* latest versions of Firefox (starting with 10) will load the addon nevertheless.
After it's been enabled again it was found it causes reproducible crashes of Firefox.
Please check
https://bugzilla.novell.com/show_bug.cgi?id=746647

Mozilla devs were looking into the issue and found it's an error in the addon. You can get detailed information from the report there:
https://bugzilla.mozilla.org/show_bug.cgi?id=727745
Comment 1 André Klapper 2012-02-17 12:44:19 UTC 
Which exact tracker version is this about?

Also, could you please paste relevant information from the linked webpages here so it can be found when querying?
Comment 2 Wolfgang Rosenauer 2012-02-17 12:56:20 UTC 
It was found with 0.12.5 but the code is wrong in head still as analyzed by Mozilla.

Backtrace from crash:
Program received signal SIGSEGV, Segmentation fault.
JS_SetContextThread (cx=0x0) at /usr/src/debug/mozilla/js/src/jsapi.cpp:6276
6276        JS_AbortIfWrongThread(cx->runtime);
(gdb) bt

+ Trace 229686

  • #0 JS_SetContextThread
    at /usr/src/debug/mozilla/js/src/jsapi.cpp line 6276
  • #1 ScopedContextThread
    at /usr/src/debug/mozilla/js/src/ctypes/CTypes.cpp line 71
  • #2 js::ctypes::CClosure::ClosureStub
    at /usr/src/debug/mozilla/js/src/ctypes/CTypes.cpp line 5418
  • #3 ffi_closure_SYSV_inner
    at /usr/src/debug/mozilla/js/src/ctypes/libffi/src/x86/ffi.c line 384
  • #4 ffi_closure_SYSV
    at /usr/src/debug/mozilla/js/src/ctypes/libffi/src/x86/sysv.S line 188
  • #5 g_simple_async_result_complete
    from /usr/lib/libgio-2.0.so.0
  • #6 tracker_sparql_connection_get_async_co
    at /home/juerg/Code/tracker/tracker/src/libtracker-sparql-backend/tracker-backend.vala line 373
  • #7 tracker_sparql_connection_get_async_co
    at tracker-backend.c line 3968
  • #8 g_simple_async_result_complete
    from /usr/lib/libgio-2.0.so.0
  • #9 tracker_sparql_backend_get_internal_async_co
    at /home/juerg/Code/tracker/tracker/src/libtracker-sparql-backend/tracker-backend.vala line 318
  • #10 __lambda1_
    at /home/juerg/Code/tracker/tracker/src/libtracker-sparql-backend/tracker-backend.vala line 300
  • #11 ___lambda1__gsource_func
    at tracker-backend.c line 3176
  • #12 g_idle_dispatch
    at gmain.c line 4785
  • #13 g_main_dispatch
    at gmain.c line 2425
  • #14 g_main_context_dispatch
    at gmain.c line 2995
  • #15 g_main_context_iterate
    at gmain.c line 3073
  • #16 g_main_context_iteration
    at gmain.c line 3136
  • #17 nsAppShell::ProcessNextNativeEvent
    at /usr/src/debug/mozilla/widget/src/gtk2/nsAppShell.cpp line 144
  • #18 nsBaseAppShell::DoProcessNextNativeEvent
    at /usr/src/debug/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp line 171
  • #19 nsBaseAppShell::OnProcessNextEvent
    at /usr/src/debug/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp line 324
  • #20 nsThread::ProcessNextEvent
    at /usr/src/debug/mozilla/xpcom/threads/nsThread.cpp line 595
  • #21 NS_ProcessNextEvent_P
    at /usr/src/debug/obj/xpcom/build/nsThreadUtils.cpp line 245
  • #22 mozilla::ipc::MessagePump::Run
    at /usr/src/debug/mozilla/ipc/glue/MessagePump.cpp line 110
  • #23 MessageLoop::RunInternal
    at /usr/src/debug/mozilla/ipc/chromium/src/base/message_loop.cc line 208
  • #24 RunHandler
    at /usr/src/debug/mozilla/ipc/chromium/src/base/message_loop.cc line 201
  • #25 MessageLoop::Run
    at /usr/src/debug/mozilla/ipc/chromium/src/base/message_loop.cc line 175
  • #26 nsBaseAppShell::Run
    at /usr/src/debug/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp line 189
  • #27 nsAppStartup::Run
    at /usr/src/debug/mozilla/toolkit/components/startup/nsAppStartup.cpp line 228
  • #28 XRE_main
    at /usr/src/debug/mozilla/toolkit/xre/nsAppRunner.cpp line 3551
  • #29 do_main
    at /usr/src/debug/mozilla/browser/app/nsBrowserApp.cpp line 198
  • #30 main
    at /usr/src/debug/mozilla/browser/app/nsBrowserApp.cpp line 281 

Analysis from Mozilla:

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
Comment 3 Martyn Russell 2012-03-08 11:19:36 UTC 
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.