From: Matthew Hodgson <matthew@mx...> - 2009-05-20 00:55:40
Is it possible to persuade a mingw application to dump a core file of
some kind on crashing? I'm familiar with using drmingw as a JIT
debugger, but I'd really like to be able to inspect the heap during
post-mortem - and generally have a complete snapshot of the state of the
app, rather than just a series of stack traces. Does anyone do this?
One option seems to be to invoke MiniDumpWriteDump in DbgHelp.dll to
generate a win32 minidump file from a crash handler - but it seems mingw
doesn't provide headers for DbgHelp.dll. Is there a reason why making
this API available is hard, or has nobody needed it yet?
Meanwhile, it seems that people like crystalspace3d.org have implemented
their own minidump writers
- and meanwhile Google breakpad never seems to have never got round to
supporting mingw, despite also having its own minidump writer
And then there's the problem that no debugger which can read
minidump files can resolve STABS symbols, as far as I know (although gdb
support seems to be in progress for WinCE minidumps).
Finally, I've seen the existence of mingwdump (as per
http://www.mail-archive.com/gdb@.../msg00073.html) - but it seems
very old and apparently doesn't support stack traces. Is anyone still
using it successfully?
Any info on how people actually perform post-mortem debugging beyond a
stacktrace would be much appreciated :)
P.S. What's the closest equivalent to valgrind under mingw? I'd
ideally like something which spots any invalid memory access, like
valgrind's memcheck, rather than a simple malloc replacement like mpatrol.
On 2009-05-21 16:12Z, asm23 wrote:
> Hi. If I remember correct. In the codeblocks windows distribution,
> there's a file named "exchndl.dll" used for crash dump. Maybe, it could
> help. You can ask developers.
'drmingw' provides a file by that name; I'd guess that codeblocks
is merely distributing a copy.