* [Help/Hint]: gdb output analysis
@ 2020-05-14 13:36 Kunal Chauhan
2020-05-14 13:48 ` Philippe Waroquiers
0 siblings, 1 reply; 4+ messages in thread
From: Kunal Chauhan @ 2020-05-14 13:36 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Help/Hint]: gdb output analysis
2020-05-14 13:36 [Help/Hint]: gdb output analysis Kunal Chauhan
@ 2020-05-14 13:48 ` Philippe Waroquiers
2020-05-14 14:15 ` Kunal Chauhan
0 siblings, 1 reply; 4+ messages in thread
From: Philippe Waroquiers @ 2020-05-14 13:48 UTC (permalink / raw)
To: Kunal Chauhan, gdb
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Help/Hint]: gdb output analysis
2020-05-14 13:48 ` Philippe Waroquiers
@ 2020-05-14 14:15 ` Kunal Chauhan
2020-05-14 19:03 ` Philippe Waroquiers
0 siblings, 1 reply; 4+ messages in thread
From: Kunal Chauhan @ 2020-05-14 14:15 UTC (permalink / raw)
To: Philippe Waroquiers; +Cc: gdb
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 <
philippe.waroquiers@skynet.be> 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:atkunalchauhan@gmail.com <E-mail%3Aatkunalchauhan@gmail.com>*
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Help/Hint]: gdb output analysis
2020-05-14 14:15 ` Kunal Chauhan
@ 2020-05-14 19:03 ` Philippe Waroquiers
0 siblings, 0 replies; 4+ messages in thread
From: Philippe Waroquiers @ 2020-05-14 19:03 UTC (permalink / raw)
To: Kunal Chauhan; +Cc: gdb
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-14 19:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-14 13:36 [Help/Hint]: gdb output analysis Kunal Chauhan
2020-05-14 13:48 ` Philippe Waroquiers
2020-05-14 14:15 ` Kunal Chauhan
2020-05-14 19:03 ` Philippe Waroquiers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).