Debugbuild to crashlog

[GWRon]

Wookie at discord asked for ways to autogenerate a kind of crashlog.
So you can hand out special builds to users experiencing crashes. Once it crashes you could collect certain information regarding source of the crash.

I suggested one way to achieve it: a wrapper binary which executes the debug build of the application of interest. If the debugger there kicks in the wrapper binary would command the debugger to spit out certain information...about current scope, backtrace etc.

While this could work (and the wrapper could be kinda generic..aka provided by bmx ng) it might be also something bmk possibly can provide .../ Build in the binary on request.
So instead of the debugger waiting for input it spits put a defined set of information (similar to the tree maxide spits out in the debug pane).

What do you think? What do you suggest to offer such a thing to your application's users?

[Kerntrick]

Could it be possible for the user(programmer) to have some access over 'bbOnDebugEnterScope' and 'bbOnDebugEnterStm' ?
It would be handy to at least walk/unwind that stack to a file or something in a end-user build.

[GWRon]

I often would like to have a kind of lightweight debug build. Often I would already enjoy knowing "where" something happened. Without details of the variables etc. Once you know where something crashes you could always go deeper with additional debuglog calls etc. But this is only needed as debug builds are so much slower in blitzmax than release builds (because of the way our debugger works).

[GWRon]

@Scaremonger linked to these on discord:

libc has backtraces:
https://www.gnu.org/software/libc/manual/html_node/Backtraces.html
There is also this library:
https://github.com/ianlancetaylor/libbacktrace

Some of us might be OK with having a backtrace based on the bcc generated C-code and it is better than having nothing at all.