The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org