Re: [gnome-db] Libgda4.0.6 warnings and segfault

[Vivien Malerba <vmalerba gmail com>]

> We use only MySQl.
>
> Yes, sorry, I forgot to mention that; I tried to use
> GDA_CONNECTION_OPTIONS_THREAD_SAFE but the code didn't compile. I did a
> search in libgda 4.0.6 src (wich is what we're using now) and I just saw one
> mention of it in gda-connection.h. I thought that it was only for future or
> development versions because that flag still seems to not to be working in
> 4.0.6.
>
> This is what we use now:
>
> db->_priv->conn = gda_connection_open_from_string (db->_priv->provider,
> db->_priv->dsn, db->_priv->db_auth, GDA_CONNECTION_OPTIONS_DONT_SHARE,
> NULL);

This option is not available in version >= 4.0, I guess you meant
GDA_CONNECTION_OPTIONS_NONE.

>
> So, I guess that we should use the development versión to use
> GDA_CONNECTION_OPTIONS_THREAD_SAFE. I'm going to try it to check if it
> solves the problem, although I'm a bit worried because it is not the stable
> version.

The GDA_CONNECTION_OPTIONS_THREAD_SAFE option really only starts a new
thread from which all the "real" connection usage is done, and you get
a "dummy" GdaConnection object which only role is to send requests to
that thread and wait for the reply.

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.

If, as I understand, it is difficult to create a small program which
illustrated the problem, then you can try to add some printf lines to
the gda-mutex.c file (the GdaMutex is a mutex which can be locked
several times by the same thread) to try to identify where the lock
are obtained and not released. I sometimes use a function which prints
a backtrace from within the program using the folloging code (which
outputs a lot of information to ba analysed after the program has
finished):
static void
print_backtrace (void)
{
	int size, i;
	void *buf[200];
	char **fnames;

	size = backtrace (buf, 200);
	fnames = backtrace_symbols (buf, size);
	for(i = 0; i < size; i++) {
		//if (strstr (fnames[i], "gda"))
			printf("\t%s\n", fnames[i]);
	}
	free (fnames);
}


>
> In the meantime, do you know if there are some way to circunvent this
> problem without using the very latest code? Would you suggest to use
> development version in a production environment?

The short answer is: no. However from what I understand, you are
currently in the process of migrating from version 3 to 4, which means
that by the time your migration is complete the 4.2 version will
hopefully have become the new stable version, so it might not be a bad
idea if you wanted to start with the current unstable version now.

Regards,

Vivien