From owner-freebsd-threads@FreeBSD.ORG Fri May 13 17:40:02 2005 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A240A16A4CE for ; Fri, 13 May 2005 17:40:02 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73F3543D66 for ; Fri, 13 May 2005 17:40:02 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4DHe2ql043888 for ; Fri, 13 May 2005 17:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4DHe2Q0043887; Fri, 13 May 2005 17:40:02 GMT (envelope-from gnats) Resent-Date: Fri, 13 May 2005 17:40:02 GMT Resent-Message-Id: <200505131740.j4DHe2Q0043887@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Pete French Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A721C16A4CE for ; Fri, 13 May 2005 17:39:20 +0000 (GMT) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DA5A43D76 for ; Fri, 13 May 2005 17:39:20 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWe83-0004ln-Fc for FreeBSD-gnats-submit@freebsd.org; Fri, 13 May 2005 18:39:15 +0100 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.50 (FreeBSD)) id 1DWe83-000K2U-Aq for FreeBSD-gnats-submit@freebsd.org; Fri, 13 May 2005 18:39:15 +0100 Message-Id: Date: Fri, 13 May 2005 18:39:15 +0100 From: Pete French To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: threads/80992: abort() sometimes not caught by gdb depending on thread library X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Pete French List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 17:40:02 -0000 >Number: 80992 >Category: threads >Synopsis: abort() sometimes not caught by gdb depending on thread library >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri May 13 17:40:02 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Pete French >Release: FreeBSD 5.4-RELEASE i386 >Organization: www.ticketswitch.com >Environment: System: FreeBSD dilbert.rattatosk 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Tue May 10 14:15:25 BST 2005 petefrench@dilbert.rattatosk:/usr/obj/usr/src/sys/P4-SMP-WORKSTATION i386 >Description: When an unknown method is called in /usr/lib/libobjc.a it calls abort() to halt the program with a SIGABRT. Running such a program under gdb should then allow you to trace the point of the call. If the program is linked with -lthr then this works. If it is linked with -lpthread then this does not work, and gdb says "The program no longer exists." This works on FreeBSD 4 and all other operating systems I have tried it on. It also works, as stated, with libthr on FreeBSD 5. The problem seems to be specific to libpthread This has only shown up when trying to debug threaded code, but the fact it is specific to a thread library and that the code behaves everywhere else makes me wonder if something more sinister is going on inside pthread. >How-To-Repeat: Simple test code: #include #include #include #include int main(int argc, char *argv[]) { id my_test = [Object new]; [my_test a_missing_method]; return 0; } Compile with "cc -g test.m -lobj -lpthread" and run under gdb. Compiling with "cc -g test.m -lobj -lthr" behaves as expected. >Fix: This is only an issue when debugging, and if I need to track down a bad method call I can always compile and run with libthr in order to find it. Annoying but not the end of the world. >Release-Note: >Audit-Trail: >Unformatted: