[Caml-list] Segmentation fault at process initialization

[Caml-list] Segmentation fault at process initialization

[Alex Baretta]

When the Xcaml runtime system is linked with the -linkall option of 
ocamlc-3.06, the xcaml executable I get crashes with a segmentation 
fault at process initialization. If, on the other hand, I link the 
executable without the -linkall option, it runs fine, except for the 
fact that it lacks several library modules it should have.

The libraries I'm using are the following:
postgres, which is know to work very well;
cgi, which contains no C code;
and str, num and dynlink coming straight from the ocaml distribution.

My code is definitely not a problem because it runs fine if the -linkall 
option is suppressed. Neither is the -linkall option a problem in and of 
itself, because I can reproduce the behaviour by issuing equivalent 
linking commands using the cmo files as opposed the cmas.

How can I diagnose this segmentation fault? Under what circumstances 
exactly are ocaml programs "allowed" to crash with a segmentation fault?

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

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

[Richard Jones]

On Thu, Sep 18, 2003 at 02:26:25PM +0200, Alex Baretta wrote:
> When the Xcaml runtime system is linked with the -linkall option of 
> ocamlc-3.06, the xcaml executable I get crashes with a segmentation 
> fault at process initialization. If, on the other hand, I link the 
> executable without the -linkall option, it runs fine, except for the 
> fact that it lacks several library modules it should have.
> 
> The libraries I'm using are the following:
> postgres, which is know to work very well;
> cgi, which contains no C code;
> and str, num and dynlink coming straight from the ocaml distribution.
> 
> My code is definitely not a problem because it runs fine if the -linkall 
> option is suppressed. Neither is the -linkall option a problem in and of 
> itself, because I can reproduce the behaviour by issuing equivalent 
> linking commands using the cmo files as opposed the cmas.
> 
> How can I diagnose this segmentation fault? Under what circumstances 
> exactly are ocaml programs "allowed" to crash with a segmentation fault?

Obviously under no circumstances, but I've had it happen a few times.

If it's a native code version, try running it under gdb and look at
the stack trace. You can usually work out from the name which module
was being compiled. It'll be something like Module__entry for the
toplevel code, or Module__function_123 for 'function' in the module.

(You might need to supply the -g option to gcc, ie. ocamlopt -ccopt -g)

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/

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

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

[Alex Baretta]

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. I am actually linking my code with the postgres stub library 
for the libpq, the PostgreSQL client library. But this definitely not 
the problem. I've been using the same version of libmlpostgres and libpq 
for months now with no problems. And I also do some marshalling to and 
from files, but I know this segmentation fault occurs before any files 
are read in for unmarshalling.


> If it's a native code version, try running it under gdb and look at
> the stack trace. You can usually work out from the name which module
> was being compiled. It'll be something like Module__entry for the
> toplevel code, or Module__function_123 for 'function' in the module.
> 
> (You might need to supply the -g option to gcc, ie. ocamlopt -ccopt -g)
> 
> Rich.

Let me point out that it is not ocamlc which crashes, but it is my 
bytecode executable which crashes immediately, before any of my code is 
executed--otherwise I'd get some diagnostic output, which I do not get.

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

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

[Pierre Weis]

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.

[...]

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.

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:

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.

Hope this helps,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


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

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

[Stefano Zacchiroli]

On Thu, Sep 18, 2003 at 03:21:07PM +0200, Alex Baretta wrote:
> >If it's a native code version, try running it under gdb and look at
> >the stack trace. You can usually work out from the name which module
> >was being compiled. It'll be something like Module__entry for the
> >toplevel code, or Module__function_123 for 'function' in the module.
> Let me point out that it is not ocamlc which crashes, but it is my 
> bytecode executable which crashes immediately, before any of my code is 
> executed--otherwise I'd get some diagnostic output, which I do not get.

You were not misunderstood. The suggestion of using gdb is still valid
even if you're running bytecode executables, using gdb backtraces you
will be able to see interesting stuff like external C functions
invocations.

Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney

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

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

[Damien Doligez]

On Thursday, September 18, 2003, at 03:21 PM, Alex Baretta wrote:

> Let me point out that it is not ocamlc which crashes, but it is my 
> bytecode executable which crashes immediately, before any of my code 
> is executed--otherwise I'd get some diagnostic output, which I do not 
> get.

You should use ocamldebug, it will tell you in which library's
initialisation code your program crashes.  With ocamldebug you
can step back, even from a segfault.

-- Damien

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

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

[Alessandro Baretta]

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

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

[Richard Jones]

On Mon, Sep 22, 2003 at 07:09:07PM +0200, Alessandro Baretta wrote:
> 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.

Can you use make in a more verbose mode to find out the exact
difference between the two command lines (the one which links
properly and the one which links badly)?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
C2LIB is a library of basic Perl/STL-like types for C. Vectors, hashes,
trees, string funcs, pool allocator: http://www.annexia.org/freeware/c2lib/

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

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

[Gerd Stolpmann]

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