As users of a program enlarge and diversify, it becomes natural to think about automatic bug collecting. First step through this automation will be preparing and packaging things for an automated bug collecting system. In this post, I will document the initial steps we went through to trigger generation of a bug report package after a recovery from hard kill (kill -9) or crash.

The most important part of postmortem analysis will be investigating crash dumps. Unfortunately, Windows does not produce crash dumps as default. However, it may be easily made so by registry modification. For global configuration add  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ LocalDumps key to registry with corresponding parameters about dump type, dump folder, and dump count. These global values may be overridden by application level configuration, placed in an application.exe key as may seen at following RegEdit window;

bugcollector-registry-editor

In the upper figure, we asked windows to generate mini crash dumps at d:\test_folder\multithread\datafiles\cores directory.

Now assume we have a fatal bug as;

bugcollector-form-a-crash

After a crash there should be dump file appearing at corresponding folder.

bugcollector-crash-dump

Our bug report will include crash dump, log files and program configuration.

bugcollector-what-to-zip

It is important for log file to include information about actual software being running. As oldskool version information about major / minor defines are error prone, we may make version control commit information propagate through build software. An example of embedding git commit information may be seen at a previous post . This makes code of concern available by a simple checkout, other then searching version change which have possibility of being non unique.

Assuming program being build for multiple OS, zlib packager will be used. One drawback of zlib is it’s lack of native support for multiple files. This will be handled by a wrapper class preparing a tar file from bug package contents.

What tar does is collecting many files into an tarball archive file. Each  file is represented by a 512 byte header and multiple of 512 byte data chunks containing original file with (optional zero) padding to make multiple of 512 byte.

bugcollector-zlib-tar

 

In our case a wrapper class around zlib library is prepared which handles searching available files and creating tarball before operation.

For Linux side, the required steps for allowing crash dumps is handled before and requires modification of /etc/security/limits.conf for core size setting and /etc/sysctl.conf for name and path configuration.

 

 

Advertisements