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
-
about 4 years 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!