Il 06/02/2013 12:25, Daniel P. Berrange ha scritto: >> > Something is definitely needed to learn the syscall that is killing >> > QEMU. But I don't think the signal handler approach is going to >> > work. We tried that and ran into too many situations where signals >> > were being blocked by libraries (spice is one example). And we >> > didn't want to get in the business of patching third party libraries >> > to allow SIGSYS. > We absolutely should be fixing libraries not to screw up signal handling > in applications. I see that the SPICE worker thread blocks every single > signal except SEGV/FPE/ILL, which is just completely bogus. There's no > acceptable reason for SPICE to block so many signals.
There definitely is. It is blocking the signals only in the worker thread, so that the library does not get in the way of applications that do not expect other threads to exist. By keeping the signals blocked, the application is free to handle them: 1) knowing that a signal will always be delivered to the thread running the event loop, and will interrupt select/poll; 2) without having to enforce _both_ thread-safety and async-signal-safety. The problem is that SIGSYS is a per-thread signal, like SIGSEGV/FPE/ILL. So it is impossible to block it, what the kernel does if you block it is treat it as SIG_DFL. Unfortunately, SIGSYS is obscure enough that nobody knows about it and/or realizes it is a companion to SIGSEGV/FPE/ILL. So _yes_, we should indeed get in the business of patching third-party libraries (and QEMU itself, see util/qemu-thread-posix.c) to allow SIGSIGV/FPE/ILL/SYS, but that's where the scope of the problem ends. Paolo
