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 740923 - Crash in tracker-store at tracker_fts_shutdown_db
Crash in tracker-store at tracker_fts_shutdown_db
Status: RESOLVED FIXED
Product: tracker
Classification: Core
Component: FTS
unspecified
Other Windows
: Normal normal
: ---
Assigned To: tracker-general
Depends on:
Blocks:
 
 
Reported: 2014-11-30 14:07 UTC by Philip Van Hoof
Modified: 2014-12-27 16:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Protect global variable against simul destruction (1.03 KB, patch)
2014-11-30 14:24 UTC, Philip Van Hoof
rejected Details | Review

Description Philip Van Hoof 2014-11-30 14:07:48 UTC


Thread 1 (LWP 2028)

  • #0 __GI___libc_free
    at malloc.c line 2970
  • #1 g_free
    at gmem.c line 197
  • #2 g_strfreev
    at gstrfuncs.c line 2424
  • #3 tracker_fts_shutdown_db
    at tracker-fts.c line 268
  • #4 tracker_db_interface_sqlite_finalize
    at tracker-db-interface-sqlite.c line 1338
  • #5 g_object_unref
    at gobject.c line 3197
  • #6 __nptl_deallocate_tsd
    at pthread_create.c line 156
  • #7 start_thread
    at pthread_create.c line 315
  • #8 ??
    from /lib/libc.so.6
  • #9 ??
    from /lib/libc.so.6

Thread 2 (LWP 2025)

  • #0 releaseMemArray
    at sqlite3.c line 62951
  • #1 releaseMemArray
    at sqlite3.c line 62940
  • #2 closeAllCursors
    at sqlite3.c line 63520
  • #3 sqlite3VdbeHalt
    at sqlite3.c line 64016
  • #4 sqlite3VdbeReset
    at sqlite3.c line 64259
  • #5 sqlite3VdbeFinalize
    at sqlite3.c line 64334
  • #6 sqlite3_finalize
    at sqlite3.c line 65819
  • #7 tracker_db_statement_finalize
    at tracker-db-interface-sqlite.c line 1813
  • #8 g_object_unref
    at gobject.c line 3197
  • #9 g_hash_table_remove_all_nodes
    at ghash.c line 500
  • #10 g_hash_table_unref
    at ghash.c line 1026
  • #11 close_database
    at tracker-db-interface-sqlite.c line 1098
  • #12 tracker_db_interface_sqlite_finalize
    at tracker-db-interface-sqlite.c line 1341
  • #13 g_object_unref
    at gobject.c line 3197
  • #14 __nptl_deallocate_tsd
    at pthread_create.c line 156
  • #15 start_thread
    at pthread_create.c line 315
  • #16 ??
    from /lib/libc.so.6
  • #17 ??
    from /lib/libc.so.6

Thread 4 (LWP 2027)

  • #0 tracker_fts_shutdown_db
    at tracker-fts.c line 265
  • #1 tracker_db_interface_sqlite_finalize
    at tracker-db-interface-sqlite.c line 1338
  • #2 g_object_unref
    at gobject.c line 3197
  • #3 __nptl_deallocate_tsd
    at pthread_create.c line 156
  • #4 start_thread
    at pthread_create.c line 315
  • #5 ??
    from /lib/libc.so.6
  • #6 ??
    from /lib/libc.so.6

Thread 5 (LWP 2007)

  • #0 tracker_fts_shutdown_db
    at tracker-fts.c line 265
  • #1 tracker_db_interface_sqlite_finalize
    at tracker-db-interface-sqlite.c line 1338
  • #2 g_object_unref
    at gobject.c line 3197
  • #3 g_private_replace
    at gthread-posix.c line 1067
  • #4 tracker_db_manager_shutdown
    at tracker-db-manager.c line 1279
  • #5 tracker_data_manager_shutdown
    at tracker-data-manager.c line 4612
  • #6 tracker_main_main
    at /usr/src/debug/tracker-1.1.4+git4/tracker/src/tracker-store/tracker-main.vala line 329
  • #7 main
    at /usr/src/debug/tracker-1.1.4+git4/tracker/src/tracker-store/tracker-main.vala line 158
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Comment 1 Philip Van Hoof 2014-11-30 14:24:10 UTC
Created attachment 291831 [details] [review]
Protect global variable against simul destruction
Comment 2 Martyn Russell 2014-12-02 09:56:17 UTC
Comment on attachment 291831 [details] [review]
Protect global variable against simul destruction

Hi Philip, I thought we had a fix for this already somewhere...

Anyway, I kind of knew about this bug but wasn't able to reproduce it very easily.

This fix looks right to me, but I wonder if we shouldn't also protect the creation of the property_names too with the/a mutex? I am thinking of re-initialisation or race condition cases.
Comment 3 Philip Van Hoof 2014-12-02 10:29:12 UTC
(In reply to comment #2)
> (From update of attachment 291831 [details] [review])
> Hi Philip, I thought we had a fix for this already somewhere...
> 
> Anyway, I kind of knew about this bug but wasn't able to reproduce it very
> easily.
> 
> This fix looks right to me, but I wonder if we shouldn't also protect the
> creation of the property_names too with the/a mutex? I am thinking of
> re-initialisation or race condition cases.

To be completely correct we should protect each access to the variable, including read, create and destroy, with the same static mutex.

Or we do a thread local copy of the table for each thread. That's also a possibility (which I think might even be better).
Comment 4 Martyn Russell 2014-12-02 10:36:45 UTC
(In reply to comment #3)
> To be completely correct we should protect each access to the variable,
> including read, create and destroy, with the same static mutex.

Indeed.
 
> Or we do a thread local copy of the table for each thread. That's also a
> possibility (which I think might even be better).

I don't think a thread local copy is the right approach because then there could be discrepancies between the table information between threads. It's unlikely but ...
Comment 5 Martyn Russell 2014-12-27 16:17:18 UTC
Comment on attachment 291831 [details] [review]
Protect global variable against simul destruction

This patch is no longer needed, Carlos applied a patch upstream using GPrivate APIs.
Comment 6 Martyn Russell 2014-12-27 16:39:18 UTC
Carlos fixed this commit:

commit a105aacd5531d0d5e7d2af7c12c156c3375135af
Author: Carlos Garnacho <carlosg@gnome.org>
Date:   Sun Nov 30 12:34:31 2014 +0100

    tracker-fts: Make the property list per-thread data
    
    This is global memory, and shared across threads, which doesn't play well
    when (un)initializing it, as multiple simultaneous accesses can occur.