0

I have a coredump extracted from a remote target in production. I need to debug it on my own computer since the target lacks gdb-server. Locally, I have the corresponding tooling, debug symbols and source code.

The problem is that when I load this core into gdb most, if not all, addresses and symbols are not resolved:

#15 0x00007ffc78fd87a0 in ?? ()
#16 0x0000000002147bb0 in ?? ()
#17 0x00007ffc78fd8740 in ?? ()
#18 0x0000000000000006 in ?? ()
#19 0x0000332d70667351 in ?? ()
#20 0x00000000021612a0 in ?? ()
#21 0x00007ffc78fd8760 in ?? ()
#22 0x0000000000000006 in ?? ()
#23 0x0000332d70667351 in ?? ()
#24 0x00000000021612a0 in ?? ()
#25 0x0000000000000012 in ?? ()
#26 0x00000000021468e0 in ?? ()

If I recompile some module of the application with -no-pie -fno-PIE, the frames for that exact module become available. However, that is not an option. The target is in production and needs this security feature enabled.

My main goal is to have some way of debugging this system post-mortem in another computer since the only thing I'll have from a crash is a coredump that I can extract. Is there any way around this? Am I missing something? Perhaps, some way of embedding the exact memory offsets that were used when the application was running to the coredump; in a way that gdb will read.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
Bipolar Transistor
  • 108
  • 7
  • 2
    ASLR is irrelevant -- the most likely root cause is system library mismatch, If you provide correct system libraries (as the linked answer shows) GDB will recover at-runtime addresses on its own. – Employed Russian Mar 31 '22 at 13:40
  • @EmployedRussian I assumed the libraries were OK since the result of ```info sharedlibrary``` showed that all libraries were loaded from the correct path (corresponding sysroot). These are unstripped matching versions of the system libraries running on the target. I assumed that this was ASLR fault when I started experimenting with ```-no-pie -fno-PIE``` and suddenly more frames were becoming available. In this case, I was able to substitute the ones on the target. I'm trying to setup the debug workflow, the target is not really deployed. – Bipolar Transistor Mar 31 '22 at 13:58
  • 1
    If you are already using `sysroot`, then this is _probably_ not a duplicate, so I reopened this. But you should edit your question to show _exactly_ what you've done and what you see. – Employed Russian Mar 31 '22 at 15:33

1 Answers1

1

After two days and I've just figured it out. A rookie mistake.

I was calling gdb on the .debug version of the app instead of the app itself:

$ cd ~/sysroot
$ x86_64-linux-gdb usr/bin/.debug/app -c <path_to_dump>

instead of:

$ cd ~/sysroot
x86_64-linux-gdb usr/bin/app -c <path_to_dump>

I've been reusing that command from bash history for the past 2 days and it was giving me a false positive. I corrected it and all symbols show up.

Bipolar Transistor
  • 108
  • 7