On Sun, Jan 23, 2011 at 09:04:46PM +0100, Stefan Sperling wrote: > On Sun, Jan 23, 2011 at 02:18:10PM +0100, Stefan Sperling wrote: > > Turns out qemu is running into libpthreads bugs. > > > 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(). > > > With rthreads, the OpenBSD guest finished a cvs checkout and also > > a kernel build. I'm starting a make build on it next. > > With this patch to libpthread, an OpenBSD guest in a qemu run with > pthreads (not rthreads) has finished a cvs checkout and a kernel build. > I'm starting a make build on it now. (BTW the instance run with rthreads > is still happily running make build.) > > The patch protects the region around _thread_machdep_restore_float_state(), > which severly messes with the stack of the current thread, from being > interrupted by signals. > Please test. This problem could also affect other applications. > > I'm not sure of the bit making sig_defer_count volatile is needed, > but it does have an effect on the assembly code generated for > _thread_kern_sig_defer() and _thread_kern_sig_undefer(). > Thrown in because it cannot hurt.
i will try to take a look tomorrow. i don't think the volatile is needed so i prefer if it's not included unless we found otherwise. f.-
