From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11078 invoked by alias); 17 Jul 2007 13:46:01 -0000 Received: (qmail 11065 invoked by uid 22791); 17 Jul 2007 13:46:00 -0000 X-Spam-Check-By: sourceware.org Received: from smtp28.poczta.onet.pl (HELO smtp28.poczta.onet.pl) (213.180.130.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 17 Jul 2007 13:45:53 +0000 Received: from smtp3k.poczta.onet.pl ([213.180.130.37]:44735 "EHLO smtp3k.poczta.onet.pl") by ps28.test.onet.pl with ESMTP id (ORCPT ); Tue, 17 Jul 2007 15:45:38 +0200 Received: from pmq2.test.onet.pl ([192.168.246.2]:36488 "EHLO pmq2") by kps3.test.onet.pl with ESMTP id convert rfc822-to-8bit (ORCPT ); Tue, 17 Jul 2007 15:45:30 +0200 Received: from 136.182.158.153 by 192.168.240.59 with HTTP; Tue, 17 Jul 2007 15:45:30 +0200 ,from 175.28.12.111 by 136.182.158.153 with HTTP Date: Wed, 18 Jul 2007 03:41:00 -0000 From: Maciej Sikorski To: gdb@sourceware.org Subject: Re: Remote mutli-threaded debugging with large number of threads X-Mailer: onet.poczta Message-Id: In-Reply-To: Q15945449-c82b26ed540b386fce30ee9b3c2cf9ac@pmq3.test.onet.pl MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8BIT 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-07/txt/msg00136.txt.bz2 Comparison of correct situation logs from connection to one with incorrect behaviour (the same application that starts working after different one opens connection first) shows something like this: Correct case: Packet received: 000000b0308281803082ff8000000004308282500000000000000008000000000002d0000000000030828b780000000048044422105724bc39c0629839c0627839c062580ff05c5c300287580ffef8c00fe968040f94c2380ff05c900ff05c7c0ff05c780ff05c740ff05c680ff05c6400000002308282500ff0c71c30828250000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0fa5180002d000580444420f0fa62c000000000000000000000000 Sending packet: $mf0fa518,4#c8...Ack Packet received: 7c000026 Incorrect case: Packet received: 000000b0308281803082ff8000000004308282500000000000000008000000000002d0000000000030828b780000000048044422105724bc39c0629839c0627839c062580ff05c5c300287580ffef8c00fe968040f94c2380ff05c900ff05c7c0ff05c780ff05c740ff05c680ff05c6400000002308282500ff0c71c30828250000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0fa5180002d000580444420f0fa62c000000000000000000000000 Sending packet: $m0,4#fd...Ack Packet received: E01 E01 The stub-side thread library does not have the required thread local storage support. I assume hex after $m is address that gdb is asking about How is this possible that in bad case address is 0? Logs before these sequences do not show any differences. It looks like that GDB in both cases received f0fa518, but in second case it sends $m0 instead of $mf0fa518. It also looks strange to me that after "opening pipe" (first attach to different application that always works) problem is gone. Can you help with further diagnosis and potential root cause finding? Maciej Sikorski m.sikorski0@poczta.onet.pl napisa³: >Yes, I agree it has nothing to do with application size - just confirmed that I can see correctly threads of 17 meg binary. >Interesting thing is that after running debug session on first working application (one that problem never appeared), then detaching and attaching to second one everything works perfectly. > >Gdbserver is restarted and attached to a second app. It seems that it is a matter of configuration GDB keeps from previous connection. >This is a kind of workaround for me, but still dont know root cause. Any suggestions what I can look for in remote debug logs? > >Maciej Sikorski >