Improve error reporting on Windows releases

[gfgtdf]

this fr is about our official windows release becasue i don't know how exactly the other releases handle this, also it might require a plattform dependent implementation.

Currently our rerror reporting is very poor, users get the usual ''wesnoth.exe stopped working'' dialog and that's it. No chance to provide useful information like dumps or stacktraces in bugreports. In particular for issues that cannot be reproduced easily this makes it very hard to fix them.

So what basicially needs to be done is creating a errorhandler that creates a dump and then generate stacktraces out of it. Ofc the relase woudl then also ned to be shipped with debug information. I also know that optimisations might make it harder to get a useful stacktrace but in my experience (with msvc) it is possible to get a good optimisation level and useful debug information at the same time, ofc it sometimes happens the debugger is unable to generate a good stacktrace but in 80% of the crashs there were no problems and implementing something like this is still totally worth it.

I think the main challenge here is that it somehow requires people to work together (packagers and developers) sicne our main windows release uses mingw while afaik the majority of our windows devs who might be able to implemnt this use msvc.

Maybe with the steam relese we could also use a steam feature to automaticially send crashreports to us, but this is really optional and just a random thought.

[Pentarctagon]

It would depend a lot on what you mean by "good optimization level". With gcc/clang at least, using the highest optimization level usually results in stacktraces with tons of "<optimized out>" lines. I'd imagine using LTO would also complicate things, if that eventually becomes stable enough.

[gfgtdf]

well by that i mean form what i tested the the builds it gave me were not slower then our current official release build.

Of course the stacktraces are not as good as in debug builds, they often point you to a call for function x at line y where ther is simply no call to function x, but if you think a little it is then easy to see that that stacktrace just skipped a few inlined functions or got the line number wriong by one etc. and is still ver helpful at figuring out what went wrong.

[CelticMinstrel]

This is not a bad idea but is definitely super platform dependent.

That said, it may not really matter that much anymore? MacOS automatically gives a stack trace when a program crashes, and if I understand correctly Linux produces a core dump from which the stack trace can be extracted.

That just leaves Windows… and if I'm not mistaken, Windows 10 actually does something similarly to Linux (writing a crash report to some standard location). So the people who would benefit would be mostly Windows 7 users? That's assuming it didn't yet have that crash report feature; it wouldn't surprise me if that is already in Windows 7.

[gfgtdf]

and if I'm not mistaken, Windows 10 actually does something similarly to Linux

I don't know what linux does, but i can tell that our current windows relerase does not give useful information. Even if windows 10 had such a feature, since wesnoth doesnt ship with any debug information there is no way windows could know the functionnames/codelines in the stacktrace etc.

[Pentarctagon]

I also don't believe linux produces any usable stacktrace without debugging information, unless there's been something I've been missing all this time. The reason macos probably is able to give any stack trace is because the default Release build flags for it include -Os -g for optimization and debugging info. Even if debugging information was present on a linux build though, my understanding is that you would still need a bit of additional code to be written(and the -rdynamic flag to be present) for any stacktrace to be present automatically on a crash.

Another concern would be how much it increases the download size - on linux with gcc at least, the default -O3 is ~22 MBs, while even adding just the -g flag balloons the current release executable size to nearly 400 MBs(though it compresses down to ~75 MBs with 7zip).

[cooljeanius]

This would be helpful for me for introducing my fiancée to Wesnoth