No useful backtrace in core dump.

No useful backtrace in core dump.

[代尔欣]

Hi list,
        I'm new with gdb. Really need your help. I run gdb with my
program on ARM platform. I compiled the codes with -g option. After
the codes crash, in core dump file, I only see something like:

Raise()
Abort()
?? ()

Why no the last function called in my program? How to make this work,
Please help.

Thanks!

Re: No useful backtrace in core dump.

[Baurzhan Ismagulov]

On Thu, Apr 22, 2010 at 10:40:57AM +0800, 代尔欣 wrote:
> After
> the codes crash, in core dump file, I only see something like:
> 
> Raise()
> Abort()
> ?? ()

http://sources.redhat.com/ml/gdb/2008-08/msg00101.html

We ended up not using abort() where it was possible.

With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/

Re: No useful backtrace in core dump.

[代尔欣]

Baurzhan Ismagulov,
         Many thanks your reply. I read the related thread. It seems
an abort() function problem. My program do not call abort() function.
I suppose some other place call abort() function(maybe in libc...). Or
abort signal also can lead this? Any other solution to fix this
instead change the abort() function call(because the abort() call may
place in other module and I can't or difficult modify).

Thank!

2010/4/22 Baurzhan Ismagulov <ibr@radix50.net>:
> On Thu, Apr 22, 2010 at 10:40:57AM +0800, 代尔欣 wrote:
>> After
>> the codes crash, in core dump file, I only see something like:
>>
>> Raise()
>> Abort()
>> ?? ()
>
> http://sources.redhat.com/ml/gdb/2008-08/msg00101.html
>
> We ended up not using abort() where it was possible.
>
> With kind regards,
> --
> Baurzhan Ismagulov
> http://www.kz-easy.com/
>

Re: No useful backtrace in core dump.

[Mark Kettenis]

> Date: Thu, 22 Apr 2010 10:40:57 +0800
> From: =?GB2312?B?tPq2+9DA?= <daierxin@gmail.com>
> 
> Hi list,
>         I'm new with gdb. Really need your help. I run gdb with my
> program on ARM platform. I compiled the codes with -g option. After
> the codes crash, in core dump file, I only see something like:
> 
> Raise()
> Abort()
> ?? ()
> 
> Why no the last function called in my program? How to make this work,
> Please help.

Because GCC generates overoptimized code that destroys the call stack.
Please complain about this on the gcc mailing lists.

Re: No useful backtrace in core dump.

[代尔欣]

Hi Mark,
      How about I use lower optimize option with GCC? If this still
can't work, I will follow your suggestion...
Thanks!

2010/4/22 Mark Kettenis <mark.kettenis@xs4all.nl>:
>> Date: Thu, 22 Apr 2010 10:40:57 +0800
>> From: =?GB2312?B?tPq2+9DA?= <daierxin@gmail.com>
>>
>> Hi list,
>>         I'm new with gdb. Really need your help. I run gdb with my
>> program on ARM platform. I compiled the codes with -g option. After
>> the codes crash, in core dump file, I only see something like:
>>
>> Raise()
>> Abort()
>> ?? ()
>>
>> Why no the last function called in my program? How to make this work,
>> Please help.
>
> Because GCC generates overoptimized code that destroys the call stack.
> Please complain about this on the gcc mailing lists.
>

Re: No useful backtrace in core dump.

[Baurzhan Ismagulov]

On Thu, Apr 22, 2010 at 04:35:41PM +0800, 代尔欣 wrote:
>       How about I use lower optimize option with GCC? If this still
> can't work, I will follow your suggestion...

IIUC, the thread implies that rebuilding glibc without
__attribute__((noreturn)) for abort() should solve the problem, but I
haven't tried that.

With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/

Re: No useful backtrace in core dump.

[代尔欣]

http://sources.redhat.com/ml/gdb/2008-08/msg00123.html
From above thread:
Indeed, changing abort() to invalid memory reference makes backtrace work.
foo (int a, int b)
{
int c=40;
abort(); <--- IIUC, change to invalid memory reference
return a+b;
}

I don't know whether can remove the __attribute__((noreturn)) or not
when compiling glibc. It seems the problem a little complicated....

2010/4/22 Baurzhan Ismagulov <ibr@radix50.net>:
> On Thu, Apr 22, 2010 at 04:35:41PM +0800, 代尔欣 wrote:
>>       How about I use lower optimize option with GCC? If this still
>> can't work, I will follow your suggestion...
>
> IIUC, the thread implies that rebuilding glibc without
> __attribute__((noreturn)) for abort() should solve the problem, but I
> haven't tried that.
>
> With kind regards,
> --
> Baurzhan Ismagulov
> http://www.kz-easy.com/
>

Re: No useful backtrace in core dump.

[Baurzhan Ismagulov]

On Thu, Apr 22, 2010 at 05:02:10PM +0800, 代尔欣 wrote:
> http://sources.redhat.com/ml/gdb/2008-08/msg00123.html
> From above thread:
> Indeed, changing abort() to invalid memory reference makes backtrace work.
> foo (int a, int b)
> {
> int c=40;
> abort(); <--- IIUC, change to invalid memory reference
> return a+b;
> }

This is basically refraining from using abort(), which you said could be
difficult for you to modify, especially since you don't know yet who
calls it.

As the first step, I'd run the app under gdb / gdbserver to find out the
caller.

With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/

Re: No useful backtrace in core dump.

[代尔欣]

Baurzhan Ismagulov,
    Thanks your valuable reply. I will try find who call abort(). Hope
I do not go wrong direction.
Thanks!

2010/4/22 Baurzhan Ismagulov <ibr@radix50.net>:
> On Thu, Apr 22, 2010 at 05:02:10PM +0800, 代尔欣 wrote:
>> http://sources.redhat.com/ml/gdb/2008-08/msg00123.html
>> From above thread:
>> Indeed, changing abort() to invalid memory reference makes backtrace work.
>> foo (int a, int b)
>> {
>> int c=40;
>> abort(); <--- IIUC, change to invalid memory reference
>> return a+b;
>> }
>
> This is basically refraining from using abort(), which you said could be
> difficult for you to modify, especially since you don't know yet who
> calls it.
>
> As the first step, I'd run the app under gdb / gdbserver to find out the
> caller.
>
> With kind regards,
> --
> Baurzhan Ismagulov
> http://www.kz-easy.com/
>

Re: No useful backtrace in core dump.

[Baurzhan Ismagulov]

On Thu, Apr 22, 2010 at 05:36:46PM +0800, 代尔欣 wrote:
> Hope I do not go wrong direction.

This depends on your goal, whether you want to debug this particular
case, or you want to solve the backtrace problem in general.

If you can reproduce the problem, then running the app under gdb is the
easiest way. Otherwise, you could analyze the stack in the core file
manually and see callers past abort().

With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/