.RPT backtrace is broken in msys1 Windows installer builds
(This was gna bug #22711, originally reported Sep 2014. Presumably all of these were msys1 installer builds; I have no idea about msys2 builds.)
The Windows builds produce .RPT files on crash that contain a backtrace and other debugging info, which is very useful.However, the output is a bit broken:
- No function/line number information is ever produced for addresses within Freeciv itself (as opposed to dependencies like Gtk).
- Frequent warnings "Dwarf Error: found dwarf version '7573', this reader only handles version 2 information." interspersed in the output. (The supposed dwarf version is a random number that varies.)
- Occasional assertion fail "BFD 2.13.90 20030111 assertion fail ../../src/bfd/libbfd.c:584" and truncated output (e.g. last backtrace of bug #21874 original report)
I'm guessing that 2 and 3 are due to some disagreement between the format of DWARF debug info and whatever is parsing it at runtime. Don't know who's in the wrong, and whether it's specific to debug info baked into our precompiled dependencies. Dunno if 1 might have the same cause.
I'll use this ticket to describe the workarounds I'm using that let us get useful information out of these traces.
However, it would be good to get this fully working. At the moment, people reporting crashes can't tell different stack signatures apart, so tend to conflate different symptoms in the same bug report. (And blame Gtk for every crash because it's the only part of the backtrace with symbols resolved...)
How I'm working around (1) currently:
For general Windows-wrangling on Linux, the mingw-w64 package available in Debian-derived distros is great. It's a cross-compiler, but here I use it to look at precompiled binaries.
Also, to extract binaries from the installers, I use 7z (in p7zip-full on Debian): "7z x Freeciv-2.4.2-win32-gtk3-setup.exe" lets you get at the installer contents such as freeciv-gtk2.exe.
To decode a .RPT file I simply do "i686-w64-mingw32-nm -n freeciv-gtk2.exe" to list the symbols, and pick the symbol with the highest address not greater than the one in the backtrace.
[later] I have [scripted] this now; attached hacky script.
Bug #22625 comment 4 has another variant: "Dwarf Error: mangled line number section."
If it really is mangled, that might explain (1).
cazfi: Windows Installer builds are not debug-builds. I'll do test build with "-g" at least to see how much it would affect the size of the package.
jtn: Hm, in task #7729 cproc said installer builds contain debug symbols.
cazfi: I don't see them included in any way in the build process. He also says that he sees them only with gdb - which is able, in presence of sources on the host machine, to build up the information at run time.
cazfi: ...but it being autoconf default, and build process not removing it either, it actually should be there. We'll see.