cadey
/
nim-wiki
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated Hunting crashes: The ultimate guide (rest)

This commit is contained in:
Andreas Rumpf 2017-02-01 09:27:58 +01:00
parent dbfdfb8a76
commit 807e605f78
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Hunting-crashes:-The-ultimate-guide.rest
View File

@ -1,5 +1,12 @@
Ok, so your nice Nim program crashes under various hard-to-reproduce conditions. What can you do about that?
Generally speaking the most important question when you have a corruption is **what piece of code wrote to this memory location**. This question is answered by *watchpoints*, breakpoints are mostly useless for this. In general I found breakpoints only useful to set *watchpoints* in them.
Classical debugging
===================
Use ``--debugger:native`` and use GDB or LLDB or Visual Studio for debugging. Note that currently local variables are mangled and a ``0`` is attached to the name.
Test with different GCs
=======================
@ -34,6 +41,8 @@ Test different compiler options
enables assertions in Nim's GC.
``-d:nimBurnFree``
overwrite deallocated memory with 0xff bytes so that "access after free" triggers a segfault.
``--tlsEmulation:on|off```
turn "thread local storage emulation on/off". This is helpful when you do have an issue in a threaded program. As I recently learned, the fact that TLS is cleaned at thread exit is often an overlooked cause for crashes. TLS is *unsafer* than global storage in this respect.
Edit lib/system/mmdisp.nim and gc.nim
=====================================
@ -42,3 +51,4 @@ Even more debugging options can be enabled by editing ``lib/system/mmdisp.nim``.
One problem with corruptions is their non-deterministic nature, in particular heap and stack addresses change from run to run. Define ``-d:corruption`` to enable "cell IDs", so that every "cell" (that is every ``ref``/``string``/``seq``) gets a unique ID. It's often interesting to see if the corrupted cell has the same ID from run to run or if it differs. If it differs the bug is non-deterministic. Within the GC ``writeCell`` can be used to output offending cells.