From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11048 invoked by alias); 4 Oct 2007 18:13:26 -0000 Received: (qmail 11035 invoked by uid 22791); 4 Oct 2007 18:13:26 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 Oct 2007 18:13:14 +0000 Received: (qmail 30953 invoked from network); 4 Oct 2007 18:13:13 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 Oct 2007 18:13:13 -0000 To: "haoran woo" Cc: gdb@sourceware.org Subject: Re: investigate a multi-threaded core References: <55e9e6630710040908s66d43337had870f44b3111d83@mail.gmail.com> From: Jim Blandy Date: Thu, 04 Oct 2007 18:13:00 -0000 In-Reply-To: <55e9e6630710040908s66d43337had870f44b3111d83@mail.gmail.com> (haoran woo's message of "Thu, 4 Oct 2007 12:08:51 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/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-10/txt/msg00038.txt.bz2 "haoran woo" writes: > I am investigating a multi-threaded core, from info threads, I can see > two threads (thread 1 and thread 6) were doing something when the > process cored, while other thread > is sleeping or waiting for a signal. I have two questions: > > 1. how to know which thread caused the crash? > when bring up the core by "gdb prog core", and do bt, the stack trace > is for thread 1, but from looking at the code, can not find any clue; > however, thread 6 is a little bit more suspcious. > but since gdb by default brings up thread 1, I am not sure whether I > should focus on thread 6 or thread 1. If I'm reading correctly, GDB just selects the first thread it finds listed in the core file. I don't know of anything that indicates which thread took the signal, or the status of each thread. If something looks suspicious in thread 6, I'd say that's where to concentrate. > 2. this is a stripped library, how to find the args passed to the > function call? I am using info frame, but the address give me > anything, since this is a C++ object, and I expect to see the first > arguments should have some vtable (the class has virtual functions). Those are interesting stack pointer values. Is this i386 Linux? The strategy for finding arguments without symbols depends on knowing your ABI's function calling conventions well. I'd try to look for some value I recognized, like the saved PC, and then figure out how the stack is laid out from there. I don't think we can really help you with your debugging. This mailing list is for discussing GDB itself. If you have any questions about GDB itself, we'll do our best to answer them.