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 619682 - crash on libgda using GDA_CONNECTION_OPTIONS_THREAD_SAFE
crash on libgda using GDA_CONNECTION_OPTIONS_THREAD_SAFE
Status: RESOLVED INCOMPLETE
Product: libgda
Classification: Other
Component: SQLite provider
4.1.x
Other Linux
: Normal major
: ---
Assigned To: malerba
gnome-db Maintainers
Depends on:
Blocks: 565773
 
 
Reported: 2010-05-25 22:41 UTC by Massimo Cora'
Modified: 2010-06-07 19:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Massimo Cora' 2010-05-25 22:41:02 UTC 
After a change to GDA_CONNECTION_OPTIONS_THREAD_SAFE my libgda git master has a crash.
I didn't yet changed mutex policies into the core, but when libgda is using two different databases at the same time (no problem discovered with just one [but that is thread safe at symbol-db level]) I've got the following stack trace.

+ Trace 222096

Thread 140736628230416 (LWP 24122)

  • #0 *__GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #1 *__GI_abort
    at abort.c line 88
  • #2 __libc_message
    at ../sysdeps/unix/sysv/linux/libc_fatal.c line 173
  • #3 malloc_printerr
  • #4 *__GI___libc_free
    at malloc.c line 3738
  • #5 gda_sql_statement_free
    at gda-statement-struct.c line 170
  • #6 gda_statement_dispose
    at gda-statement.c line 226
  • #7 g_object_unref
    from /usr/lib/libgobject-2.0.so.0
  • #8 free_private_shared_data
    at gda-data-select.c line 384
  • #9 gda_data_select_dispose
    at gda-data-select.c line 462
  • #10 gda_thread_recordset_dispose
  • #11 g_object_unref
    from /usr/lib/libgobject-2.0.so.0
  • #12 sdb_engine_get_tuple_id_by_unique_name2
    at symbol-db-engine-core.c line 993
  • #13 sdb_engine_add_new_sym_type
    at symbol-db-engine-core.c line 4158
  • #14 sdb_engine_add_new_symbol
    at symbol-db-engine-core.c line 5203
  • #15 sdb_engine_populate_db_by_tags
    at symbol-db-engine-core.c line 1517
  • #16 sdb_engine_ctags_output_thread
    at symbol-db-engine-core.c line 1620
  • #17 ??
    from /lib/libglib-2.0.so.0
  • #18 ??
    from /lib/libglib-2.0.so.0
  • #19 start_thread
    at pthread_create.c line 300
  • #20 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #21 ?? 






Comment 1


malerba





          2010-05-26 14:12:59 UTC
        



It would be usefull to have the backtrace of all the threads you have, or even better a standalone testcase in which the core dump occurs.
Just as a reminder, the GDA_CONNECTION_OPTIONS_THREAD_SAFE option does not mean that the GdaDataModel resulting from a SELECT's execution can be used by several threads at the same time.






Comment 2


Massimo Cora'





          2010-05-30 12:39:42 UTC
        



(In reply to comment #1)
> It would be usefull to have the backtrace of all the threads you have, or even
> better a standalone testcase in which the core dump occurs.

actually I received that crash only once. I'll report as many info as possible if it rehappens.

> Just as a reminder, the GDA_CONNECTION_OPTIONS_THREAD_SAFE option does not mean
> that the GdaDataModel resulting from a SELECT's execution can be used by
> several threads at the same time.


well, I'm using GdaDataModel in a thread per time, they're not shared between threads.






Comment 3


Massimo Cora'





          2010-05-30 21:42:11 UTC
        



got it another time:

(gdb) bt




+
Trace
    222165






    

  • 
#0
*__GI_raise

    
                at ../nptl/sysdeps/unix/sysv/linux/raise.c
                  line
                  64

    

    • 

  • 
#1
*__GI_abort

    
                at abort.c
                  line
                  88

    

    • 

  • 
#2
__libc_message

    
                at ../sysdeps/unix/sysv/linux/libc_fatal.c
                  line
                  173

    

    • 

  • 
#3
malloc_printerr

    
                at malloc.c
                  line
                  6239

    

    • 

  • 
#4
_int_free

    
                at malloc.c
                  line
                  4934

    

    • 

  • 
#5
*__GI___libc_free

    
                at malloc.c
                  line
                  3738

    

    • 

  • 
#6
gda_sql_statement_free

    
                at gda-statement-struct.c
                  line
                  170

    

    • 

  • 
#7
gda_statement_dispose

    
                at gda-statement.c
                  line
                  226

    

    • 

  • 
#8
g_object_unref

    
                from
                /usr/lib/libgobject-2.0.so.0

    

    • 

  • 
#9
free_private_shared_data

    
                at gda-data-select.c
                  line
                  384

    

    • 

  • 
#10
gda_data_select_dispose

    
                at gda-data-select.c
                  line
                  462

    

    • 

  • 
#11
gda_thread_recordset_dispose

    • 

  • 
#12
g_object_unref

    
                from
                /usr/lib/libgobject-2.0.so.0

    

    • 

  • 
#13
sdb_engine_get_tuple_id_by_unique_name2

    
                at symbol-db-engine-core.c
                  line
                  1014

    

    • 

  • 
#14
sdb_engine_add_new_scope_definition

    
                at symbol-db-engine-core.c
                  line
                  4845

    

    • 

  • 
#15
sdb_engine_add_new_symbol

    
                at symbol-db-engine-core.c
                  line
                  5423

    

    • 

  • 
#16
sdb_engine_populate_db_by_tags

    
                at symbol-db-engine-core.c
                  line
                  1538

    

    • 

  • 
#17
sdb_engine_ctags_output_thread

    
                at symbol-db-engine-core.c
                  line
                  1641

    

    • 

  • 
#18
??

    
                from
                /lib/libglib-2.0.so.0

    

    • 

  • 
#19
??

    
                from
                /lib/libglib-2.0.so.0

    

    • 

  • 
#20
start_thread

    
                at pthread_create.c
                  line
                  300

    

    • 

  • 
#21
clone

    
                at ../sysdeps/unix/sysv/linux/x86_64/clone.S
                  line
                  112

    

    • 

  • 
#22
??

    • 











(gdb) info threads
* 23 Thread 0x7fffd19c2910 (LWP 26432)  0x00007ffff3f02f05 in *__GI_raise (
    sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
  11 Thread 0x7fffd31c5910 (LWP 26367)  __lll_lock_wait_private ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
  10 Thread 0x7fffd3fff910 (LWP 26352)  0x00007ffff42329eb in read ()
   from /lib/libpthread.so.0
  6 Thread 0x7fffdd2bf910 (LWP 26346)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  5 Thread 0x7fffe9745910 (LWP 26345)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  3 Thread 0x7fffe9f46910 (LWP 26343)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  2 Thread 0x7fffeb1a3910 (LWP 26329)  __lll_lock_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
  1 Thread 0x7ffff7fc8790 (LWP 26326)  0x00007ffff3f91633 in *__GI___poll (
    fds=<value optimized out>, nfds=<value optimized out>, timeout=99)
    at ../sysdeps/unix/sysv/linux/poll.c:87




this time I'm populating just one db, so just one thread access one db.
The other threads you see here are only waiting on a queue.






Comment 4


Massimo Cora'





          2010-05-30 22:07:35 UTC
        



Here they are some more cases, I don't know if they're related.

I'm having a test with transaction and isolation level GDA_TRANSACTION_ISOLATION_SERIALIZABLE.
When the transaction starts there are some concurrent selects probably on a second db. On disposing the thing crashes.

first stack trace:

Program received signal SIGSEGV, Segmentation fault.




+
Trace
    222166






Thread 140736770201872
          (LWP 28675)


    

  • 
#0
g_slice_alloc

    
                from
                /lib/libglib-2.0.so.0

    

    • 

  • 
#1
??

    
                from
                /usr/lib/libgobject-2.0.so.0

    

    • 

  • 
#2
??

    
                from
                /usr/lib/libgobject-2.0.so.0

    

    • 

  • 
#3
g_signal_handlers_disconnect_matched

    
                from
                /usr/lib/libgobject-2.0.so.0

    

    • 

  • 
#4
gda_set_dispose

    
                at gda-set.c
                  line
                  1001

    

    • 

  • 
#5
g_object_unref

    
                from
                /usr/lib/libgobject-2.0.so.0

    

    • 

  • 
#6
sdb_engine_add_new_symbol

    
                at symbol-db-engine-core.c
                  line
                  5724

    

    • 

  • 
#7
sdb_engine_populate_db_by_tags

    
                at symbol-db-engine-core.c
                  line
                  1538

    

    • 

  • 
#8
sdb_engine_ctags_output_thread

    
                at symbol-db-engine-core.c
                  line
                  1641

    

    • 

  • 
#9
??

    
                from
                /lib/libglib-2.0.so.0

    

    • 

  • 
#10
??

    
                from
                /lib/libglib-2.0.so.0

    

    • 

  • 
#11
start_thread

    
                at pthread_create.c
                  line
                  300

    

    • 

  • 
#12
clone

    
                at ../sysdeps/unix/sysv/linux/x86_64/clone.S
                  line
                  112

    

    • 

  • 
#13
??

    • 













Comment 5


Massimo Cora'





          2010-05-30 22:12:41 UTC
        



actually bugzilla wrapped the two stack traces in one. Click on "trace 222166" to see both.

I've got some more info:
the crash doesn't happen if I specify GDA_CONNECTION_OPTIONS_NONE on connection to db.
So actually the problem seems related to parameter GDA_CONNECTION_OPTIONS_THREAD_SAFE.






Comment 6


malerba





          2010-05-31 09:53:21 UTC
        



Using the GDA_CONNECTION_OPTIONS_THREAD_SAFE makes Libgda use some internal threads (not visible to the user), which is the reason it behaves differently compared with GDA_CONNECTION_OPTIONS_NONE. However that does not give enough indications.

From the information you've provided I've created some test cases and still can't figure out what the problem is.

Could you try to provide a standalone test case in which the problem appears (even if only from time to time, in this case if you can also give me a core dump and/or backtraces)?






Comment 7


Massimo Cora'





          2010-05-31 10:07:07 UTC
        



yes, I'll try to do it asap.






Comment 8


Massimo Cora'





          2010-05-31 22:51:11 UTC
        



strange enought, I wrote a test example but I cannot make it crash.
I'll keep trying.
The population seems ok now, no crash too. It's a weird bug.






Comment 9


Massimo Cora'





          2010-06-07 19:37:36 UTC
        



well, I hadn't encountered thig bug anymore.
I'll close the bug as incomplete. If this re-happens I'll reopen it.