On Fri, Jan 21, 2011 at 06:39:17PM +0100, Stefan Sperling wrote: > On Fri, Jan 21, 2011 at 12:18:28PM +0100, Stefan Sperling wrote: > > It would be interesting to know if this helps others who have seen qemu > > crash. > > Well it did eventually crash again, but with a nonesense trace this time.
Turns out qemu is running into libpthreads bugs. With my patches a Linux guest wouldn't crash qemu anymore, even though it was constantly running 2 builds of Subversion at once and also Subversion's regression test suite (which is very I/O intensive). But even with my qemu patches, an OpenBSD guest would still cause qemu to crash during a simple cvs checkout. The crashes were always in SIGARLM or SIGUSR2 signal handlers. Qemu uses these signals in its I/O code. Some crashes had similar traces as the one seen before, with _thread_kern_sig_defer() apparently calling _thread_kern_sig_undefer(). Some had an apparently corrupt stack -- when this happened, the program counter within the last sigcontext saved for the running thread was always in _thread_machdep_restore_float_state(). Not sure what to make of these crashes. Anyway, I found that qemu runs stable with rthreads, with both Linux and OpenBSD guests, and without any patches. cd /usr/src/lib/librthread make obj depend && make && sudo make install mkdir ~/.lib cd ~/.lib; ln -s /usr/lib/librthread.so.4.1 libpthread.so.13.1 sudo sysctl kern.rthreads=1 env LD_LIBRARY_PATH=$HOME/.lib qemu ... With rthreads, the OpenBSD guest finished a cvs checkout and also a kernel build. I'm starting a make build on it next.
