This is the mail archive of the
mailing list for the GDB project.
Re: GDB bt command and core dumps
Any clue how many bytes of heap should be dump for gdb "bt" to work ?
On Wed, Mar 25, 2009 at 12:42 PM, Amol Lad <email@example.com> 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
> On Tue, Mar 24, 2009 at 8:12 PM, Daniel Jacobowitz <firstname.lastname@example.org> wrote:
>> On Tue, Mar 24, 2009 at 07:58:18PM +0530, Amol Lad wrote:
>>> 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
> Sent from: Bangalore KA India.
Sent from: Bangalore KA India.