Re: [gnome-db] Libgda4.0.6 warnings and segfault
Vivien Malerba <[email protected]>
| Newsgroups | gmane.comp.gnome.db |
|---|---|
| Message-ID | <[email protected]> |
On 5 February 2010 19:11, Alberto Roman Linacero <[email protected]> wrote: >> > In the specific case of MySQL, if it has been compiled with the >> > --enable-thread-safe-client option, then the API should be thread safe >> > and the resulting GdaConnection object (without the >> > GDA_CONNECTION_OPTIONS_THREAD_SAFE option) should also be thread safe. >> > So the problem seems to be a bug in Libgda where a lock is acquired >> > and not released. >> >> I guess that MySQL should be compiled with that option, but I'll compile a >> new one to be sure (we're using tyhe MySQL 5.1 debian package from >> dotdeb.org) > > Well, I've compiled MySQL with the --enable-thread-safe-client but it still > fails. Also, this message appears in my /var/log/messages: > > Feb 5 07:53:11 opensourcesim ossim-server[7987]: MySQL was not compiled with > the --enable-thread-safe-client flag, only one thread can access the provider > > But something should be wrong somewhere, because the binaries has been > compiled with that flag. To re-check if I was wrong, I took the default mysql > binaries (wich has that option), but the message still appears. > There is obviously something wrong there as the mysql_thread_safe() function directly returns the status of the --enable-thread-safe-client flag... > I started to think that something regarding the gda multithread detection > could be involved. So I modified the providers/mysql/gda-mysql-provider.c > file to force the thread use: > > if (!mysql_thread_safe ()) { > // provider_class->limiting_thread = g_thread_self (); > provider_class->limiting_thread = NULL; > } > else > provider_class->limiting_thread = NULL; > > But as you can imagine, I wasn't lucky, the mysql queries fails, and with the > insertions I get a new error: "MySQL server has gone away" messages (strange, > because I tested the connection with gda_connection_is_opened() before the > insertion and it's still alive) The result is understandable. Still, I would like to do some more testing in case there is a libgda bug somewhere. Can you give me an outline on how many MySQL silmutaneous connections you use, and from how many threads each connection is used, so I can try to write a test program? > > Well, it seems that I'll wait until release 4.2 before continue testing. We're > going to come back to libgda2.3, because we're going to release a new > software version very soon and I can't continue the migration. I'll continue > with the migration and the tests in two weeks or so. > Of course in 4.2 this whould work because the new connection option makes sure only one thread actually uses the MySQL connection object. Vivien