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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
