Without stack trace, silent crashes are practically intractable.
In my java and python /career/ (I think c# as well) , exceptions always generate a console stack trace. The only time it didn’t happen was a Barclays JNI library written in c++..
In c++, getting the stack trace is harder.
- when I used the ETSFlowAsert() construct I get a barely usable stack trace, with function names, without line numbers
- [[safeC++]] described a technique to generate a simple stack trace with some line numbers but I have never tried it
- the standard assert() macro doesn’t generate stack trace
- In RTS and mvea, memory access errors lead to seg-fault and core dump. In these contexts we are lucky because the runtime environment (host OS, standard library, seg-fault signal handler ..) cooperate to dump some raw data into the core file, but it’s not as reliable as the JVM runtime … Here are some of the obstacles:
- core files may be suppressed
- To actually make out this information, we need gdb + a debug build of the binary with debug symbols.
- it can take half an hour to load the debug symbols
- My blogpost %%first core dump gdb session describes how much trouble and time is involved to see the function names in the stack trace.