[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#627132: marked as done (New "-custom" binary generation breaks stack backtraces)

Your message dated Thu, 13 Aug 2015 11:45:16 +0200
with message-id <55CC672C.4020000@debian.org>
and subject line Re: Bug#627132: New "-custom" binary generation breaks stack backtraces
has caused the Debian Bug report #627132,
regarding New "-custom" binary generation breaks stack backtraces
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
627132: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627132
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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

--- End Message ---
--- Begin Message --- 
Le 16/11/2011 08:44, Stéphane Glondu a écrit :
>> So my personal opinion is that the original bug isn't really "fixed",
>> but it's close enough that I think it would be within your
>> maintainer's discretion to declare it so. Or alternatively this feels
>> somewhat like a "help" or "wontfix" situation, though it's not a
>> perfect match for either of those either IMO.
> 
> You're right. I was thinking about sub-bug #627761 when I wrote my mail
> yesterday. This one (#627132) still stands. The buglog from [1] should
> be more clear now :-)

Following #678577, the new -custom behaviour is opt-in. So by default,
stack backtraces with -custom shouldn't be broken any more. This is
documented in /usr/share/doc/ocaml-nox/README.Debian

I won't spend any further time on this bug, hence closing.

Cheers,

-- 
Stéphane

--- End Message ---
Reply to: