From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5459 invoked by alias); 17 Feb 2005 01:42:15 -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 4487 invoked from network); 17 Feb 2005 01:42:02 -0000 Received: from unknown (HELO topsns.toshiba-tops.co.jp) (202.230.225.5) by sourceware.org with SMTP; 17 Feb 2005 01:42:02 -0000 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for sourceware.org [12.107.209.250]) with SMTP; 17 Feb 2005 01:42:02 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id B90781EAE1; Thu, 17 Feb 2005 10:42:00 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id ABF111D6DE; Thu, 17 Feb 2005 10:42:00 +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 j1H1g09c029148; Thu, 17 Feb 2005 10:42:00 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 17 Feb 2005 09:01:00 -0000 Message-Id: <20050217.104200.93020045.nemoto@toshiba-tops.co.jp> To: drow@false.org Cc: gdb@sources.redhat.com Subject: Re: huge remote debug traffic with multi-thread program From: Atsushi Nemoto In-Reply-To: <20050216165909.GA11396@nevyn.them.org> References: <20050216.210432.15259170.nemoto@toshiba-tops.co.jp> <20050216165909.GA11396@nevyn.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 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00112.txt.bz2 >>>>> On Wed, 16 Feb 2005 11:59:09 -0500, Daniel Jacobowitz said: drow> The normal cause of this sort of problem is GDB's lame software drow> single-step support. You have two threads iterating in the same drow> piece of code, and probably GDB is continually getting a trap drow> from the wrong one. Or it may get confused about where it has drow> put the breakpoint. Thanks for your suggestion. It looks latter. drow> Does the problem go away if each thread is in a separate drow> identical copy of the function? No, this problem still remains if each thread have its own function. Looking the log, gdbserver keep getting SIGTRAP on 0x00404a78 (__pthread_wait_for_restart_signal+132). This is a return address from __pthread_sigsuspend() which is a stopping place of SIGINT (Ctrl-C). I'm wondering why gdb set breakpoint to the return address of __pthread_sigsuspend() ... --- excerpt from hostlog-join.txt --- remote_interrupt called remote_stop called Packet received: T0225:00404e18;1d:7fff7a08;thread:4000; Program received signal SIGINT, Interrupt. ... Sending packet: $g#67...Ack Packet received: 0000000010005e18000000047fffffff7fff7a20000000100000000100000001000000018678e008ffffffff00200200001001000000ffff87ff5e74ffffffff1000006010008dc07f7ffbe000004002000000007fff7e04ffffffff000000000000000100404e0000000000000000001000d1507fff7a087fff7b9000404a78000000000000070800001c20004093d01000002000404e18ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000002d30000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 # pc=0x00404e18, ra=0x00404a78 ... 0x00404e18 in __pthread_sigsuspend (set=0x7fff7a20) at ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c:54 54 ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c: No such file or directory. in ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c Current language: auto; currently c (gdb) c Continuing. ... Sending packet: $m404a78,4#35...Ack Packet received: 8fbc0010 Sending packet: $M404a78,4:0005000d#08...Ack # set breakpoint on 0x00404a78 --- Atsushi Nemoto