From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32026 invoked by alias); 27 Aug 2008 16:04:51 -0000 Received: (qmail 32015 invoked by uid 22791); 27 Aug 2008 16:04:50 -0000 X-Spam-Check-By: sourceware.org Received: from aussmtpmrkpc120.us.dell.com (HELO aussmtpmrkpc120.us.dell.com) (143.166.82.159) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 27 Aug 2008 16:04:14 +0000 X-IronPort-AV: E=Sophos;i="4.32,279,1217826000"; d="scan'208";a="353957774" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 27 Aug 2008 11:04:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18613.31478.512294.761920@gargle.gargle.HOWL> Date: Fri, 29 Aug 2008 01:55:00 -0000 From: Paul Koning To: saffroy@gmail.com Cc: gdb@sourceware.org Subject: Re: how could gdb handle truncated core files? References: X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid 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: 2008-08/txt/msg00282.txt.bz2 >>>>> "Jean-Marc" == Jean-Marc Saffroy writes: Jean-Marc> Hi, For now, gdb does not seem to be able to do anything Jean-Marc> useful with a truncated core file on Linux (ie. what you Jean-Marc> get when your process dies and the core size limit is not Jean-Marc> 0 but less than the size of the process). Jean-Marc> In a number of cases, I think it would be nice to be able Jean-Marc> to at least get a stack trace, and examine local Jean-Marc> variables. This could require a limited amount of data to Jean-Marc> be dumped by the kernel. I've generally had good success (on a different OS) with partial corefiles. As you said, the issue isn't in GDB, the issue is that the partial corefile has to have the right subset of data in it. Jean-Marc> ...In search of a solution, I patched my Linux kernel so that Jean-Marc> dumping a core would start with the segments that hold a Jean-Marc> stack (assuming user stack pointers are valid): thus these Jean-Marc> segments have a chance of being dumped before the core Jean-Marc> limit is reached. Jean-Marc> This approach gives interesting results with a (very Jean-Marc> simple) single threaded process. However, my attempts with Jean-Marc> a multithreaded process failed, like this: Jean-Marc> $ gdb GNU gdb 6.8 This GDB was Jean-Marc> configured as "x86_64-unknown-linux-gnu"... Cannot access Jean-Marc> memory at address 0x2aaaaabc29c8 (gdb) bt #0 Jean-Marc> 0x00002aaaaabc9345 in ?? () #1 0x00000000400179f0 in ?? () Jean-Marc> #2 0x0000000000000000 in ?? () Jean-Marc> That is: - gdb does not load symbols from binaries - as a Jean-Marc> result, gdb does not detect threads (because IIRC Jean-Marc> libthread_db would be loaded when some libpthread.so Jean-Marc> symbols are detected in the process) - the backtrace seems Jean-Marc> incorrect: if I have a "full" core dump, gdb shows the Jean-Marc> following stack trace: I'm not particularly familiar with how shared library support works in Linux. The address that's giving you trouble is a shared library address, not an address in your main binary (or its data space). As a guess, the problem is that there's an additional bit of critical data that needs to be in your corefile: the tables that tell GDB what shared libraries are loaded by the process, and to what addresses. paul