diff --git a/Hunting-crashes:-The-ultimate-guide.rest b/Hunting-crashes:-The-ultimate-guide.rest index 7027209..705075f 100644 --- a/Hunting-crashes:-The-ultimate-guide.rest +++ b/Hunting-crashes:-The-ultimate-guide.rest @@ -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. +