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

Vivien Malerba <[email protected]>
Newsgroups gmane.comp.gnome.db
Message-ID <[email protected]>
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.