On Tue, 3 Apr 2007, andrzej zaborowski wrote:
Hi, with QEMU_AUDIO_DRV set to "sdl" and booting from CD-ROM with AIO on a Linux host and with SDL 1.2.11, qemu locks up in sigwait() (the main thread) and SDL_SemWait() (the audio thread) as soon as music is playing and CD-ROM is being read at the same time. It appears that audio/sdlaudio.c:sdl_callback is called by SDL when it shouldn't be called, and block-raw.c is trying to flush the AIO operations, so it would seem that the SIGUSR2 which is intended to wake up the sigwait is instead captured by SDL and SDL tries to be smart and calls sdl_callback. sdl_callback has a sanity check but this check is *after* SDL_SemWait() so it is not triggered. The strange thing is that using a different signal (tried SIGUSR1 and SIGPOLL) for AIO doesn't help. Does SDL catch all signals? I could be totally wrong because I don't know SDLAudio at all.
If my reading of SDLs sources are correct then it shouldn't be trying to catch any signals when explicitly instructed not to do so (which is done in sdl.c (SDL_INIT_NOPARACHUTE flag)).
Any ideas about the exact reason why this is happening and how to fix it?
Given the semantics of signal delivery in POSIX what you describe might happen, what is a little surprising is that SDL (btw. which backend SDL uses?) doesn't complain. Here's my theory: signal will be delivered to the arbitrary thread that happens to not block it, for whatever reason, the thread SDL created to do audio processing is picked up, which leads to some system call being interrupted(eventually) and -1 (errno == EINTR), SDL happily continues calling stuff. One solution would be to explicitly block everything upon entering sdl_callback for the first time. This is ugly and can have any consequences one cares to imagine, but that's SDL for you (any particular reason why you are using it?) P.S. Quoting PTHREAD_SIGNAL(3) NOTES For !sigwait! to work reliably, the signals being waited for must be blocked in all threads, not only in the calling thread, since otherwise the POSIX semantics for signal delivery do not guarantee that it's the thread doing the !sigwait! that will receive the signal. The best way to achieve this is block those signals before any threads are created, and never unblock them in the program other than by calling !sigwait!. -- vale