The `getDebuggingInfo` function relies on `programCounters` being a
NULL terminated list. However, none of the usage actually adds NULL...
- In the path that passes `getProgramCounters` result into
`getDebuggingInfo`, no explicit 0 value is added to `result`.
In practice, there happens to be a 0 there very frequently,
but it is not guaranteed (`env MallocScribble=1`), and even
if it is not there the implementation often continues to work
when processing the extra garbage data, silencing the problem.
- In the path from Nim `addDebuggingInfo` (`system/stacktraces.nim`),
the `programCounters` list is constructed by Nim logic and also
does not add a 0 value to the list. This means that even if we fix
`getProgramCounters` to produce NULL terminated list, other usage
is still broken, and outside the control of this library.
Therefore, remove the NULL terminator logic and pass length explicitly
while retaining any early loop exits when encountering 0 for compat.
Also fix some memory leaks in error conditions.
Allow separating stack unwinding and program counter collection from the
more expensive step of getting the associated debugging info for each
program counter.
This is useful for implementing efficient backtraces for exceptions - a
scenario in which you add a new backtrace each time an exception is
re-raised, but you rarely need to print them (usually when that
exception is uncaught).
libunwind snapshot - 673484b34189b1bccf73a2ec96968092bc8a26a7
even though it cannot work in there (a global "--import:libbacktrace"
flag may be applied to *.nims files, so we don't want the import to fail
in that case).
Etan Kissling
tersec
Zahary Karadjov
Ivan Yonchovski
Ștefan Talpalaru