0

I know there is a similar question out there. But I think this question is different.

I'm using gdb-cross-aarch64 to analyze a dumped core file generated on an arm arch64 device.

My command line is like:

gdb-cross-aarch64 /path_to/gst-launch-1.0 /path_to/core.2135

and gst-launch-1.0 is depended on a shared lib libOmxCore.so.

Here is the output of the gdb:

GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux --target=aarch64-poky-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./work/aarch64-poky-linux/gstreamer1.0/1.4.5-r0/image/usr/bin/gst-launch-1.0...done.
[New LWP 2135]
[New LWP 2137]
[New LWP 2141]
[New LWP 2139]
[New LWP 2138]
[New LWP 2136]
[New LWP 2143]
[New LWP 2142]
[New LWP 2140]

warning: Could not load shared library symbols for 46 libraries, e.g. linux-vdso.so.1.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `gst-launch-1.0 filesrc location=samplevideo.mp4 ! decodebin ! fakesink'.
Program terminated with signal SIGABRT, Aborted.
#0  0x0000007fa1d42cb0 in ?? ()
(gdb) set sysroot /Disk_1/Alan_s_Work/path_to/image/
Reading symbols from /Disk_1/Alan_s_Work/path_to/libOmxCore.so...done.
(gdb) bt
#0  0x0000007fa1d42cb0 in ?? ()
#1  0x0000007fa1d46120 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

As shown above, I've set the sysroot in gdb, and symbols in libOmxCore.so and gst-launch-1.0 are read by gdb.

But I can't still see a valid stack backtrace through gdb.

I'm pretty sure that the signal SIGABRT is caused in libOmxCore.so.

What am I doing wrong here ? Or what else should I do ?

Thank You

Community
  • 1
  • 1
Alan
  • 469
  • 10
  • 26

1 Answers1

0

Those are the tricky errors to find. The debugger picks up the backtrace information it normally shows by walking upwards through the stack frames of the core dump you provide.

In case the stack is corrupted, there is obviously not any useful information left there that could be used to create the backtrace, or reverse argumentation: If you cannot see a proper backtrace, your code corrupted the stack. Not much post-mortem help the debugger can give you.

Corrupted stack, especially when working with an external library, can happen for a huge amount of reasons. Some are:

  1. Handing over memory the library expects to see on the heap on the stack
  2. handing over a pointer to a stack variable that is no longer valid (like returning a pointer to a local variable)
  3. Telling the library wrong stories about the variable or buffer size you gave it.
  4. Handing over a scalar rather than a pointer
  5. Assuming the library would allocate buffers and hand back pointers, but the library assumes otherwise.
  6. ...and a huge amount of other possible reasons...

Manually go through your code, aligning the memory areas you need to allocate with the requirements of the library. Find out in whose ownership the memory the library works with (is it your code or the lib that allocates it) and carefully check it is large enough for the requirements.

SIGABRT is being sent for a huge amount of reasons, some you might want to look at a bit more intensely:

  1. A thread running wild (i.e. not being join ed for
  2. anything about heap management like malloc and free with improper pointers
  3. And anything where your libraries find themselves in a situation where going on with the program is impossible.
tofro
  • 5,640
  • 14
  • 31
  • thank you @tofro . " I pretty sure that the signal SIGABRT is caused in libOmxCore.so" Because I plant a `assert(0)` in a function in libOmxCore.so on purpose. Since I want to tutoring myself on how to use `gdb`. – Alan Aug 18 '16 at 07:48