Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007771OCamlconfigure and build/installpublic2018-04-13 11:092018-04-26 17:46
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Platformx64OSLinux, macOSOS Version
Product Version4.06.1 
Target VersionFixed in Version 
Summary0007771: ocamldebug and ocamldoc segfault or Failure("input_value: unknown custom block identifier")
DescriptionI have packaged OCaml for conda on the conda-forge channel, [^] [^]

This system compiles binaries on virtual machines (Linux on CircleCI, macOS on TravisCI) and shares the binaries for easy installation, e.g.

conda install -c conda-forge ocaml

Conda supports Windows, macOS and Linux but currently the OCaml package only covers macOS and Linux.

The recipes seem to work, but these commands fail as logged here: [^] [^]
Linux CircleCI,

$ ocamldebug -version
Fatal error: exception Failure("input_value: unknown custom block identifier") [^]
macOS, TravisCI,

$ ocamldebug -version
/Users/travis/miniconda3/conda-bld/ocaml_1523031087918/test_tmp/ line 7: 33648 Segmentation fault: 11 ocamldebug -version [^]
macOS, TravisCI,

$ ocamldoc -version
/Users/travis/miniconda3/conda-bld/ocaml_1523032262217/test_tmp/ line 8: 33653 Segmentation fault: 11 ocamldoc -version

I see this on OCaml 5.06.0, 5.06.1 and also 5.02.0 as well, see: [^]

I strongly suspect that something in the conda build scripts in combination with your build process is breaking, but don't really know where to start.
Steps To ReproduceRun the conda builds from [^]

e.g. You could fork the repository on GitHub, turn on CircleCI and TravisCI for your fork, and push a white space commit to GitHub to trigger the build.
Additional InformationHaving an OCaml developer join or take over the conda recipe would be most welcome.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
gasche (administrator)
2018-04-13 11:37
edited on: 2018-04-13 11:37

The first wild guess would be a version mismatch between the compiler distribution that produced the ocamldebug/ocamldoc executables and the one that is available on the machine trying to run them.

Can you confirm that all the other commands tested in your `test:` recipe ( [^] ) work as expected?

One thing that is special about ocamldoc/ocamldebug is that they remain distributed as bytecode executables by default, while most other OCaml commands (but I'm not sure all of them) give the short name to their native-compiled versions. This suggests that maybe native programs work correctly on your system, but bytecode programs don't. Could you check for example (ocamlc.byte -version) and (ocamlc.opt -version)? If this hypothesis is correct, only the latter should work.

Bytecode-compiled OCaml programs start with a shebang line that indicate the location of the bytecode interpreter (ocamlrun). The path is decided at build time, which is one of the reasons why OCaml programs are not relocatable in practice. Can you lookup the shebang line on your test systems? Is there an ocamlrun program at the right OCaml version in the requested directory? If there is an ocamlrun program at the right version in a *different* directory, does the command

  /path/to/the/right/ocamlrun ocamldebug -version

work correctly?

peterjc (reporter)
2018-04-13 11:43

As to your first guess, these failing tests are on the same VM which did the compiling - although not exactly the same environment as they try to simulate installing the finished package.

Yes, all the simple test commands (using -version or -help) work except these two. That these two commands are special (bytecode only) seems to be important.

I was wondering about the native vs bytecode, and if I could force native only for example.

This hint seems like a very important clue: "Bytecode-compiled OCaml programs start with a shebang line that indicate the location of the bytecode interpreter (ocamlrun)"

I know that the conda build system does make efforts to re-write paths referring to libraries etc so that on the end user's machine they will point at the conda provided libraries and not the system libraries. That may need to be triggered here explicitly.

I will explore the hashbang line, and try explicitly invoking them via ocamlrun, and get back to you.

Thank you!
peterjc (reporter)
2018-04-13 12:14

Debugging this here: [^]

I'm pretty sure that the hashbang lines are correct, both at the point of the test on TravisCI/CircleCI, and once installed on an end user's system:

Confirming the hashbangs look fine with an actual installation of the ocaml v5.06.0 package under Conda on Linux:

$ which ocamldebug
$ which ocamldoc
$ head -n 1 `which ocamldebug`
$ head -n 1 `which ocamldoc`
On this Linux system those tools seg-fault:

$ ocamlrun -version
The OCaml runtime, version 4.06.0
$ ocamldoc -version
Segmentation fault (core dumped)
$ ocamldebug -version
Segmentation fault (core dumped)
They also fail this way:

$ ocamlrun `which ocamldebug` -version
Segmentation fault (core dumped)
$ ocamlrun `which ocamldoc` -version
Segmentation fault (core dumped)
gasche (administrator)
2018-04-13 14:40


  ocamldoc.opt -version

work well on the system?
peterjc (reporter)
2018-04-13 15:12

Yes, "ocamldoc.opt -version" works on Linux / CircleIO, macOS / TravisCI, and on our local Linux system where I installed the conda package: [^]

This is consistent with the native binaries (*.opt) working but there being a problem with the bytecode versions.

Might this be the problem, quoting your INSTALL file:

> 9- After installation, do *not* strip the ocamldebug and ocamlbrowser
> executables. (These are mixed-mode executables, containing both
> compiled C code and OCaml bytecode; stripping erases the bytecode!)
> Other executables such as ocamlrun can safely be stripped.

Is there any easy check? e.g. On the Linux system where the package is installed:

$ file `which ocamlc.opt`
/mnt/shared/scratch/xxx/apps/conda/bin/ocamlc.opt: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=2be5e1b8c3665ef9470115ba2b9ae02cc27da238, not stripped

$ file `which ocamlc.byte`
/mnt/shared/scratch/xxx/apps/conda/bin/ocamlc.byte: data

$ ocamlc.opt -version
$ ocamlc.byte -version
(no output)

Is the file output then a sign of a problem with the byte binaries?
peterjc (reporter)
2018-04-26 17:46

Any other suggestions for debugging the byte binaries?

I have checked their hashbang, but is there anything to dump the rest of the file?

The following is from a Linux machine with the current (problematic) conda package installed,

$ strings `which ocamlc.byte` | head -n 1

$ strings `which ocamlc.byte` | grep feedstock | head

Are these traces of the file system used to compile the code likely to be a problem? (The term "feedstock" is part of the vocabulary used by the conda-forge build system)

- Issue History
Date Modified Username Field Change
2018-04-13 11:09 peterjc New Issue
2018-04-13 11:37 gasche Note Added: 0019017
2018-04-13 11:37 gasche Note Edited: 0019017 View Revisions
2018-04-13 11:43 peterjc Note Added: 0019018
2018-04-13 12:14 peterjc Note Added: 0019019
2018-04-13 14:40 gasche Note Added: 0019023
2018-04-13 15:12 peterjc Note Added: 0019024
2018-04-26 17:46 peterjc Note Added: 0019064

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker