From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28415 invoked by alias); 6 Apr 2007 09:40:13 -0000 Received: (qmail 28406 invoked by uid 22791); 6 Apr 2007 09:40:13 -0000 X-Spam-Check-By: sourceware.org Received: from topsns2.toshiba-tops.co.jp (HELO topsns2.toshiba-tops.co.jp) (202.230.225.126) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Apr 2007 10:38:49 +0100 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for sourceware.org [209.132.176.174]) with ESMTP; Fri, 6 Apr 2007 18:38:48 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id E1E7A416FE; Fri, 6 Apr 2007 18:38:45 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id CDE6820910; Fri, 6 Apr 2007 18:38:45 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l369ciW0030099; Fri, 6 Apr 2007 18:38:45 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 06 Apr 2007 09:40:00 -0000 Message-Id: <20070406.183844.05598302.nemoto@toshiba-tops.co.jp> To: drow@false.org Cc: gdb@sourceware.org Subject: Re: generic error with a statically linked multithreaded program From: Atsushi Nemoto In-Reply-To: <20070405144533.GA31862@caradoc.them.org> References: <20070405142913.GA30928@caradoc.them.org> <20070405.233933.122593816.anemo@mba.ocn.ne.jp> <20070405144533.GA31862@caradoc.them.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00036.txt.bz2 On Thu, 5 Apr 2007 10:45:33 -0400, Daniel Jacobowitz wrote: > > Thank you. > > Is it http://sources.redhat.com/bugzilla/show_bug.cgi?id=2696, right? > > > > If so, the gdb patch mentioned in it is already merged in gdb 6.6? > > I think so, but I don't remember for sure. I tried the libc patch on MIPS and it works fine with gdbserver. But with MIPS native gdb, I got a little bit different error message: thread_get_info_callback: cannot get thread info: generic error Do you have any thoughts on this error? # ./gdb ./hello GNU gdb 6.6.50.20070405 Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "mips-linux"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set debug lin-lwp 1 (gdb) run Starting program: /hello LLW: waitpid 741 received Trace/breakpoint trap (stopped) LLW: Candidate event Trace/breakpoint trap (stopped) in process 741. LLTA: PTRACE_PEEKUSER process 741, 0, 0 (OK) LLW: trap_ptid is process 741. LLR: Preparing to resume process 741, 0, inferior_ptid process 741 LLR: PTRACE_CONT process 741, 0 (resume event thread) LLW: waitpid 741 received Trace/breakpoint trap (stopped) LLW: Candidate event Trace/breakpoint trap (stopped) in process 741. LLTA: PTRACE_PEEKUSER process 741, 0, 0 (OK) LLW: trap_ptid is process 741. [Thread debugging using libthread_db enabled] LLR: Preparing to resume process 741, 0, inferior_ptid process 741 LLR: PTRACE_CONT process 741, 0 (resume event thread) LLW: waitpid 741 received Trace/breakpoint trap (stopped) LLW: Candidate event Trace/breakpoint trap (stopped) in process 741. LLTA: PTRACE_PEEKUSER process 741, 0, 0 (OK) LLW: trap_ptid is process 741. thread_get_info_callback: cannot get thread info: generic error (gdb) quit The program is running. Exit anyway? (y or n) y KC: PTRACE_KILL process 741, 0, 0 (OK) KWC: wait process 741 received unk. # And gdb did not hang in this case. No problem with dynamically-linked program. --- Atsushi Nemoto