我可以从Windows上的ghc Haskell进程转储中收集哪些信息？

Question

One of the users of my command line application has reported what appears to be an infinite loop. They helpfully took a dump of the process (via Task Manager) while it was in this state and sent it to me.

I'm not sure how to get useful information out of this dump. My normal technique of windbg -z the-dump-file.dmp -y releases\\v5.0.0 -i releases\\v5.0.0 doesn't give me much information that I know how to interpret. Are there ghc-specific tools I can use instead?

Moving forward, are the build options I should add or other things I should do to my release process to make this kind of post-mortem debugging more fruitful?

Here's an example of the stacks that I'm seeing. Not much useful info, especially for someone used to debugging C/C++ code in WinDbg. :-)

   0  Id: 112dc.cc18 Suspend: 1 Teb: 00000000`00341000 Unfrozen
*** ERROR: Module load completed but symbols could not be loaded for gbc.exe
 # Child-SP          RetAddr           Call Site
00 00000000`01b7d8d0 00000000`01049f71 gbc+0xc5676e
01 00000000`01b7d930 00000000`0104b5b4 gbc+0xc49f71
02 00000000`01b7d9a0 00000000`0104c644 gbc+0xc4b5b4
03 00000000`01b7da60 00000000`0104c1fa gbc+0xc4c644
04 00000000`01b7dab0 00000000`0042545b gbc+0xc4c1fa
05 00000000`01b7db30 00000000`011c40a0 gbc+0x2545b
06 00000000`01b7db38 00000000`0535bee1 gbc+0xdc40a0
07 00000000`01b7db40 00000000`010ffd80 0x535bee1
08 00000000`01b7db48 00000000`0535bee1 gbc+0xcffd80
09 00000000`01b7db50 00007ffb`3581fb01 0x535bee1
0a 00000000`01b7db58 00007ffb`3581b850 imm32!?MSCTF_NULL_THUNK_DATA_DLB+0x2e9
0b 00000000`01b7db60 00000000`00000010 imm32!CtfImmGetCompatibleKeyboardLayout
0c 00000000`01b7db68 00000000`00000000 0x10

   1  Id: 112dc.d324 Suspend: 1 Teb: 00000000`00349000 Unfrozen
 # Child-SP          RetAddr           Call Site
00 00000000`05c2fc48 00007ffb`36441563 ntdll!ZwWaitForWorkViaWorkerFactory+0x14
01 00000000`05c2fc50 00007ffb`34172774 ntdll!TppWorkerThread+0x293
02 00000000`05c2ff60 00007ffb`36470d61 kernel32!BaseThreadInitThunk+0x14
03 00000000`05c2ff90 00000000`00000000 ntdll!RtlUserThreadStart+0x21

   2  Id: 112dc.11b48 Suspend: 1 Teb: 00000000`0034b000 Unfrozen
 # Child-SP          RetAddr           Call Site
00 00000000`0642dd38 00007ffb`32f2988f ntdll!ZwWaitForSingleObject+0x14
01 00000000`0642dd40 00000000`00ffca15 KERNELBASE!WaitForSingleObjectEx+0x9f
02 00000000`0642dde0 00000000`00000000 gbc+0xbfca15

Answer 1

Some resources that might be useful. (If there are more up-to-date ones, I would like to see them myself.)

• https://ghc.haskell.org/trac/ghc/wiki/Debugging/CompiledCode
• https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/debug-info.html
• https://wiki.haskell.org/Debugging

A few important nuggets:

The runtime flag +RTS -? Will tell you what runtime flags add debugging information. These will start with +RTS -D . For example, +RTS -DS turns on a number of runtime assertions and sanity checks.

The strange names you see are encoded in something called Z-encoding. This is defined at https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/cmm/CLabel.hs .

If you can recompile the code with debugging symbols on and threading off, and still reproduce the bug, you can set breakpoints (or hit control-C) inside the debugger and backtrace from there. You can examine memory with a command like print/a 0x006eb0c0 (although you seem to be using 64-bit pointers). You can see the assembly-language instruction that crashed with disassemble .

You need to use the -ddump-stg compile flag to see what the variable names mean, because that is the last phase of the transformation before the program is assembled, and the variable names you see in the debugger correspond to the ones here.

You can instrument the code with Debug.Trace .