Window users please comment on how to run debugger on FC

[Kunda1]

http://www.freecadweb.org/wiki/index.ph ... _Backtrace has Linux and MacOSX covered but is missing WIndows. Can someone please fill in the gap? Future Win testers and devs will appreciate it.
Cheers!

[ian.rees]

I don't think we want the instructions to be too detailed, otherwise they'll end up being more work to maintain.

First, get setup to build on Windows: http://www.freecadweb.org/wiki/index.ph ... ith_VS2013.
Then, while you're still in Visual Studio run the FreeCAD you built in the debugger, reproduce the crash, and look at call stack https://msdn.microsoft.com/en-us/librar ... .120).aspx. -Ian-

[sgrogan]

I don't know of an equivalent to gdb for windows, that doesn't require having some version of Visual Studio installed.
The best I know is to start FreeCAD on the command line w/

Code: Select all

freecad -l

A log file will be written to C:\Users\USERNAME\AppData\Roaming\FreeCAD called FreeCAD.log. It's a hidden directory.
Of course a debug build is possible, but this is developer stuff, not for a postmortem user report.

[wmayer]

Of course a debug build is possible, but this is developer stuff, not for a postmortem user report.

And the debug version links to the debug version of the C runtime library which you are not allowed to deploy.

On Windows it's actually easy. If you have a hard crash then a file crash.dmp will be created (in the directory of the user.cfg file). This can be sent to the devs and loaded with VS. The debugger then stops at the function where the crash happened.

However, with a normal Release build you just see the dlls and some hex numbers but not the function names. To circumvent this limitation FreeCAD can be built with the cmake option "FREECAD_RELEASE_PDB". This will create a Release build with minimal debug information and the pdb files to each dll. Since the pdb/dll files seem to contain some kind of signature it's important to keep the pdb after a release is made because when rebuilding FreeCAD from exactly the same sources the newly created pdb files will be ignored by the debugger. So, therefore it's best when creating a release that the pdb files (maybe in a separate zip file) will be uploaded, too.

Additionally, when running FreeCAD with the option -l then some additional callstack information are written to the FreeCAD.log file.

[sgrogan]

And the debug version links to the debug version of the C runtime library which you are not allowed to deploy.

Thanks wmayer, after posting I was re-reading this article: http://www.wintellect.com/devcenter/jro ... -must-know your response has filled in the gaps for me. I'll build the pdb's for the next developer snapshots and see how it goes.

[Kunda1]

And the debug version links to the debug version of the C runtime library which you are not allowed to deploy.

Thanks wmayer, after posting I was re-reading this article: http://www.wintellect.com/devcenter/jro ... -must-know your response has filled in the gaps for me. I'll build the pdb's for the next developer snapshots and see how it goes.

ToDo: condense all this in to useful instructions on the wiki Debugging page.

[wmayer]

In some cases it's possible to make the dll and pdb matching again. For more details have a look here:
http://www.debuginfo.com/tools/chkmatch.html
http://stackoverflow.com/questions/7448 ... h-properly

[Kunda1]

And the debug version links to the debug version of the C runtime library which you are not allowed to deploy.

Thanks wmayer, after posting I was re-reading this article: http://www.wintellect.com/devcenter/jro ... -must-know your response has filled in the gaps for me. I'll build the pdb's for the next developer snapshots and see how it goes.

@sgrogan, was this followed-up on ? Just wondering.

[sgrogan]

@sgrogan, was this followed-up on ? Just wondering.

I could only produce the release .pdb's if I created them at the same time as the compilation.
At the time I did publish some matching "release" .pdb's, but there was little interest. The creation of these increases the package size (or split as a separate package) with little gain.
In practice, to achieve a usable debug build on Win you need to compile a debug build locally, using the Libpack.

There might be some limited use of a release .pdb package for the stable releases, to get a more meaningful stack trace on a core dump. Practically though Win/release uses MSVS SEH (structured exception handling) so crashes don't happen in the release build.

[Kunda1]

Thanks for the response!

We could add this as a TODO once we get a CI working again (that we we have an option to generate a debug build if needed, not by defualt). Also if we could make a Docker build debug builds in windows...? What do you think?