Re: [Caml-list] Segmentation fault at process initialization

[Alessandro Baretta <alex@baretta.com>]

First of all thanks to Pierre and Stefano et al. for the 
time you have take to read my post and answer me. I wish to 
comment on all your replies and have taken Pierre's as an 
example. This is a fairly long post: it will explain where I 
have localized the bug to be and how I solved the problem. 
Hopefully, it will be interesting to some.

Pierre Weis wrote:
> Hi Alex,
> 
> 
>>Richard Jones wrote:
>>
>>>Obviously under no circumstances, but I've had it happen a few times.
>>
>>Not really. Ocaml programs are guaranteed to be segmetation fault free 
>>only unless they link to C code or use the Marshal module to input data 
>>structures.
> 
> 
> Or you use the Obj module, or you do a stack overflow on some
> architectures, or you access out of a string or array on some others.

Well, ok, I was just mentioning a couple of non-type-safe 
spots. There are a couple more.

> Anyhow, if it is possible, try to compile your code with the bytecode
> compiler and use the debugger that easily find this kind of problems.

I only use bytecode because all my software strongly depends 
on the Dynlink library. And, no, I'm not able to get any 
useful messages out of ocamldebug because the segmentation 
fault apparently occurs during the initialization of the 
virtual machine included in the bytecode executable via 
custom-mode compilation.

> Another simple way to localize the problem is to add a message at the
> end of each compilation unit; for instance, as last line of the
> implementation file foo.ml of module Foo, just write:

None of my debugging fprintfs get executed.

> prerr_endline "Module Foo successfully initialized.";;
> 
> This way, you could normally see which module fails to initialized and
> then you could find more easily why.

Unluckily, it did not help, but I did manage to solve the 
problem, and I want to share my experience with all the 
gurus out there because I am interested in knowing if anyone 
experienced the same issues. Here's my original setup: my 
code depends on a number of libraries which are distributed 
with a findlib-savvy Makefile, as well as a number of other 
libraries which I have written. My own libraries are also 
findlib-savvy, but one is not obliged to install them so 
long as they are in a well defined position within the 
source code tree. I use gnu-make and a number of makefiles, 
including Markus' OcamlMakefile, to automate the compilation 
process. The compilation process itself takes advantage of 
ocamlfind to access the findlib packages. All this is very 
straightforward.

The very strange behavior I observed originally is that the 
bytecode executable would segfault immediately upon process 
initialization if the executable was built from the root 
directory of my source code (therby bypassing ocamlfind as 
far my own libraries were concerned), but ran fine if the 
same executable was build in its own leaf directory, where 
my libraries are accessible only through ocamlfind.

This is the crucial point: the same ocaml code crashes with 
a segfault if it is compiled from the root directory and 
runs perfectly if the compilation and linking are performed 
in the leaf directory with the avail of ocamlfind.

Obviously, there is some bug with the linker: and not so 
much the caml linker as the C linker which generates the 
custom runtime environment. Apparently, gcc's linker is very 
  sensitive to the options it is passed (-L and -I maybe?): 
depending on the relative order of the options, as generated 
by the two different makefile setups, the C linker would 
generate a functional or a buggy custom runtime.

The solution I found: I excluded all findlib and makefile 
magic from the linking process of the executable. The 
linking command has been hard-wired into the Makefile. No 
spurious -ccopt are passed to the linker. No, I no longer 
get any crash, let alone segfaults. It's not ideal because 
it doesn't scale well with code complexity. I'd prefer to 
continue using my makefile-magic, but I'm happy to see my 
Xcaml system back to work.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners