It's not always straightforward to open a core dump originating from customer's environment, since there's a wide variety of versions of all the binaries involved - usual workflow is to install a VM with the SP that the customer is using, enable debuginfo repositories and then follow the buildid hints that gdb is providing.

However this sounds like a bit of an overkill. Lately, there has been a debuginfod project announced:

  • https://fosdem.org/2020/schedule/event/debugging_debuginfod/
  • https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server/

It might be beneficial to investigate it and find out whether it could be useful to our daily work when solving customer-reported issues.

@marxin has been spending some time with debuginfod recently. Also see 20200113221924.GC22149@suse.de thread on research ML.

Looking for hackers with the skills:

Nothing? Add some keywords!

This project is part of:

Hack Week 19


Comments

  • marxin
    4 months ago by marxin | Reply

    I would be happy if somebody can experiment with the debuginfod protocol. There's a status page made by elfutils people: https://sourceware.org/elfutils/Debuginfod.html

    and I've set up a server instance for openSUSE TW packages: https://debuginfod.opensuse.org/

    Note that I haven't pushed elfutils (with debuginfod capability) to Factory, you'll have to use the devel project: https://build.opensuse.org/package/show/Base:System/elfutils

Similar Projects

This project is one of its kind!