Bug#627132: New "-custom" binary generation breaks stack backtraces
Package: ocaml
Version: 3.12.0-5
Severity: normal
It appears that the new "-output-obj" style strategy for generating
-custom bytecode executables
(cf. patches/0011-Embed-bytecode-in-C-object-when-using-custom.patch)
has broken the normal usage of stack backtraces in such executables.
We have a large OCaml application that links with a number of
native-code libraries; we use native-code compilation for most
purposes, but also use byte compilation specifically to support
debugging. In particular we run with OCAMLRUNPARAM=b to get stack
backtraces from uncaught OCaml exceptions.
When I upgraded to the latest Debian OCaml packages, this stopped
working. Now when I try to run a ELF-wrapper-around-bytecode
executable with the environment variable OCAMLRUNPARAM=b to debug an
exception, I see the error message
(Program not linked with -g, cannot print stack backtrace)
even though I did, in fact, compile the program with "-g". It appears
this is because read_debug_info() is searching for debugging
information in the executable and not finding it.
After looking through the OCaml source code, I found that a
combination of undocumented features can be used to provide an
inconvenient workaround to this problem. The relevant debugging
information is being created at link time, but it appears that it is
stored in a file with an unpredictable name in /tmp, with the
extension .cds. Though the file names like "/tmp/camlobjfe90df.cds"
sound like temporary files that would be deleted at the end of
compilation, they are not deleted; I currently have more than 100 such
files (taking more than 250MB) in /tmp. If I supply the undocumented
CAML_DEBUG_FILE environment variable at runtime, pointing to the
correct .cds file, then backtraces work again. However I don't see any
proper way to find the correct filename; hacky things that work
include running ocamlc under "strace -eopen" and looking for the most
recent .cds file in /tmp.
The "strip"ping problem that appeared to motivate the new embedding
process had never bothered us, so another suitable workaround from our
perspective would be if there was a way to disable the
new "-output-obj"-style behavior.
-- Stephen
Reply to: