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