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 545979 - gda_connection_close() brings to a crash
gda_connection_close() brings to a crash
Status: RESOLVED FIXED
Product: libgda
Classification: Other
Component: general
unspecified
Other All
: Normal critical
: ---
Assigned To: malerba
gnome-db Maintainers
Depends on:
Blocks: 358479 548606
 
 
Reported: 2008-08-02 13:23 UTC by Massimo Cora'
Modified: 2008-09-16 17:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Massimo Cora' 2008-08-02 13:23:23 UTC
Steps to reproduce:
reporting here the bug for a better handling. Gnome-db list was notified some days ago.

revision 3186



Stack trace:
I got a crash with revision 3186, after a gda connection is used and
some prepared statements are compiled inside it:

** Message: SymbolDBPlugin: Dectivating SymbolDBPlugin plugin ...
**
** ERROR:(gda-connection.c:3691):statement_weak_notify_cb: assertion
failed: (cnc->priv->prepared_stmts)

Program received signal SIGABRT, Aborted.

Thread 3067164352 (LWP 5743)

  • #0 raise
    from /lib/libc.so.6
  • #1 abort
    from /lib/libc.so.6
  • #2 g_assertion_message
    from /usr//lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??

Other information:
Comment 1 Massimo Cora' 2008-08-27 19:51:49 UTC
further investigations brought me to think that the problem is in the g_object_unref () for the prepared statements.

I think the problem is related to populations threads that mix the statements on a connection with another one.

The bug is happening at a random statement unreffing point when an engine is disconnected and the other is still working.

Comment 2 malerba 2008-08-29 12:27:15 UTC
Can you check the problem is still present with revision 3194?
Comment 3 Massimo Cora' 2008-08-29 17:04:22 UTC
Unfortunately it's still present.

** ERROR:(gda-connection.c:3688):statement_weak_notify_cb: assertion failed: (cnc->priv->prepared_stmts)

Comment 4 Massimo Cora' 2008-09-10 19:05:35 UTC
(In reply to comment #2)
> Can you check the problem is still present with revision 3194?
> 

still present with rev 3204
Comment 5 Massimo Cora' 2008-09-13 19:08:43 UTC
this bug happens either when I unref the statements before the gda_connection_close () or after.
May it be that the statements of a connection are static? They could be overwritten by the ones of another connection.
In Anjuta I have this:

connection1 -> get connected
connection1 -> generate prepared statements
connection2 -> get connected
connection2 -> generate prepared statements

connection1 -> unref statements

<-- crash happens -->


Comment 6 Massimo Cora' 2008-09-15 19:06:35 UTC
ok, I started putting g_message () everywhere on gda-connection.c.
What I discovered till now is:

while executing the prepared statements the gda_connection_add_prepared_statement () is called many times, but the associated hash_table reaches correctly the size of 41 elements.
When I'm gonna unreffing the statements from my program I get correctly something like: prepared_stms_stmt_destroyed_cb () from 41 to 0. Then the strange thing: it does print 5 more statement_weak_notify_cb (): I removed the g_assert () replacing it with a debug_message which increase its counter.

What may happen? Probably more objects than necessary are wrongly unreffed. Still don't know where it happen anyway.

Comment 7 malerba 2008-09-16 06:47:22 UTC
Can you try with rev#3205 as I've corrected at least one problem which was that in a g_hash_table_foreach() I was removing items from the hash table which is not allowed (once I read the doc...)?
Comment 8 Massimo Cora' 2008-09-16 17:09:20 UTC
(In reply to comment #7)
> Can you try with rev#3205 as I've corrected at least one problem which was that
> in a g_hash_table_foreach() I was removing items from the hash table which is
> not allowed (once I read the doc...)?
> 

hey it works! it doesn't crash anymore and no warning messages are displayed.
Yes you cannot touch hash_table elements while iterating it with foreach ().

thanks,
Massimo
Comment 9 malerba 2008-09-16 17:21:51 UTC
Great, so I'm closing the bug!