1

With lots of versions of binaries, if I receive a core dump, I currently rely on the sender telling me the version they were running so I can match it with the right source/symbols that built it. They are often incorrect and much time is wasted. Even asking them to send the binary with the core is error-prone. Is there a way to embed a version string into the source code that I can look for in a core dump? Or is there some kind of hash/signature I can use to match it from a build? Or is there a better convention?

mark
  • 5,269
  • 2
  • 21
  • 34
  • Not sure if it's feasible for you, but I have my software, when generating a dmp file, name the file `Product_vMajor.Minor.Build.dmp` or something to that effect. That way the build version is directly in the file name. – ChrisMM Oct 08 '21 at 18:29

2 Answers2

3

I currently rely on the sender telling me the version they were running so I can match it with the right source/symbols that built it.

Since you are talking about core dumps, it seems exceedingly likely that you are using an ELF platform (probably Linux).

On an ELF platform, the standard way to identify a binary is to use --build-id linker flag, which embeds a unique checksum into the binary. This is likely passed to the linker from g++ by default, but you can explicitly specify that flag with -Wl,--build-id as well.

Linux kernel saves the page containing the NT_GNU_BUILD_ID ELF note, which allows you to

  1. Immediately identify what binary produced the core (using e.g. eu-unstrip -n --core core) and
  2. Use GDB to automatically load correct debug info. See e.g this article.
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Even though I was looking for the ability to do something more like having "release-1.2.3" in the core, this is clearly the "right" way. Additionally, I can access the build-id at runtime via this method: https://stackoverflow.com/questions/55641889/access-build-id-at-runtime. And finally I still get what I want by using alloca on my main thread's stack an copying the version string there - I'm able to see that in the core as well, so best of all worlds. – mark Oct 11 '21 at 16:17
0

Can your main call a generated int build6278() function which then call into you real entry point? Your build system would need to generate this stub with a different name per version.

Then you just need to look up the callstack and find this function name. This assumes a build with symbols.

Alternatively, using your suggestion:

int main()
{
    const char* version = g_Version; // that symbol will have to be added by your build system
    std::cout << g_Version << std::endl;
    return regularMain();
}

should allow you to check the local version pointer in the crash dump.

Jeffrey
  • 11,063
  • 1
  • 21
  • 42
  • It could, and I do build with symbols, but I strip them out before release so presumably I'd still be in the same boat. Although it got me thinking; I could allocate a string on the heap with the version... or put it on the stack of the main thread... – mark Oct 08 '21 at 18:46
  • Just do something to convince the compiler to not optimize it out. – Jeffrey Oct 08 '21 at 18:51
  • Would it work to use an integer instead of a string and pass it as an argument to `regularMain()`? – JaMiT Oct 08 '21 at 19:20
  • Yes that's another good thought... an integer has the advantage of not being a reference with data residing elsewhere. I'll play with it... – mark Oct 08 '21 at 19:36