Re: [fluid-dev] glib crash

[Element Green]

I haven't built FluidSynth in a while and just saw those warnings that you mention.

Looking over the changes with the glib thread API, I see that mutexes are now generally statically allocated (they could be either statically or dynamically allocated in previous versions), so the deprecation of g_mutex_new/free is because of that.  g_thread_init() is deprecated because the thread system is now always initialized at the start of a glib based application.  I doubt the crash is because of this.  Functional equivalents of those functions are still provided, albeit with the compile time warnings, and I would imagine that for those functions the additional support code to utilize the recommended interfaces is trivial.  So I suspect that the crashes will still occur.  However, I did update subversion to include changes which will use different glib thread APIs depending on the version (pre or post 2.32).  It might make a difference.

Best regards,

Element Green

On Mon, Aug 19, 2013 at 9:55 AM, address@hidden <address@hidden> wrote:

Hello,

trying to build a debug version of glib, and will do some tests on the failing target machines.

In the meantime, I wanted to note that when I compile fluidsynth against the latest glib (v2.36.3), I get a lot a deprecation warnings related to mutex and threads :

/Users/antoine/Documents/Code/fluidXtra/src/fluidsynth-1.1.5/src/utils/fluid_sys.h:161:31: 'g_thread_init' is deprecated

/Users/antoine/Documents/Code/fluidXtra/src/fluidsynth-1.1.5/src/utils/fluid_sys.h:162:10: 'g_mutex_new' is deprecated

/Users/antoine/Documents/Code/fluidXtra/src/fluidsynth-1.1.5/src/midi/fluid_midi_router.c:150:3: 'g_static_mutex_free' is deprecated

etc..

Looking at the glib header files, I see this, in deprecated/gthread.h

GLIB_DEPRECATED_IN_2_32

void     g_thread_init                   (gpointer vtable);

Could this mean that the current glib, when being called with these deprecated functions, fails on some old systems ?

Thank you

Le 16 août 2013 à 18:58, Element Green <address@hidden> a écrit :

Probably my fault for the multiple email post (got stuck in the admin
interface trap due to its size and I approved it without realizing
that it had made it to the list already somehow).

Anyways..

I had a look at the thread_memory_from_self() function in the glib
source code and I don't see anything that would suggest usage of SSE
instructions (its a memory allocation function).  There is a lot of
use of the thread system though, so that could be the culprit.  If you
have a problem system you can test with, I would try building Glib
with debugging information to see if you can get the actual source
code line that is causing the crash.  You could also do a disassembly
dump at the instruction pointer EIP, to see what the actual
instruction is, which also might provide some insight.  Either the
instruction was intended, but not supported on the problem system -
which would mean glib may have been built for a platform that was too
specific, or some sort of corruption is occurring.  Looking at how
glib got built (its build time options, thread support system, etc)
might also be useful information.

Hope that helps.

Best regards,

Element Green

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev