From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1101 invoked by alias); 2 Apr 2007 17:54:39 -0000 Received: (qmail 1086 invoked by uid 22791); 2 Apr 2007 17:54:36 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.palmsource.com (HELO mx1.palmsource.com) (12.7.175.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 02 Apr 2007 18:54:30 +0100 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 65CA65EFC6; Mon, 2 Apr 2007 10:54:29 -0700 (PDT) Received: from mx1.palmsource.com ([127.0.0.1]) by localhost (mx1.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28492-01; Mon, 2 Apr 2007 10:54:28 -0700 (PDT) Received: from ussunex03.svl.access-company.com (ussunm001.palmsource.com [192.168.101.12]) by mx1.palmsource.com (Postfix) with ESMTP id ACD825EF3E; Mon, 2 Apr 2007 10:54:07 -0700 (PDT) Received: from 192.168.92.56 ([192.168.92.56]) by ussunex03.svl.access-company.com ([192.168.101.12]) via Exchange Front-End Server owa.access-company.com ([10.0.20.19]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Apr 2007 17:55:26 +0000 Received: from svmsnyderlnx by owa.access-company.com; 02 Apr 2007 10:54:08 -0700 Subject: RE: GDB receives SIGKILL From: Michael Snyder To: Vadim Shmelev Cc: 'Baurzhan Ismagulov' , gdb@sourceware.org In-Reply-To: <200704021344.l32DiWiT016756@imap.acronis.ru> References: <200704021344.l32DiWiT016756@imap.acronis.ru> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 02 Apr 2007 17:54:00 -0000 Message-Id: <1175536448.9195.10.camel@svmsnyderlnx.palmsource.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 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-04/txt/msg00013.txt.bz2 On Mon, 2007-04-02 at 17:47 +0400, Vadim Shmelev wrote: > Thanks for response, Baurzhan. I will try to describe the problem in > > (gdb) handle SIG32 nostop noprint > Signal Stop Print Pass to program Description > SIG32 No No Yes Real-time event 32 > (gdb) handle SIG33 nostop noprint > Signal Stop Print Pass to program Description > SIG33 No No Yes Real-time event 33 Why did you do the above? Those signals are part of linuxthreads handling and debugging. There should be no need to silence them -- if there is, it could be a sign of something wrong. > > (gdb) b > 'ComputerManagement::CreateLocalLinuxHardwareInfo(Fomatik::Computer*)' > Breakpoint 1 at 0x9053fe6: file ../../../include/processor/ref/allocator.h, > line 23. > (gdb) r > Starting program: /mnt/afc_agent.exe > warning: shared library handler failed to enable breakpoint This is odd, but may have to do with libthread_db being linked static. I forget -- do we have linuxthreads debugging working with static link? [question for the other maintainers] > Reading symbols from shared object read from target memory...done. > Loaded system supplied DSO at 0xffffe000 What's this? System supplied DSO? > Detaching after fork from child process 2322. > Detaching after fork from child process 2325. Ah... fork? You know it is dangerous to mix threads and forks, don't you? If your process has spawned threads before it forks, you're almost guaranteed to be in bad trouble. I didn't see any msgs from gdb saying a thread had been spawned, but the thread detection might be broken eg. by the fact that we are linked statically. Can you try dynamic linking, at least of the libthread_db library? > > Program terminated with signal SIGKILL, Killed. > The program no longer exists. > Current language: auto; currently c++ > > The next output string looks strange ' warning: shared library handler > failed to enable breakpoint' as application is linked statically. Any > advises?