|
8077bf3d
|
2014-07-07T21:27:42
|
|
Fixed bug 2618 - incomplete pthread-based lock support should be removed
binarycrusader
Since changeset 358696c354a8, SDL 2.0 has been broken on Solaris when compiling with the Solaris Studio compiler (which uses the pthread implementation of SDL_AtomicLock).
Notably, it gets stuck at the MemoryBarrierRelease in SDL_GetErrBuf:
6585 # 218
6586 if (!tls_errbuf && !tls_being_created) {
6587 SDL_AtomicLock_REAL ( & tls_lock );
6588 if (!tls_errbuf) {
6589 SDL_TLSID slot;
6590 tls_being_created = SDL_TRUE;
6591 slot = SDL_TLSCreate_REAL ( );
6592 tls_being_created = SDL_FALSE;
6593 { SDL_SpinLock _tmp = 0 ; SDL_AtomicLock_REAL ( & _tmp ) ; SDL_AtomicUnlock_REAL ( & _tmp ) ; };
^^^ loops forever above
6594 tls_errbuf = slot;
6595 }
6596 SDL_AtomicUnlock_REAL ( & tls_lock );
6597 }
Running: testthread
(process id 28926)
^Cdbx: warning: Interrupt ignored but forwarded to child.
signal INT (Interrupt) in __nanosleep at 0xfe52a875
0xfe52a875: __nanosleep+0x0015: jae __nanosleep+0x23 [ 0xfe52a883, .+0xe ]
Current function is SDL_Delay_REAL
204 was_error = nanosleep(&tv, &elapsed);
(dbx) where
[1] __nanosleep(0xfeffe848, 0xfeffe850, 0xfe75a5ac, 0xfe5169d8), at 0xfe52a875
[2] nanosleep(0xfeffe848, 0xfeffe850), at 0xfe516a3b
=>[3] SDL_Delay_REAL(ms = 0), line 204 in "SDL_systimer.c"
[4] SDL_AtomicLock_REAL(lock = 0xfeffe88c), line 104 in "SDL_spinlock.c"
[5] SDL_GetErrBuf(), line 225 in "SDL_thread.c"
[6] SDL_ClearError_REAL(), line 216 in "SDL_error.c"
[7] SDL_InitSubSystem_REAL(flags = 0), line 116 in "SDL.c"
[8] SDL_Init_REAL(flags = 0), line 244 in "SDL.c"
[9] SDL_Init(a = 0), line 89 in "SDL_dynapi_procs.h"
[10] main(argc = 1, argv = 0xfeffe948), line 65 in "testthread.c"
As far as I can tell, this is because pthread_spin_trylock() always returns EBUSY for this particular lock; since it works in other places, I'm suspicious.
Different Solaris Studio compiler versions seem to make no difference.
I've verified this is broken on Linux as well if SDL_spinlock.c is modified to use the pthread implementation.
This appears to be because pthread_spin_init() and pthread_spin_destroy() are not used with the locks as required.
|