This is the mail archive of the
mailing list for the GDB project.
Re: GDB bt command and core dumps
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.