This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <> 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

Sent from: Bangalore KA India.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]