Stack trace explained or What to do with dump files

[FastEddie]

This paper describes what the dump.dmp files are good for and how to use them.

Summary and quick start
Once in a while Manalink shows a message to inform us about a function call that didn‘t go as expected, for example get_card_instance(1, -1). The dump.dmp file provides us the information which function was the culprit. It consists of an error message („bad parameters“), what went wrong („get_card_instance(1, -1)“) and the way the program took in the form of a stack trace. If you don’t want details this section is all you need. If you want to look under the hood, read the whole thing.

Without going into too much detail, a stack trace is the call order of functions with the last function at the top, when things went haywire. So if you know who called whom you can work backwards and see where the actual bug happens. Fortunately, some friendly programmer provided us with a perl script called dmp.pl in the main directory where also ManalinkEh.dll resides. It worked for me under the Linux Subsystem for Windows. Might as well under MinGW64 but I didn’t test this. To get it going do as follows:

Install perl and the package libcapture-tiny-perl. Under the Linux Subsystem enter

sudo apt install perl
sudo apt install libcapture-tiny-perl

in the command line and the packages will install. Fix the path to Magic-trace in line 33, Easiest thing to do is to set it to ‘./Magic-trace.c’ as both are in the same folder.
Say you dump file is in the same folder and called dump_23_v3.dmp. Then run it with

./dmp.pl ../bugs/dump_23_v3.dmp

You get an output like this:

At the top is the actual error message in turquoise. The yellow functions belong to the dll and are shown with file name and line number. Turquoise functions lower on the screen are from the exe. There we don’t have line numbers, unfortunately. The grey functions (actually the addresses in hex code) are system calls.