New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ocamlopt generates stack invalid for backtrace() #5334
Comments
Comment author: @xavierleroy The man page for backtrace(3) notes: "These functions make some assumptions about how a function's return
ocamlopt-generated stack frames are, in general, quite different from gcc-generated frames. In particular, no frame pointer is ever used by ocamlopt. So, I'm not surprised that backtrace() fails to unravel a Caml stack. Maybe this could be improved by generating .cfi directives in ocamlopt's output, as suggested in #5314, but I have no idea whether backtrace() can exploit this information. When you say "this does not happen on amd64, i386, ...", do you mean that on those platforms, If the answer is (1) and (2) but not (3), maybe this just points to a lack of robustness in the PowerPC implementation of backtrace(), its implementation on other platforms being more robust against nonstandard frames. That might (or not) be improved if |
Comment author: @ygrek I am observing (2) and I think it's libc's problem. $ cat qq.ml module U = ExtUnix.Specific let rec f = function let g a b = let () = let r = g 1 2 in exit r $ ocamlfind ocamlopt -g -linkpkg -package extunix qq.ml -o qq Uncommenting Obj.magic and running in gdb : $ ocamlfind ocamlopt -g -linkpkg -package extunix qq.ml -o qq |
Comment author: @xavierleroy Thanks to "ygrek" for the analysis. It seems that, with the current glibc-PowerPC implementation of backtrace(), the only way to address this issue would be to add frame pointers to the OCaml PowerPC code generator, but this is not going to happen. (It is a design decision of ocamlopt that frame pointers are not maintained: this has a non-negligible cost for small functions, and in a functional language there are many of them.) So, I'll close this PR shortly. There are however two problems with glibc that should probably be reported to them: |
Original bug ID: 5334
Reporter: @glondu
Status: closed (set by @xavierleroy on 2013-08-31T10:43:59Z)
Resolution: won't fix
Priority: normal
Severity: minor
Version: 3.12.0
Category: ~DO NOT USE (was: OCaml general)
Related to: #5314
Monitored by: tgazagna mehdi @ygrek till
Bug description
On a powerpc machine:
$ uname -a
Linux pescetti 2.6.32-5-powerpc #1 Tue Jun 14 09:33:14 UTC 2011 ppc GNU/Linux
$ ocamlopt -config
version: 3.12.0
standard_library_default: /usr/lib/ocaml
standard_library: /usr/lib/ocaml
standard_runtime: /usr/bin/ocamlrun
ccomp_type: cc
bytecomp_c_compiler: gcc -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -fPIC
bytecomp_c_libraries: -lm -ldl -lcurses -lpthread
native_c_compiler: gcc -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT
native_c_libraries: -lm -ldl
native_pack_linker: ld -r -o
ranlib: ranlib
cc_profile: -pg
architecture: power
model: ppc
system: elf
asm: as -u -m ppc
ext_obj: .o
ext_asm: .s
ext_lib: .a
ext_dll: .so
os_type: Unix
default_executable_name: a.out
systhread_supported: true
$ cat backtrace.c
#include <caml/mlvalues.h>
#include <execinfo.h>
value caml_backtrace(value unit) {
void *buffer[100];
return(Val_int(backtrace(buffer, 100)));
}
$ cat main.ml
external backtrace : unit -> int = "caml_backtrace";;
let f () = backtrace () + 1;;
exit (f ());;
$ ocamlopt backtrace.c main.ml && ./a.out; echo $?
zsh: segmentation fault ./a.out
139
$ ocamlc -custom backtrace.c main.ml && ./a.out; echo $?
7
This does not happen on amd64, i386, armel, sparc. It doesn't happen either when calling backtrace() in a pure C program, nor when all CAML{local,return} macros are there, nor when backtrace() in called directly at toplevel in OCaml code. I suspect ocamlopt is faulty here.
The text was updated successfully, but these errors were encountered: