From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6121 invoked by alias); 5 Aug 2003 17:21:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6113 invoked from network); 5 Aug 2003 17:21:36 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 5 Aug 2003 17:21:36 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.9/8.12.9) with ESMTP id h75HLYPJ014954; Tue, 5 Aug 2003 12:21:34 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h75HLYHK026688; Tue, 5 Aug 2003 12:21:34 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h75HLXbq026687; Tue, 5 Aug 2003 13:21:33 -0400 Date: Tue, 05 Aug 2003 17:21:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200308051721.h75HLXbq026687@duracef.shout.net> To: carlton@kealia.com, gdb@sources.redhat.com Subject: Re: attach.exp failure X-SW-Source: 2003-08/txt/msg00063.txt.bz2 Well now that's interesting. attach 1065 Attaching to program: /gdb/mirror/src/gdb/testsuite/gdb.base/attach2, process 1065 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 0x420b0205 in nanosleep () from /lib/i686/libc.so.6 (gdb) PASS: gdb.base/attach.exp: attach call i r r3 ERROR: Couldn't send p should_exit = 1 to GDB. UNRESOLVED: gdb.base/attach.exp: p should_exit = 1 ERROR: Couldn't send c to GDB. UNRESOLVED: gdb.base/attach.exp: c Looks like gdb crashed or went into a loop. Probably crashed because if it went into a loop, the test would take some long $TIMEOUT time to run. Are there any funky core files lying around? The target program is inside nanosleep, probably called from sleep, and I know that gdb screws up the frame info when it backtraces through sleep. But I have never gotten this behavior. The connection between 'nanosleep' and a crash is just too tenuous. Your problem has the word 'nanosleep' in it but I just don't see a smoking gun linking it to the 'sleep' frame info problem. :( What vendor/version of linux are you running on? Can you disassemble 'sleep' from libc.so and post the first few instructions? Want to try this patch? http://sources.redhat.com/ml/gdb-patches/2003-08/msg00053.html