From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWuCw-0006o1-DF for qemu-devel@nongnu.org; Mon, 29 Apr 2013 15:57:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWuCv-0004es-Bv for qemu-devel@nongnu.org; Mon, 29 Apr 2013 15:57:54 -0400 Received: from e24smtp01.br.ibm.com ([32.104.18.85]:43647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWuCv-0004dt-02 for qemu-devel@nongnu.org; Mon, 29 Apr 2013 15:57:53 -0400 Received: from /spool/local by e24smtp01.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 29 Apr 2013 16:57:50 -0300 Received: from d24relay02.br.ibm.com (d24relay02.br.ibm.com [9.13.184.26]) by d24dlp02.br.ibm.com (Postfix) with ESMTP id 91C091DC004E for ; Mon, 29 Apr 2013 15:57:46 -0400 (EDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.8.31.93]) by d24relay02.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3TJuhgF41353410 for ; Mon, 29 Apr 2013 16:56:43 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r3TJvi6q017631 for ; Mon, 29 Apr 2013 16:57:44 -0300 Message-ID: <517ED0B8.9070607@linux.vnet.ibm.com> Date: Mon, 29 Apr 2013 16:57:44 -0300 From: Eduardo Otubo MIME-Version: 1.0 References: <517AC9E5.3050204@linux.vnet.ibm.com> <7515044.dYPbKXmJQB@sifl> <517AFCFA.1020407@redhat.com> In-Reply-To: <517AFCFA.1020407@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Paul Moore , qemu-devel@nongnu.org, Eric Paris On 04/26/2013 07:17 PM, Paolo Bonzini wrote: > Il 26/04/2013 23:07, Paul Moore ha scritto: >>>> 3. Debugging and/or learning mode - third party libraries still have the >>>> problem of interfering in the Qemu's signal mask. According to some >>>> previous discussions, perhaps patch all external libraries that mass up >>>> with this mask (spice, for example) is a way to solve it. But not sure >>>> if it worth the time spent. Would like to hear you guys. >> I think patching all the libraries is a losing battle, I think we need to >> pursue alternate debugging techniques. > > It is really only about patching libraries that create threads _and_ > block all signals in the newly-created thread (to not interfere with the > program's own handling of the signals). In this case, the per-thread > signals (SIGFPE/SIGSEGV/SIGBUS/SIGSYS/SIGILL) should be left unblocked, > but SIGSYS is often forgotten. But otherwise you have a fast way to test third party linked libraries, I would have to test it each one manually. How many libraries are linked to Qemu today? > > I don't think there are many libraries like this, but fixing SPICE at > least should definitely be welcome. > > In fact QEMU's own util/qemu-thread-posix.c does not unblock those > signals. Eduardo, can you submit a patch for that? I sure can. -- Eduardo Otubo IBM Linux Technology Center