[Help/Hint]: gdb output analysis

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Help/Hint]: gdb output analysis

Sourceware - gdb list mailing list
Hi Team,

I got some output at gdb with core dump file

*I have not a clue that how the address shown by gdb can  help me to go to
exact point of code violation.*
*please suggest some clue !*

*Logs by gdb:*

Core was generated by `/opt/proj/bin/ty 0 0'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb66e8ee4 in strlen () from /lib/libc.so.6
[Current thread is 1 (LWP 2084)]
(gdb) bt
#0  0xb66e8ee4 in strlen () from /lib/libc.so.6
#1  0xb6da3854 in ?? () from /opt/qcom/lib/libcurl.so.4
#2  ---Type <return> to continue, or q <return> to quit---

thanks
kunal
Reply | Threaded
Open this post in threaded view
|

Re: [Help/Hint]: gdb output analysis

Sourceware - gdb list mailing list
If you get a SEGV in strlen, it is typically because you
call it with a bad pointer (null pointer, not addressable memory, ...)
or with a pointer to a non null terminated string and strlen then
goes too far and reaches an not addressable page.

You should 'Type <return>' to continue and examine the callstack
and the variables/args in the call stack.
As strlen is called by libcurl, you should look at how your application
calls libcurl.

The gdb command
  bt full
will show you the full stack trace with args and local variables.

Good luck

Philippe

On Thu, 2020-05-14 at 19:06 +0530, Kunal Chauhan via Gdb wrote:

> Hi Team,
>
> I got some output at gdb with core dump file
>
> *I have not a clue that how the address shown by gdb can  help me to go to
> exact point of code violation.*
> *please suggest some clue !*
>
> *Logs by gdb:*
>
> Core was generated by `/opt/proj/bin/ty 0 0'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0xb66e8ee4 in strlen () from /lib/libc.so.6
> [Current thread is 1 (LWP 2084)]
> (gdb) bt
> #0  0xb66e8ee4 in strlen () from /lib/libc.so.6
> #1  0xb6da3854 in ?? () from /opt/qcom/lib/libcurl.so.4
> #2  ---Type <return> to continue, or q <return> to quit---
>
> thanks
> kunal

Reply | Threaded
Open this post in threaded view
|

Re: [Help/Hint]: gdb output analysis

Sourceware - gdb list mailing list
Hi
I have only binary and core file at running the gdb only
will bt full is not working it showing following
>>>>> : previous frame is identical ,
>>also when i tried : return it shows , it will need the process, should I
need the process to run , but scenerio of crash I can not produce.

Steps that I followed as below:


> gdb process core file

output:
    0xb66e8ee4 in strlen () from /lib/libc.so.6
> #1  0xb6da3854 in ?? () from /opt/qcom/lib/libcurl.so.4
> #2  ---Type <return> to continue, or q <return> to quit--

>bt full

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





On Thu, May 14, 2020 at 7:18 PM Philippe Waroquiers <
[hidden email]> wrote:

> If you get a SEGV in strlen, it is typically because you
> call it with a bad pointer (null pointer, not addressable memory, ...)
> or with a pointer to a non null terminated string and strlen then
> goes too far and reaches an not addressable page.
>
> You should 'Type <return>' to continue and examine the callstack
> and the variables/args in the call stack.
> As strlen is called by libcurl, you should look at how your application
> calls libcurl.
>
> The gdb command
>   bt full
> will show you the full stack trace with args and local variables.
>
> Good luck
>
> Philippe
>
> On Thu, 2020-05-14 at 19:06 +0530, Kunal Chauhan via Gdb wrote:
> > Hi Team,
> >
> > I got some output at gdb with core dump file
> >
> > *I have not a clue that how the address shown by gdb can  help me to go
> to
> > exact point of code violation.*
> > *please suggest some clue !*
> >
> > *Logs by gdb:*
> >
> > Core was generated by `/opt/proj/bin/ty 0 0'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0  0xb66e8ee4 in strlen () from /lib/libc.so.6
> > [Current thread is 1 (LWP 2084)]
> > (gdb) bt
> > #0  0xb66e8ee4 in strlen () from /lib/libc.so.6
> > #1  0xb6da3854 in ?? () from /opt/qcom/lib/libcurl.so.4
> > #2  ---Type <return> to continue, or q <return> to quit---
> >
> > thanks
> > kunal
>
>

--
*Thanks with Regards!*

*Kunal Chauhan*
*Mob:09813614826*
*Mob:08860397903*

*E-mail:[hidden email] <E-mail%[hidden email]>*
Reply | Threaded
Open this post in threaded view
|

Re: [Help/Hint]: gdb output analysis

Sourceware - gdb list mailing list
On Thu, 2020-05-14 at 19:45 +0530, Kunal Chauhan wrote:

> Hi  
> I have only binary and core file at running the gdb only
> will bt full is not working it showing following
> >>>>> : previous frame is identical ,
> >>also when i tried : return it shows , it will need the process, should I need the process to run , but scenerio of crash I can not produce.
>
> Steps that I followed as below:
>
>
> > gdb process core file
>
> output:
>     0xb66e8ee4 in strlen () from /lib/libc.so.6
> > #1  0xb6da3854 in ?? () from /opt/qcom/lib/libcurl.so.4
> > #2  ---Type <return> to continue, or q <return> to quit--
>
> >bt full
>
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb
Then it will be painful :(.
You might try to guess what went wrong in the stack, and then
using e.g. 'frame address STACK-ADDRESS' if you can locate
a previous correct frame address.

I am sorry I will not be able to help more on that.

Philippe