GNOME Bugzilla – Bug 546339
multithread crash, SELECT statement to get last inserted row did not return any row
Last modified: 2008-10-26 09:13:38 UTC
Steps to reproduce: 1. 2. 3. Stack trace: first in my population engine I get: ** (anjuta:9242): WARNING **: SELECT statement to get last inserted row did not return any row ** (anjuta:9242): CRITICAL **: gda_set_get_holder_value: assertion `GDA_IS_SET (set)' failed (anjuta:9242): GLib-GObject-CRITICAL **: g_value_get_int: assertion `G_VALUE_HOLDS_INT (value)' failed after few seconds a crash appears: ** ** ERROR:(gda-sqlite-recordset.c:204):gda_sqlite_recordset_new: assertion failed: (! ps->stmt_used) Program received signal SIGABRT, Aborted.
+ Trace 204596
Thread 2983844752 (LWP 11102)
Other information: maybe this bug is related to the lack of the implementation of GdaLockable interface in some objects. I'm using GdaSet, GdaDataModel, GdaHolder. I'm reporting it here the same, my apologies if I'm wrong.
Could you provide a small example (outside of Anjuta) to make it easy to reprocude the problem?
this is not happening if I put a mutex on the engines that avoids concurrent statements executions each on a different gda connection. It's happening instead if I let libgda's mutexes to protect the execs. I'm trying to reproduce it outside Anjuta but still no luck...
running with --g-fatal-warnings doesn't help: ** Message: sdb_engine_populate_db_by_tags () [New Thread 0xb57bdb90 (LWP 9168)] ** Message: generating new statement.. 14 ** Message: generating new statement.. 23 ** WARNING **: SELECT statement to get last inserted row did not return any row aborting... Program received signal SIGABRT, Aborted.
+ Trace 205775
Thread 3020716944 (LWP 9165)
the point in which this error occurs is random.
I don't know if can be useful, but I also get a crash with the following stack: ** Message: sdb_engine_populate_db_by_tags () Implementation missing: gda_sqlite_provider_statement_execute() in gda-sqlite-provider.c line 2107 [New Thread 0xb2dffb90 (LWP 18802)] [New Thread 0xb1dffb90 (LWP 18803)] [Thread 0xb2dffb90 (LWP 18802) exited] ** Message: sdb_engine_populate_db_by_tags () ** ** ERROR:(gda-sqlite-recordset.c:205):gda_sqlite_recordset_new: assertion failed: (! ps->stmt_used) Program received signal SIGABRT, Aborted.
+ Trace 205859
Thread 3019889552 (LWP 18799)
Created attachment 117649 [details] test case ok, I'm getting something strange running this example. I get these messages at some random point: elapsed 0.360424 av 0.334876 ** Message: thread completed cycle ** Message: thread completed cycle ** (process:5443): CRITICAL **: gda_connection_event_get_event_type: assertion `GDA_IS_CONNECTION_EVENT (event)' failed elapsed 0.421882 av 0.336458 ** Message: thread completed cycle What does the program? Basically it opens two connections to two different dbs, though only cnc2 is used now. Then it creates some threads and a 'main_thread' function that insist on that cnc2. I'm getting only a critical warning, but I think that I can get something more. btw: probably I'm missing some correct implementation? Please let me know if that's the case.
(In reply to comment #5) got a crash trace: elapsed 0.315662 av 0.384091 elapsed 0.302091 av 0.383390 elapsed 0.306286 av 0.382737 elapsed 0.280266 av 0.381876 Program received signal SIGSEGV, Segmentation fault.
+ Trace 205896
Thread 3050474384 (LWP 9274)
Can you check with revision 3199? I've added some locking when executing a statement (I wonder why I had not done this earlier...)
(In reply to comment #7) > Can you check with revision 3199? I've added some locking when executing a > statement (I wonder why I had not done this earlier...) > well, the crash does not appear anymore, nor into the example program nor in Anjuta. But I found some drawbacks: * on example_threaded: some little memory is still leaked. You can let run only the thread function, excluding the execute_statement (): you'll see a little but constant increase of memory taken by `example` process. Here it reaches 6 MB at the end of all the threads. If you want to see it better just increase the number of threads. * on Anjuta the scanning of files and symbols is very very quick. The drawback is that with this new method [and excluding my mutex on the engine] it only scans 104 symbols. They should be 708 or so. BTW: this can be easily my fault, since the engine mutex-free hasn't been tested so much. If you say that this kind of bug cannot be of libgda, I'll have a deeper check on my module. thanks, Massimo
(In reply to comment #8) > * on Anjuta the scanning of files and symbols is very very quick. The drawback > is that with this new method [and excluding my mutex on the engine] it only > scans 104 symbols. They should be 708 or so. > BTW: this can be easily my fault, since the engine mutex-free hasn't been > tested so much. If you say that this kind of bug cannot be of libgda, I'll have > a deeper check on my module. > ok it seems like it was my fault. A little memleak still remains anyway.
Created attachment 121350 [details] Big memleak with rev #3244. With libgda revision 3244 I notice big memleaks running this example. Note that the example is an updated version of initial "test case". The memleak seems to occur only when 'thread_statement ()' function is called. No problem instead with 'execute_statement ()'.
Can you check with rev #3245 (for me the mem used no remains constant). Thanks for the test case.
all ok, works fine here too, thanks Massimo