From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28156 invoked by alias); 4 Apr 2007 18:20:49 -0000 Received: (qmail 28148 invoked by uid 22791); 4 Apr 2007 18:20:48 -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; Wed, 04 Apr 2007 19:20:37 +0100 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 67C995F00A; Wed, 4 Apr 2007 11:20:36 -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 15441-08-11; Wed, 4 Apr 2007 11:20:35 -0700 (PDT) Received: from ussunex03.svl.access-company.com (ussunm001.palmsource.com [192.168.101.12]) by mx1.palmsource.com (Postfix) with ESMTP id 97ACB5EEF2; Wed, 4 Apr 2007 11:20:35 -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 ; Wed, 4 Apr 2007 18:21:56 +0000 Received: from svmsnyderlnx by owa.access-company.com; 04 Apr 2007 11:20:36 -0700 Subject: RE: GDB receives SIGKILL From: Michael Snyder To: Vadim Shmelev Cc: gdb@sourceware.org In-Reply-To: <200704041247.l34ClW9n030152@imap.acronis.ru> References: <200704041247.l34ClW9n030152@imap.acronis.ru> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 04 Apr 2007 18:20:00 -0000 Message-Id: <1175710836.11945.26.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/msg00028.txt.bz2 On Wed, 2007-04-04 at 16:50 +0400, Vadim Shmelev wrote: > Thanks for comments, Daniel and Michael. I will try to describe my > environment. > > For statically building of application I use gcc 4.1.1, glibc 2.3.2 and all > glibc components configured and built together. NPTL threads are not used. > Target platform is VMware ESX Server with 2.4.21 kernel, accordingly dynamic > linking doesn't match, as glibc's conflict is possible. How I can realize, > that problem doesn't have decision, but I should know possible reasons for > receiving SIG32 and SIG33 signals. Kernel 2.4.21? That kernel may possibly be too old. I don't know for sure. The reason for receiving the sig32 and sig33 is because the libpthreads library uses them for inter-thread communication and synchronization. If everything is working properly, GDB intercepts them and understands some information from them, giving gdb an insight into what the thread library is doing. You (the user) should never see them or be aware of them. There is some underlying problem that is preventing this system (kernel -- glibc -- libpthreads -- gdb) from working properly.