No idea how widespread this is, but under Ubuntu 12.04 x86_64 a
default SDL build with CMake would suffer deadlocks in
SDL_DestroySemaphore, while a build with autotools ran without a
problem. About 95% of the time it?d happen in SDL_Init, but failing
that it?d occur during SDL_Quit. A typical backtrace from a deadlocked
start from the latest hg:
#0 __lll_lock_wait () at
…/nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
#1 0x00007ffff690c065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007ffff690beba in __pthread_mutex_lock (mutex=0x6f6950) at
pthread_mutex_lock.c:61
#3 0x00007ffff66cc3a4 in SDL_mutexP (mutex=0x6f6950) at
/home/scott/Development/fourier/SDL/src/thread/pthread/SDL_sysmutex.c:103
#4 0x00007ffff66cc84f in SDL_DestroySemaphore (sem=0x6f8860) at
/home/scott/Development/fourier/SDL/src/thread/generic/SDL_syssem.c:126
#5 0x00007ffff6651c8f in SDL_CreateThread (fn=0x7ffff6651ded
<SDL_TimerThread>, name=0x7ffff66d1ba4 “SDLTimer”,
data=0x7ffff68fe4a0)
at /home/scott/Development/fourier/SDL/src/thread/SDL_thread.c:286
#6 0x00007ffff66520da in SDL_TimerInit () at
/home/scott/Development/fourier/SDL/src/timer/SDL_timer.c:230
#7 0x00007ffff65d35de in SDL_InitSubSystem (flags=33) at
/home/scott/Development/fourier/SDL/src/SDL.c:76
#8 0x00007ffff65d39cf in SDL_Init (flags=33) at
/home/scott/Development/fourier/SDL/src/SDL.c:193
A bit of digging revealed that the CMake litmus test for PTHREADS_SEM
didn?t have a definition for main(), which made gcc explosively give
up when linking.
Also the tests for HAVE_RECURSIVE_MUTEXES, HAVE_SEM_TIMEDWAIT and
HAVE_PTHREAD_SPINLOCK failed because Linux was set to link in
-lpthread; using the GCCism -pthread works, and seems to be necessary
for the linker to find methods like pthread_mutexattr_settype. I have
no idea what it does differently, given that a scan with ldd doesn?t
show any extra libraries linked in other than libpthread, but I?m
willing to leave that mystery to the GCC high-priests.
So yes, detecting PTHREADS_SEM fixes the problem, but since the point
of these tests is to disable unavailable features or cutover to a
failsafe, I?m concerned that the failsafe for running with PTHREADS
and without PTHREADS_SEM doesn?t work that well. Unfortunately I have
zero insight as to what it might mean; everything I know about
libpthread fits comfortably onto a piece of fortune cookie paper. But
this behaviour was very reproducible on two x86_64 Ubuntu machines,
and also quite annoying.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: fixcmakepthread.patch
Type: application/octet-stream
Size: 888 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130118/a01f72ed/attachment.obj