Fwd: Help: please help to use gdb and its related terms

Fwd: Help: please help to use gdb and its related terms

[Kunal Chauhan]

---------- Forwarded message ----------
From: "Kunal Chauhan" <atkunalchauhan@gmail.com>
Date: 5 May 2020 6:55 p.m.
Subject: Help: please help to use gdb and its related terms
To: <gnu@gnu.org>
Cc:

Hi Team,

Here is some output of gdb I am not understanding .

#0  0xb66e8ee4 in strlen () from /lib/libc.so.6

[Current thread is 1 (LWP 2084)]

(gdb) bt full

#0  0xb66e8ee4 in strlen () from /lib/libc.so.6

No symbol table info available.

#1  0xb6da3854 in ?? () from /opt/qcom/lib/libcurl.so.4

No symbol table info available.

#2  0x05b40000 in ?? ()

No symbol table info available.

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

-- 
*Thanks with Regards!*

*Kunal Chauhan*
*Mob:08860397903*

*E-mail:atkunalchauhan@gmail.com <E-mail%3Aatkunalchauhan@gmail.com>*

Re: Fwd: Help: please help to use gdb and its related terms

[Andrew Burgess]

* Kunal Chauhan via Gdb <gdb@sourceware.org> [2020-05-05 21:39:32 +0530]:

> ---------- Forwarded message ----------
> From: "Kunal Chauhan" <atkunalchauhan@gmail.com>
> Date: 5 May 2020 6:55 p.m.
> Subject: Help: please help to use gdb and its related terms
> To: <gnu@gnu.org>
> Cc:
> 
> Hi Team,
> 
> Here is some output of gdb I am not understanding .
> 
> #0  0xb66e8ee4 in strlen () from /lib/libc.so.6
> 
> [Current thread is 1 (LWP 2084)]
> 
> (gdb) bt full
> 
> #0  0xb66e8ee4 in strlen () from /lib/libc.so.6
> 
> No symbol table info available.

You're currently in strlen in libc.so.6 (at address 0xb66e8ee4), but
you don't have debug information available, so GDB will have unwound
the stack using analysis of the function prologue (instead of using
unwind information from the debug info).

> 
> #1  0xb6da3854 in ?? () from /opt/qcom/lib/libcurl.so.4
> 
> No symbol table info available.

The previous frame was somewhere is libcurl.so.4 (at address
0xb6da3854) , though GDB couldn't find a nearby text symbol (that's
what the '??' tells us).  There's no debug information available for
this library either.  The '??' could be the result of some really
aggressive symbol removal from libcurl, or might indicate that the
previous unwind went wrong and you're not really at 0xb6da3854.

Again, the stack is going to be unwound using prologue analysis as
there's no debug information available.

> 
> #2  0x05b40000 in ?? ()
> 
> No symbol table info available.

This is starting to look very wrong now (I'm always suspicious of
addresses ending with 0000), GDB couldn't identify a function or even
a file that claims this address.

Again (obviously maybe) no debug information, prologue analysis unwind.

> 
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>

After unwinding GDB got back the same stack pointer and program
counter for the previous frame.  This most likely means the prologue
analysis unwinder is trying to unwind an incorrect location, and is
just getting back the same junk each time.

GDB prints the above message and stops to avoid going into an endless
loop.

You should consider installing debug information if possible for libc
and libcurl, this might aid the unwinder.

It's possible that the prologue analysis unwinder went wrong for your
target, you should try manually unwinding the stack (by checking the
ABI for your target, and examining the machine state) and see if you
agree with GDB.

Hope this helps,

Thanks,
Andrew

Re: Fwd: Help: please help to use gdb and its related terms

[Kunal Chauhan]

On 8 May 2020 10:24 p.m., "Kunal Chauhan" <atkunalchauhan@gmail.com> wrote:

1.Manually unwinding the stack is not clear to me.

2. Also should i compile my binary with debug symbol if yes i have no idea
please help .

3 can i check all the things while compiling binary like crash issue memory
etc?
4. Can I run my binary with gdb at run time?

5. The best to narrow down the crash , if libraries are not under my
control.


Thanks
Kunal


On 7 May 2020 12:43 a.m., "Andrew Burgess" <andrew.burgess@embecosm.com>
wrote:

* Kunal Chauhan via Gdb <gdb@sourceware.org> [2020-05-05 21:39:32 +0530]:

> ---------- Forwarded message ----------
> From: "Kunal Chauhan" <atkunalchauhan@gmail.com>
> Date: 5 May 2020 6:55 p.m.
> Subject: Help: please help to use gdb and its related terms
> To: <gnu@gnu.org>
> Cc:
>
> Hi Team,
>
> Here is some output of gdb I am not understanding .
>
> #0  0xb66e8ee4 in strlen () from /lib/libc.so.6
>
> [Current thread is 1 (LWP 2084)]
>
> (gdb) bt full
>
> #0  0xb66e8ee4 in strlen () from /lib/libc.so.6
>
> No symbol table info available.

You're currently in strlen in libc.so.6 (at address 0xb66e8ee4), but
you don't have debug information available, so GDB will have unwound
the stack using analysis of the function prologue (instead of using
unwind information from the debug info).

>
> #1  0xb6da3854 in ?? () from /opt/qcom/lib/libcurl.so.4
>
> No symbol table info available.

The previous frame was somewhere is libcurl.so.4 (at address
0xb6da3854) , though GDB couldn't find a nearby text symbol (that's
what the '??' tells us).  There's no debug information available for
this library either.  The '??' could be the result of some really
aggressive symbol removal from libcurl, or might indicate that the
previous unwind went wrong and you're not really at 0xb6da3854.

Again, the stack is going to be unwound using prologue analysis as
there's no debug information available.

>
> #2  0x05b40000 in ?? ()
>
> No symbol table info available.

This is starting to look very wrong now (I'm always suspicious of
addresses ending with 0000), GDB couldn't identify a function or even
a file that claims this address.

Again (obviously maybe) no debug information, prologue analysis unwind.

>
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>

After unwinding GDB got back the same stack pointer and program
counter for the previous frame.  This most likely means the prologue
analysis unwinder is trying to unwind an incorrect location, and is
just getting back the same junk each time.

GDB prints the above message and stops to avoid going into an endless
loop.

You should consider installing debug information if possible for libc
and libcurl, this might aid the unwinder.

It's possible that the prologue analysis unwinder went wrong for your
target, you should try manually unwinding the stack (by checking the
ABI for your target, and examining the machine state) and see if you
agree with GDB.

Hope this helps,

Thanks,
Andrew