GDB bt command and core dumps

GDB bt command and core dumps

[Amol Lad]

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)

Thanks

-- 
Amol
Sent from: Bangalore KA India.

Re: GDB bt command and core dumps

[Daniel Jacobowitz]

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

Re: GDB bt command and core dumps

[Amol Lad]

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 <drow@false.org> 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.

Re: GDB bt command and core dumps

[Amol Lad]

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 <amol.lad@gmail.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
>
> Thanks
>
> On Tue, Mar 24, 2009 at 8:12 PM, Daniel Jacobowitz <drow@false.org> 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.