From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59234) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SV1VB-0002fh-Ji for qemu-devel@nongnu.org; Thu, 17 May 2012 10:16:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SV1V9-0002Yn-AH for qemu-devel@nongnu.org; Thu, 17 May 2012 10:16:25 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60319 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SV1V9-0002YZ-3h for qemu-devel@nongnu.org; Thu, 17 May 2012 10:16:23 -0400 Message-ID: <4FB5082F.3050506@suse.de> Date: Thu, 17 May 2012 16:16:15 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <4FB4FE3E.7080407@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Signal management in qemu-user List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Alex Barcelo , qemu-devel , Alexander Graf Am 17.05.2012 15:42, schrieb Peter Maydell: > On 17 May 2012 14:33, Andreas F=C3=A4rber 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 pack= age: >> http://repo.or.cz/w/qemu/agraf.git/commit/0760e24b52ff20a328f168ed23b5= 2c9b9c0fd28f >> >> Don't know if it fixes your specific problem. >=20 > 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. Note the term "workaround". :-) /-F --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg