From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2519 invoked by alias); 3 Sep 2007 07:47:25 -0000 Received: (qmail 2511 invoked by uid 22791); 3 Sep 2007 07:47:24 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Sep 2007 07:47:20 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id l837lFaP015606; Mon, 3 Sep 2007 09:47:15 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id l837lEW6011975; Mon, 3 Sep 2007 09:47:15 +0200 (CEST) Date: Mon, 03 Sep 2007 07:47:00 -0000 Message-Id: <200709030747.l837lEW6011975@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: vandrove@vc.cvut.cz CC: vandrove@vc.cvut.cz, yinglcs@gmail.com, gdb@sourceware.org In-reply-to: <46DB7048.7050309@vc.cvut.cz> (message from Petr Vandrovec on Sun, 02 Sep 2007 19:24:08 -0700) Subject: Re: Program received signal SIG33, Real-time event 33. References: <568e62a40709012254j43aa5c15i9c7612350a77de55@mail.gmail.com> <46DA6B56.1060200@vc.cvut.cz> <20070902134404.GA5557@caradoc.them.org> <46DB7048.7050309@vc.cvut.cz> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00011.txt.bz2 > Date: Sun, 02 Sep 2007 19:24:08 -0700 > From: Petr Vandrovec > > Daniel Jacobowitz wrote: > > On Sun, Sep 02, 2007 at 12:50:46AM -0700, Petr Vandrovec wrote: > >> Apparently your program uses signals... If this is expected (which probably is > >> for realtime signals) then > >> > >> handle SIG33 nostop noprint pass > >> > >> will configure gdb so this signal is ignored by gdb, but delivered to program > >> like without gdb. > > > > No, SIG33 is generally internal to the threading implementation. > > > > GDB 6.3 is somewhat old. I recommend trying a current version. > > If Ying uses setuid() from multithreaded program then I think that glibc > has more than one surprise ready for him... Is that still broken on Linux?