We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1709

Summary: PATCH: fix CMake tests for libpthread feature detection under Linux
Product: SDL Reporter: Scott Percival <code>
Component: buildAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: gabomdq, shirishag75
Version: HG 2.0   
Hardware: x86_64   
OS: Linux   
Attachments: Fix Linux pthread detection in CMake
Fix cmake test for PTHREADS_SEM

Description Scott Percival 2013-02-01 23:03:59 UTC 
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.
Comment 1 Scott Percival 2013-02-01 23:05:28 UTC 
Created attachment 1032 [details]
Fix Linux pthread detection in CMake
Comment 2 Frederick Lee 2013-04-16 04:01:59 UTC 
Created attachment 1110 [details]
Fix cmake test for PTHREADS_SEM

Alternate patch.  I ran into the same problem; system is (also) x86-64, Ubuntu 12.04.2, using cmake 2.8.7.  Similar symptoms to Scott's, reached similar conclusions.  Attached is the change I implemented to compile with cmake.

Of particular note, LDFLAGS went under CMAKE_REQUIRED_LIBRARIES, so that the "-lpthread" switch shows up towards the end of the command line, where it's available for resolving(?) pthread symbols.  In any case, putting "-lpthread" at the end made compiles work better.

Documentation for cmake 2.8.7 indicates CHECK_C_SOURCE_COMPILES requires main() to be in there:
>                 <code>       - source code to try to compile, must define 'main'

As an aside, docs for gcc-4.6 lists "-pthread" for only RS/6000, PowerPC, and Solaris 2.  Docs imply the switch is semi-magical to get pthreads to work on those platforms.  I think the switch is unnecessary/excessive under "LINUX".
Comment 3 Gabriel Jacobo 2013-04-19 12:31:14 UTC 
Fixed in http://hg.libsdl.org/SDL/rev/a2bddc1fb02f.

For reference, some of the stuff I found out while researching the issue...

Solving the deadlocks was achieved by adding -pthread in the LDFLAGS. That alone seemed to be enough to get "torturethread" working.

Why? When HAVE_PTHREAD_SEM is not defined (in this case because the test was faulty *and* we were missing the -pthread flag), the script includes generic/SDL_syssem.c, which in turn uses SDL_LockMutex which uses pthreads. Something (AFAICT it's an issue with reentrant threads, but I'm not 100% certain) makes pthread_mutex_lock fail if -pthread was not provided when compiling, but I'm fairly certain it's not our responsibility.

I did go further down the rabbit hole, and configured with --disable-pthreads. On Linux, this has the effect of defining SDL_THREADS_DISABLED so you get no thread support (generic doesn't kick in).

I tried to hack around this (undefining SDL_THREADS_DISABLED), to discover a recursion issue on the generic code (which I don't know if it's intended or not)...the generic version of SDL_CreateSemaphore calls the generic version of SDL_CreateMutex and then the generic version of SDL_CreateMutex calls SDL_CreateSemaphore, etc...infinite recursion (which doesn't happen if you use only one of those functions, as is the case when HAVE_PTHREAD_SEM is not defined).

In the end Sam told me that by design the platform has to provide either semaphores or mutexes, which makes sense (if you have neither, threading will be disabled).