On 17 May 2012 14:33, Andreas Färber <afaer...@suse.de> wrote: > Am 17.05.2012 11:23, schrieb Alex Barcelo: >> Running it in a i386 machine works and gives an output of "0x0d\n0x20". >> Running it in a qemu-i386 segfaults. Because the self-modifying code >> raises a SIGSEGV in the qemu (I understand that it is the method used by >> qemu to handle self-modifying code). But the sigprocmask disables the >> SIGSEGV and the qemu-user... does nothing to avoid it. So the SIGSEGV is >> unmanaged and breaks the program. > > Alex has the following SIGSEGV workaround queued for our openSUSE package: > http://repo.or.cz/w/qemu/agraf.git/commit/0760e24b52ff20a328f168ed23b52c9b9c0fd28f > > Don't know if it fixes your specific problem.
No, that's a different issue, see the analysis here: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02868.html In that case an internal-to-QEMU allocation fails (because the guest imposes a severe rlimit), we don't handle it very well and die horribly. The commit you link to above is a sticking plaster on the problem and definitely not OK for master. > Peter had some ideas how to refactor signal handling but iirc > didn't have time to work on it himself. That was mostly to do with solving the problem of signals occurring during emulation of a system call and the consequent race conditions: http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00384.html I think Alex Barcelo's problem here is unrelated. I'm not very surprised by it, though -- linux-user is not very robust in complex edge cases (and in particular is really poor for threaded programs). -- PMM
