[Dev] Compilation failing on Windows if `BACKTRACE` is defined

Game Talk The Toolbox
1

Hi,

Discovered the game a few weeks ago and I really enjoy it.

I’d like to contribute to the game code, so I tried to compile the source. As I’d like to add some code around the backtrace / debugging code (which directly falls into my domain of expertise) I also defined the BACKTRACE macro.

  • O.S: Windows 10
  • Build environment:
    • Visual Studio 2017 Enterprise (15.9.9)
    • Windows 10 SDK 10.0.17763.0
  • Last pull:
    $ git log -1
    commit 45d0f89a1dbb62b4975b501110df87cff5303d97 (HEAD -> master, origin/master, origin/HEAD)
    Merge: 40b828ee4d ca910fec58
    Author: ZhilkinSerg <ZhilkinSerg@users.noreply.github.com>
    Date:   Wed Mar 20 09:37:19 2019 +0300

Everything compile fine except 6 errors in debug.cpp:

I could easily fix those errors by adding the right headers (those functions exists on Windows in the CRT) but I’m wondering if I missed something in the build chain (maybe a missing constant to be defined?) or something else (e.g. BACKTRACE is an experimental feature?).

Thanks a lot, and kudos to the devs and the community as a whole!

Note: I’d gladly make a PR to fix the problem (if there’s a problem, of course).

2

If you are using IDE there are should be no issues as BACKTRACE flag isn’t defined in our existing VS solution/projects and therefore code guarded with #ifdef BACKTRACE is not used - just follow the guide.

I you are using command line - we do not have a guide for that yet (but would like to have one and you are welcome to add it).

You can also use MSYS to compile on Windows and there are should be no issues too - just follow the guide.

3

Also I am not completely sure whether it is really necessary to define BACKTRACE macro for existing VS solutions/projects as you can always run app under awesome VS debugger while you are on Windows.

4

Thank you very much for your answer!

If I understand correctly, BACKTRACE is not defined as of now for the release version.

I defined the BACKTRACE constant as I was thinking about implementing code to do an out of process dump (that is an external process would call MiniDumpWriteDump rather than the main process) on Windows which would help to diagnose / debug the problem in the case of a crash.

Speaking of which, is it something that would be beneficial or not? I already implemented some code but there are various things that might not be considered useful by the CDDA developers (namely an out of process dumper, or the necessity to distribute the .pdb files alongside the game to get meaningful stack traces).

If you think it doesn’t worth the hassle, I might try to found other ways to contribute to the game.

Thanks!

EDIT: technically, the idea (of having an external dumper) is to answer to this comment in the code.

5

I agree that having meaningful stack trace for Windows builds would be great.

Unfortunately precompiled Windows builds we are distributing are crosscompiled on Linux using mxe and gcc, so I believe it won’t be possible to output PDB for these builds.

When compiled under VS PDB files are already produced even without BACKTRACE flag (I guess it is configured in VS project file).

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5
изображение.png1664×1056 195 KB

Maybe you can search for a way to compile using VS under Linux?

6

Thanks a lot for your answer!

ho, OK I wasn’t ware of that.

Yes, exactly it’s a matter of the compiler itself. Sorry if I wasn’t clear on what i’m trying to achieve, so I’ll try to address it in in a cleaner way:

  • My idea is to add code to the base game that would add an external process dumper

    • As soon as the main game crash the dumper enter into action and create a dump of the process.
    • This would obviously only work for Windows system.

  • If a player encounter a crash, they would have a dump file (locally) that could be uploaded somewhere while filling an issue on github (which could be uploaded alongside the save file for example).

    • dump files help tremendously while trying to diagnose a crash.

  • If somehow the current build chain could offer a way to distribute a program database (*.pdb) alongside the main binary this would help to:

    • have a meaningful stack trace on the log file (which is also displayed to the end user).
    • help the process dumper to gather a lot of information on the crashed binary.

The player could upload it’s PDB file alongside the dump file or the crash examiner (the person trying to understand the bug and fix it) could simply look at the version of the game in the log file and pull out the corresponding PDB from somewhere else (probably from the jenkins builder).

Once the person have the PDB they could get the game which correspond to the player version and debug the program with all the necessary symbolic information in the debugger.

Hmmm nothing comes to my mind about that… :frowning: I don’t think VS has a tool chain available on linux. I might be wrong though…

  • A few possibilities:
    • Having a Windows VM (running on linux) with VS installed for compiling the game.
    • Using an external service to do the windows build (e.g Appveyor which is free for open source projects.)
    • I think clang / LLVM has a way to produce pdb files but the last time I checked it was deemed experimental. I need to double check that.

Thanks!

7

Update

LLVM clang supports PDB generation: http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html

It’s not feature complete but almost everything is generated: https://releases.llvm.org/8.0.0/tools/clang/docs/MSVCCompatibility.html

As clang-cl imitates closely the Microsoft compiler, so I think this is an interesting perspective.

I’m going to do a few tries to see if CDDA compiles with LLVM (and then clang-cl), generates a few crashes and see how windows debuggers deal with the generated PDBs.

8

That would be great if we could distribute PDB and produce sane crash reports on Windows.

9

Indeed :slight_smile:

I saw yesterday that there’s already a builder on Appveyor. Would distributing the output of this builder be an option? As it is directly compiled with the MS compiler, you could get the main binary and the PDB out of the builder.

Otherwise would upgrading the compilation chain on the jenkins builder to clang 8 (and using clang-cl) be also an option?

I do not feel entitled to propose such drastic changes to the build chain as I’m not a core dev. But if you (the core devs) think one of these options might worth a try I would definitely give a hand to make it happen.

Thanks!

edit oh and btw, thanks for accepting the PR :+1: