Re: GDB bt command and core dumps

[Amol Lad <amol.lad@gmail.com>]

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.