From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA16927; Mon, 22 Sep 2003 19:05:49 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA04531 for ; Mon, 22 Sep 2003 19:05:48 +0200 (MET DST) Received: from athlon.baretta.com ([213.255.109.130]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h8MH5kH01706; Mon, 22 Sep 2003 19:05:46 +0200 (MET DST) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id E41897DB4; Mon, 22 Sep 2003 13:09:07 -0400 (EDT) Message-ID: <3F6F2CB3.9080108@baretta.com> Date: Mon, 22 Sep 2003 19:09:07 +0200 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: it, en MIME-Version: 1.0 To: Pierre Weis Cc: caml-list@inria.fr, Stefano Zacchiroli , damien Doligez Subject: Re: [Caml-list] Segmentation fault at process initialization References: <200309181344.PAA12993@pauillac.inria.fr> In-Reply-To: <200309181344.PAA12993@pauillac.inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; alessandro:01 baretta:01 baretta:01 caml-list:01 pierre:01 pierre's:01 bug:01 pierre:01 weis:01 debugger:01 dynlink:01 ocamldebug:01 foo:01 foo:01 debugging:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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