public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* [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).