From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23583 invoked by alias); 25 Mar 2009 10:48:45 -0000 Received: (qmail 23573 invoked by uid 22791); 25 Mar 2009 10:48:45 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from wf-out-1314.google.com (HELO wf-out-1314.google.com) (209.85.200.171) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Mar 2009 10:48:38 +0000 Received: by wf-out-1314.google.com with SMTP id 23so3632624wfg.24 for ; Wed, 25 Mar 2009 03:48:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <8c675e9b0903250012l20e0124ah412b794dd2225379@mail.gmail.com> References: <8c675e9b0903240728i7e044580yae1deff480b3ffc9@mail.gmail.com> <20090324144219.GA28663@caradoc.them.org> <8c675e9b0903250012l20e0124ah412b794dd2225379@mail.gmail.com> Date: Wed, 25 Mar 2009 10:48:00 -0000 Received: by 10.142.154.14 with SMTP id b14mr3858938wfe.322.1237978116299; Wed, 25 Mar 2009 03:48:36 -0700 (PDT) Message-ID: <8c675e9b0903250348n312dcf55qa6130d80f35f6356@mail.gmail.com> Subject: Re: GDB bt command and core dumps From: Amol Lad To: Amol Lad , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2009-03/txt/msg00153.txt.bz2 Hi Daniel, Any clue how many bytes of heap should be dump for gdb "bt" to work ? Amol On Wed, Mar 25, 2009 at 12:42 PM, Amol Lad wrote: > It seems heap is also required. > > 0079c000-00d67000 rwxp 00763000 00:00 0 [heap] > > Executing gdb "bt" gives below error > > Cannot access memory at address 0xc975d0 > > "bt" is happy if above address range is also dumped. Any way to avoid > dumping heap and this can grow subtantially > > Thanks > > On Tue, Mar 24, 2009 at 8:12 PM, Daniel Jacobowitz wrote: >> On Tue, Mar 24, 2009 at 07:58:18PM +0530, Amol Lad wrote: >>> Hi, >>> >>> I'm working on an ARM9 platform (running Linux 2.6.18) and using gdb >>> 6.6 compiled for the platform. My application is a multithreaded >>> application and on a crash it generates core of around 200MByte. I'm >>> looking to reduce the size of the core file and I _only_ need gdb 'bt' >>> command output ; no other debugging information (i.e I'm only >>> interested in the call trace) >>> >>> - I tried ulimit -c command but the core produced are not useful in most cases >>> - I changed kernels fs/binfmt_elf.c file and modified maydump function >>> to just add crashed thread's stack in the core but no success >>> >>> What all information should be present in the core file so that bt >>> output works reliably. Is stack of crashed thread not enough ? My >>> application is compiled with -O2 (hence -fomit-frame-pointer) >> >> You'll probably need the dynamic section, too - that's what GDB uses >> to locate shared libraries. I thought there was already a way to do >> this, but I can't find it. Stack and modified private copies of file >> pages should approximate this, i.e. the data segment but not the heap. >> >> -- >> Daniel Jacobowitz >> CodeSourcery >> > > > > -- > Amol > Sent from: Bangalore KA India. > -- Amol Sent from: Bangalore KA India.