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

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Mon, 2003-09-22 um 19.09 schrieb Alessandro Baretta:

> 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.

This can only happen if there is a name conflict on the C symbol level
caused by dynamically loaded libraries, i.e. libraries loaded by the
runtime system with dlopen. In this case there is very little protection
against name clashes, and I guess the runtime system won't find them.

> 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.

This can only be a temporary solution; if you rearrange your code, the
same problem can occur again. Even the order of library initialization
has an impact on which of the conflicting symbols is preferred, because
symbol resolution is usually done lazily (and this is the real _magic_,
there are more powerful wizards out in the world than me).

Normally, the only way to find such errors is to build a statically
linked executable, because in this case the linker complains about name
clashes. It would be interesting if the linker can find your error: try
to create an executable with -custom where all your C libraries are
linked in (also give -linkall). This should result in an error,
independent of the order of the libraries in the linker command.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
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