From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18974 invoked by alias); 25 Jan 2007 19:40:51 -0000 Received: (qmail 18913 invoked by uid 22791); 25 Jan 2007 19:40:51 -0000 X-Spam-Check-By: sourceware.org Received: from nwkea-mail-5.sun.com (HELO nwkea-mail-5.sun.com) (192.18.42.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 Jan 2007 19:40:44 +0000 Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0PJegX2019068 for ; Thu, 25 Jan 2007 11:40:42 -0800 (PST) Received: from luai12.sfbay.sun.com (luai12.SFBay.Sun.COM [10.6.186.42]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0PJeghg006211; Thu, 25 Jan 2007 11:40:42 -0800 (PST) Received: from luai12.sfbay.sun.com (localhost.localdomain [127.0.0.1]) by luai12.sfbay.sun.com (8.12.11/8.12.11) with ESMTP id l0PJegcQ030390; Thu, 25 Jan 2007 11:40:42 -0800 Received: (from carlton@localhost) by luai12.sfbay.sun.com (8.12.11/8.12.11/Submit) id l0PJegC7030389; Thu, 25 Jan 2007 11:40:42 -0800 To: gdb Subject: multithreaded core files From: David Carlton Date: Thu, 25 Jan 2007 19:40:00 -0000 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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-01/txt/msg00320.txt.bz2 One of my coworkers is looking at a core file from a multithreaded program. (x86 Linux.) In this situation, GDB only prints a backtrace from the thread that actually seg faulted; he'd like to see what other threads were doing at the time. I assume there's no easy way to fix that, but he had the idea of looking through the memory to find out where the other threads' stacks are. Not completely impossible - we know some of the functions to expect in the other threads' backtraces, so we can come up with some addresses to look for. If we can find those other stacks, is there any way that we can try to convince GDB to print out backtraces for them? And even give us local variable information? Thanks, David Carlton david.carlton@sun.com