From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22673 invoked by alias); 7 Sep 2005 16:27:53 -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 22204 invoked by uid 22791); 7 Sep 2005 16:27:42 -0000 Received: from webmail.streamline-computing.com (HELO webmail.streamline-computing.com) (82.133.39.164) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 07 Sep 2005 16:27:42 +0000 Received: from [82.133.39.162] (helo=delmo.priv.wark.uk.streamline-computing.com) by webmail.streamline-computing.com with esmtp (Exim 4.52) id 1ED2g6-0000Af-3t for gdb@sources.redhat.com; Wed, 07 Sep 2005 17:21:38 +0100 Subject: Itanium and GDB on 2.6.x kernels with pthreads From: David Lecomber To: gdb Content-Type: multipart/mixed; boundary="=-56xBckT1nmxaI5Bh5/2U" Date: Wed, 07 Sep 2005 16:27:00 -0000 Message-Id: <1126110236.8094.85.camel@delmo.priv.wark.uk.streamline-computing.com> Mime-Version: 1.0 X-SW-Source: 2005-09/txt/msg00058.txt.bz2 --=-56xBckT1nmxaI5Bh5/2U Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1341 Dear all, Attached is a simple program, and simple script for GDB (current CVS, and previous versions) gcc -o pf -g pf.c -lm -lpthread gdb ./pf < gdb.script The script is a break main and then 'next' four times, followed by quit. On a 2.4.21 Itanium system, it's quick and quits happily. On a 2.6.5 Itanium, it hangs during the later nexts. Does anyone have a more recent Itanium they could try and see if this is a transient kernel issue? Note, the Intel IDB debugger does not have a problem with this test case. GDB consumes CPU, and a 'strace' shows it to be doing repeatedly: wait4(29113, 0x60000fffffffa730, 0, NULL) = -1 ECHILD (No child processes) wait4(29113, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], __WCLONE, NULL) = 29113 ptrace(PTRACE_CONT, 29113, 0, SIG_0) = 0 wait4(29113, 0x60000fffffffa730, 0, NULL) = -1 ECHILD (No child processes) Also, just generally, signal processing is goofed up -- and if I try to attach to the running GDB I just see: Loaded symbols for /lib/tls/libthread_db.so.1 (gdb) bt #0 Cannot access memory at address 0x28 (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Anyone seen this before? If someone could verify this is ok on their system, I'd appreciate it.. d. -- David Lecomber --=-56xBckT1nmxaI5Bh5/2U Content-Disposition: attachment; filename=pf.c Content-Type: text/x-csrc; name=pf.c; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Content-length: 465 #include #include #include void f(char* s) { int i; printf("Hello from : %s\n", s); fflush(stdout); for (i = 0 ; i < 100000000; i++) { float f = sqrt(i); } printf("Goodbye from : %s\n", s); fflush(stdout); } int main() { pthread_t t1; pthread_t t2; pthread_create(&t1, NULL, (void*) &f, "One"); pthread_create(&t2, NULL, (void*) &f, "Two"); pthread_join(t1, NULL); pthread_join(t2, NULL); } --=-56xBckT1nmxaI5Bh5/2U Content-Disposition: attachment; filename=gdb.script Content-Type: text/plain; name=gdb.script; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Content-length: 32 b main run next next next quit --=-56xBckT1nmxaI5Bh5/2U--