Re: [fluid-dev] glib crash

[Element Green]

On Mon, Aug 19, 2013 at 12:04 PM, address@hidden <address@hidden> wrote:

Hello,

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

>

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

I have built glib in debug mode using "brew install --test" and had it tested on the faulty machines (I cannot physically go there). But this does not give any more specific information on the faulty line.

I would expect that the backtrace would provide more information when built with debugging symbols.  I'm not very familiar with Mac OSX, but I imagine there is some way to generate a core dump, when the application crashes.  You could probably load this core up on your own machine with gdb, with the source code and get a more detailed backtrace.

I seem to remember the backtrace of your crash indicating that the crash was occurring somewhere in g_slice_alloc().  I've often found that the glib memory slice subsystem can be sensitive to memory corruption.  It could be that there is some other unrelated memory corruption going on which is causing this.  Normally in these types of situations I might utilize valgrind to try and catch such memory corruption, but this can be problematic when trying to debug realtime software.  But since it occurs on startup, it should still provide some valuable information.

 

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

How can I ask the user to do this ? He does not have a development machine...

How did you get that backtrace information originally?  I would recommend researching how to get Mac OSX to dump a core file (usually by typing certain commands in a shell prior to executing the application).  With the core file and related source code in hand, you should be able to extract that information from the debugger.

 

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

I built it against glib 2.26.3, using homebrew, by doing a "brew install --universal glib" command. This is on my Mac 10.8.4 system.

Of note is that this version is prior to 2.32 which is where the thread API changed (which you were getting those build time warnings with).

 

I am a bit helpless here. Any help appreciated.

Thanks

I know the feeling of debugging in the dark.  Can be very frustrating.  It sounds like you have a user who is willing to perform some steps to helping you track down the problem though, which is great.

Best regards,

Element Green