Re: [fluid-dev] glib crash

[David Henningsson]

On 08/19/2013 05:55 PM, 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..

I've seen these too. What I'm afraid of is that if I convert the stuff
to use the newer recommended functions instead, people using old
versions of glib might suffer. So it's a bit of a balance.

What do others think?

> 
> 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 ?

Deprecated functions should not cause any problems, at least not in
theory. And as long as glib don't go into version 3 or something like
that, they should remain intact.

Of course, bugs can always happen. But have you tried the glib list?
They might have better knowledge than us about glib specifics.

I don't know much about how mac works, but if I got the same stack trace
on my Linux machine, I would start fluidsynth with gdb and dissasemble
the thread_memory_from_self function, looking at what instruction is at
thread_memory_from_self + 187. (This is the same as Element suggested btw.)

> 
> Thank you
> 
> 
> Le 16 août 2013 à 18:58, Element Green <address@hidden
> <mailto: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 <mailto:address@hidden>
>> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>>
> 
> 
> 
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>