From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16308 invoked by alias); 27 Aug 2008 22:46:57 -0000 Received: (qmail 16299 invoked by uid 22791); 27 Aug 2008 22:46:56 -0000 X-Spam-Check-By: sourceware.org Received: from pas38-1-82-67-71-117.fbx.proxad.net (HELO siegfried.gbfo.org) (82.67.71.117) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 27 Aug 2008 22:46:09 +0000 Received: from erda.mds (localhost [127.0.0.1]) by siegfried.gbfo.org (8.13.6/8.13.6) with ESMTP id m7RMk3KG012709; Thu, 28 Aug 2008 00:46:03 +0200 Received: from localhost (saffroy@localhost) by erda.mds (8.13.6/8.13.6/Submit) with ESMTP id m7RMk3UP012706; Thu, 28 Aug 2008 00:46:03 +0200 Date: Fri, 29 Aug 2008 17:46:00 -0000 From: Jean-Marc Saffroy To: Paul Pluzhnikov cc: gdb@sourceware.org Subject: Re: how could gdb handle truncated core files? In-Reply-To: <8ac60eac0808270946l284eb94awf97be09b8b3a4aa@mail.gmail.com> Message-ID: References: <8ac60eac0808270946l284eb94awf97be09b8b3a4aa@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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/msg00285.txt.bz2 On Wed, 27 Aug 2008, Paul Pluzhnikov wrote: > You may also want to look at Google user-space coredumper: > http://code.google.com/p/google-coredumper/ Cool, this project seems to do what I need, with a limited memory footprint! :) > It is often easier to play with than to boot custom kernels, I'm not fond of custom kernels either. Should a clean kernel patch have sufficed, I would have pushed for its inclusion in the mainline. > and it already has support for prioritisation of what is dumped, > as well as compression of the core (core files are often *extremely* > compressible). This prioritisation seems to be a simple and efficient way of reducing the core size to something usable in the use cases I mentioned. >> - gdb does not load symbols from binaries > > The problem here most likely is that _r_debug.r_map was not found > in the (truncated) core. Without it, GDB can't know which libraries > were loaded, hence can't load unwind info for libpthread, hence > can't produce correct stack trace. Indeed, that's certainly the problem! Thanks for pointing out. It seems that coredumper's prioritisation works well enough that it does not need to care about this level of detail directly. Maybe the kernel could use the same approach, or a separate program could trim full core dumps on the fly (see "Piping core dumps" in http://lwn.net/Articles/280959/ ), so that linking all applications with libcoredumper could be avoided. But I'm going off-topic for this list. ;) Cheers, Jean-Marc -- saffroy@gmail.com