Search code examples
debugginggdberlangcoredump

using gdb to analyze core dump - generated by an erlang application


I have a core dump file that has been generated by an erlang application and would like to analyze. This is my first time using gdb. I installed gdb but no luck running it with the executable and the core dump file.

I give gdb the executable and the core dump as

  gdb erts-5.9.3/bin/beam.smp core

When I run that, I get,

  GNU gdb (GDB) 7.9 
  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 "x86_64-apple-darwin15.4.0".
  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 erts-5.9.3/bin/beam.smp...(no debugging symbols     found)...done.
  "/Users/sad/projects/core" is not a core dump: File format not recognized

How can I solve this?


Solution

  • This GDB was configured as "x86_64-apple-darwin15.4.0". "/Users/sad/projects/core" is not a core dump: File format not recognized

    $ file core
    /Users/sad/projects/core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), ...

    Mac OS does not use ELF file format. We can safely assume that this core came from some other system, not the one you are trying to analyse it on.

    It is still possible to analyse that core on the Mac OS system, but you need:

    1. a cross-gdb (i.e. one that can run on Mac OS host, but can deal with ELF files for your target; it is likely that you'll have to build such GDB yourself) and
    2. (unless you have a fully-static executable), you need complete set of shared libraries from the host on which the crash happened. See this answer.

    In general, it is much easier to do the post-mortem analysis on the host where the crash happened.