[Help/Hint]: gdb output analysis

Philippe Waroquiers philippe.waroquiers@skynet.be
Thu May 14 13:48:35 GMT 2020

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


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

More information about the Gdb mailing list