Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Bus error in 32-bit Snow Leopard OCaml-3.11.2-native-generated program (may be caused by Dynlink) #5012
Original bug ID: 5012
STEPS TO REPRODUCE:
Compile OCaml-3.11.2 as 32-bit on Snow Leopard:
Modify .profile so that usr/local/ocaml-3.11.2-32/bin/ocamlopt is always used (the next steps spawn shells, so just "export PATH=..." in the current shell is not enough)
Download and extract http://frama-c.com/download/frama-c-Beryllium-20090902.tar.gz
nothing happens. This is the expected behavior.
The above is the bug.
Nothing happens (expected behavior) when no plug-in to dynamically load is found
Dynlink works as expected on this platform with 64-bit OCaml 3.11.2.
Reproducing the same behavior under gdb gives:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Comment author: pascal_cuoq
I may have to package the Mac OS X binary distribution for Frama-C Boron with 3.12.0+dev18 then. I am sure this was not the intention behind the public OCaml CVS/SVN, but 64-bit Gtk+ on Mac OS X is simply not ready for prime-time, and not having dynlink is going to become a real show-stopper, what with the tens of plug-ins people are going to develop all over the world.
I cannot imagine a Frama-C user filing a bug report in caml.inria.fr/mantis for the version we distribute, but if you object for whatever reason, I will postpone the Mac OS X binary release until 3.12.0 is official.
Comment author: pascal_cuoq
Damien said: "but can't reproduce with 3.12.0+dev18."
That's because Frama-C's configure detects that dynlink is disfunctional with this compiler, and here is how it detects it:
echo "Dynlink.loadfile "foo";;" > test_dynlink.ml
The change in OCaml's configure that consisted to suppress option '-read_only_relocs suppress' for Mac OS X Snow Leopard is not fine enough: this option seems still to be necessary for 32-bit dynlink on Snow Leopard.
Comment author: @xavierleroy
The problem can be reproduced with very simple C code, attached as "dynlink.tgz". Scenario "b" corresponds to the way Caml builds its .cmxs shared objects.
One sees clearly that the MacOS 10.6 linker, invoked with "-read_only_relocs suppress", silently produces a bundle that is missing relocation information: any reference to an external symbol other than a function call is not relocated.
This is a regression compared with MacOS 10.5's linker, which produces correct relocation info. I really wish Apple would stop tinkering with their linker.
The old linker, ld_classic, produces correct relocations both under 10.5 and 10.6. (Scenario "d" in the test code.) It might be possible to use ld_classic to produce .cmxs files, however we cannot use it to produce other shared libs in Caml (the stub libs for the mixed C-bytecode libraries) because ld_classic is incompatible with some system libraries.
Comment author: Pascal Cuoq
It may not matter to us as much as I initially feared:
The only remaining question for us is whether the X11 solution will remain acceptable at least until 64-bit native gtk+ is ready. MacPorts people have apparently already given up on the system X server and are systematically shipping their own. This means I may have to get used to the idea of shipping an X server in the Mac OS X Frama-C binary release (we do not require users to install MacPorts).
I'm surprised by this choice on Apple's part (what are developers on Snow Leopard who want to produce binaries that work on Leopard supposed to do?) but we can manage. Thanks for the time spent on this very uninteresting issue. I owe you respectively a beer and a glass of non-alcoholic beverage of your choice.
Comment author: @alainfrisch
We have switched to a system where the platforms which support natdynlink are explicitly listed in the configure script. For other platforms, dynlink.cmxa is no longer installer.
The current list of platforms where natdynlink is declared to be supported is:
case "$host" in
Do you think it is safe to add: