From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 17BD9BBAF for ; Mon, 4 Jan 2010 15:10:30 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUEAIaFQUtQRFuwgWdsb2JhbACbSQEBFiS2eIQwBA X-IronPort-AV: E=Sophos;i="4.47,498,1257116400"; d="scan'208";a="44142361" Received: from furbychan.cocan.org ([80.68.91.176]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 04 Jan 2010 15:10:29 +0100 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1NRndc-0001IM-8u; Mon, 04 Jan 2010 14:10:28 +0000 Date: Mon, 4 Jan 2010 14:10:28 +0000 To: Guillaume Yziquel Cc: OCaml List Subject: Re: [Caml-list] Dynamically loaded BSS not initialised to 0. Message-ID: <20100104141028.GA3841@annexia.org> References: <4B40815E.3050707@citycable.ch> <4B412680.7090405@citycable.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B412680.7090405@citycable.ch> User-Agent: Mutt/1.5.13 (2006-08-11) From: Richard Jones X-Spam: no; 0.00; bss:01 0100,:01 guillaume:01 guillaume:01 cmxa:01 bss:01 ocaml:01 initialise:01 ocamlrun:01 model:01 drepper:01 ncurses:01 extensively:01 ocaml:01 dlopen:01 On Mon, Jan 04, 2010 at 12:21:36AM +0100, Guillaume Yziquel wrote: > Guillaume Yziquel a écrit : > >Hello. > > > >I encountered a rather weird issue. A binding of mine works fine when > >bundled as a .cmxa, but fails when bundled as a .cma. I'm running a > >Linux Debian amd64. > > > >I've tracked down the issue to the following point: it seems that when > >the BSS (uninitialised data section) of libmonetdb5.so is dynamically > >loaded, it doesn't get initialised to 0. And the code in libmonetdb5.so > >relies on the fact that BSS gets initialised to 0 when dynamically loaded. > > > >So: is ocaml failing to initialise memory to 0 when limonetdb5.so is > >dynamically loaded? > > Problem solved: This is in fact a symbol collision problem on the symbol > 'box'. There's one in libncurses, which is loaded by ocamlrun. Good ol' ELF loading model ... Uli wrote a really good introduction to writing DSOs which everyone should read: http://people.redhat.com/drepper/dsohowto.pdf The issue of symbol scope is covered there too, although I don't think it can help in this case. One or other of the libraries is just going to have to change the visibility of that symbol. In ncurses it's a public symbol, but if I understand the code correctly, in MonetDB it's just an accidentally leaked global variable (not part of the API). So MonetDB could control the visibility of that symbol using a linker script. We use linker scripts extensively in libvirt to control which clients can see which sets of symbols, eg: http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libvirt_public.syms;hb=HEAD http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libvirt_private.syms;hb=HEAD In answer to your original question, initialization of the BSS is the job of the loader (ld-linux.so(8)). OCaml just calls dlopen(3), which calls into some extremely well-tested code, so it was always going to be unlikely that BSS initialization was the problem. Rich. -- Richard Jones Red Hat