Implement stack traces

[fadushin]

This PR adds support for stacktraces, both in the display of crash reports, as well as programmatic access to stacktrace data as terms in catch clauses.

Stacktrace data is represented as a list of tuples, each of which represents a stack “frame”. Each tuple is of the form:

[{Module :: module(), Function :: atom(), Arity :: non_neg_integer(), AuxData :: aux_data()}]

where aux_data() is a (possibly empty) properties list containing the following elements:

[{file, File :: string(), line, Line :: pos_integer()}]

Stack frames are ordered from the frame “closest“ to the point of failure (the “top” of the stack) to the frame furthest from the point of failure (the “bottom” of the stack).

Stack frames will contain file and line information in the AuxData list if the BEAM files (typically embedded in AVM files) include <<“Line”>> chunks generated by the compiler. Otherwise, the AuxData will be empty.

Note that adding line information to BEAM files not only increases the size of BEAM files in storage, but calculation of file and line information can have a non-negligible impact on memory usage. Memory-sensitive applications should consider not including line information in BEAM files.

Addresses issue #254.

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

[pguyot]

As discussed elsewhere, another approach would be to modify the code loading function (or create a new one) and call it when a stack trace is needed, so that the data structures are not kept with the modules but are only generated on stack trace creation.

[fadushin]

As discussed elsewhere, another approach would be to modify the code loading function (or create a new one) and call it when a stack trace is needed, so that the data structures are not kept with the modules but are only generated on stack trace creation.

Wow, that would be a challenge! I think I would like to treat that as an optimization (future tense) and maybe give this some soak time to flush out any bugs. What do you think?

[pguyot]

As discussed elsewhere, another approach would be to modify the code loading function (or create a new one) and call it when a stack trace is needed, so that the data structures are not kept with the modules but are only generated on stack trace creation.

Wow, that would be a challenge! I think I would like to treat that as an optimization (future tense) and maybe give this some soak time to flush out any bugs. What do you think?

Let's choose the memory optimizations we want. Personally, I'm perfectly fine with the additional memory impact, and I believe larger memory gains can be obtained elsewhere (especially with gc / heaps) and the actual optimization target (or memory constraint) should be known. I'm also pointing that possible optimization as opposed to have strings in binaries vs lists. Let's move forward with stack traces which are a huge benefit, but also let's try to stick to OTP specifications. As a recent user of AtomVM, I found it difficult to not find usual Erlang stuff.

[bettio]

Merged.