[AD] OS X crash in native dialog code (was Re: SF.net SVN: alleg:[12852] allegro/branches/4.9/src/macosx/hidjoy.m)

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 25 Jan 2010, at 20:34 , Trent Gamblin wrote:
> Side note, I ran ex_joystick_events with no joysticks attached and it segfaults
> somewhere in the native dialog code. Haven't investigated.

The attached patch (committed) fixes the issue.
The problem was that Allegro's initialisation code used the thread local storage (in particular, it used the error number when allegro.cfg isn't found) before _al_pthreads_tls_init() is called.
There is a FIXME comment in the file (line 739) that refers to a workaround for the situation where get_tls() is called before TLS has been initialised. I'm not sure what the logic is, but it seems to assume that get_tls() will return NULL in this case. However, the manpage for pthread_getspecific() states that

     The effect of calling pthread_getspecific() with a key value that was not obtained from pthread_key_create(), or after a key has been
     deleted with pthread_key_delete(), is undefined.

and in fact, on OS X, it does not return NULL, but some non-zero pointer. Writing to this pointer leads to memory corruption and the reported crash.
The only correct thing to do is to make sure that TLS is initialised before get_tls() is called.
(Aside: the man page also says "If no thread-specific data value is associated with key, the value NULL is returned." which is a little confusing and may be the reason for the assumption that the function returned NULL).

I have activated the ALLEGRO_CFG_PTHREADS_TLS platform setting that seems to have been created especially for this purpose (no other platform apart from the iphone port uses this as far as I can see).
Someone who knows more about this than I do should probably verify that there are no undesirable side effects to calling _al_pthreads_tls_init() in this location. I've removed the call from the OS X system driver, since calling the function again will override the already allocated key. I don't know if there's really much harm in that, but it seemed undesirable to me.

Last but not least, someone should verify that a similar bug does not lurk on other platforms (probably not; the Windows and Linux ports seem to have a native build-in thread local storage system).

Evert

Attachment: tls.diff
Description: Binary data



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/