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 WAA28704; Mon, 22 Sep 2003 22:57:14 +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 WAA28063 for ; Mon, 22 Sep 2003 22:57:13 +0200 (MET DST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h8MKvCH21048 for ; Mon, 22 Sep 2003 22:57:12 +0200 (MET DST) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1A1Xk8-0004Lp-00; Mon, 22 Sep 2003 22:57:12 +0200 Received: from [80.129.102.51] (helo=gate.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1A1Xk7-00071o-00; Mon, 22 Sep 2003 22:57:11 +0200 Received: from ice.gerd-stolpmann.de (ice.gerd-stolpmann.de [192.168.0.13]) by gate.gerd-stolpmann.de (Postfix) with ESMTP id 4C7FB56F1; Mon, 22 Sep 2003 22:57:11 +0200 (CEST) Received: by ice.gerd-stolpmann.de (Postfix, from userid 1000) id 6CFB8B031; Mon, 22 Sep 2003 22:57:10 +0200 (CEST) Subject: Re: [Caml-list] Segmentation fault at process initialization From: Gerd Stolpmann To: Alessandro Baretta Cc: caml-list@inria.fr In-Reply-To: <3F6F2CB3.9080108@baretta.com> References: <200309181344.PAA12993@pauillac.inria.fr> <3F6F2CB3.9080108@baretta.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1064264229.961.28.camel@ice.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Sep 2003 22:57:09 +0200 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 gerd:01 stolpmann:01 alessandro:01 baretta:01 markus':01 ocamlfind:01 findlib:01 segfault:01 bypassing:01 ocamlfind:01 crashes:01 segfault:01 bug:01 runtime:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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