[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: updating a shared lib crashes running programs

On Fri, Oct 22, 2004 at 10:04:20AM +0200, Dimitri Tombroff wrote:
> /home/nxuser/pp/lib/
> $ ldd ./bin/http_stack

> I really cannot understand what could go wrong when replacing a library, 
> the running programs are not supposed to reload it.
> Any hint is welcomed ! thanks in advance

Perhaps the issue is 'lazy' link loading...

So, in part it depends on what you are doing.
If you are developing code such that a library has
different interfaces what you are seeing make sense.

Two work around tricks  come to mind... one is to migrate to new library
versions.  If you ever wondered while there are file names like
these.... it has to do with versioning.  Example...


A better one might be to add "now" to the ld command line optins...
In the ld man page...

   now --- When generating an executable or shared library, mark it to
   tell the dynamic linker to resolve all symbols when the program is
   started, or when the shared library is linked to using dlopen,
   instead of deferring function call resolution to the point when the
   function is first called.
Another trick that might be useful is found on the dlopen() man page....

    When RTLD_NOW is specified, or the environment variable
    LD_BIND_NOW is set to a nonempty string, all undefined symbols
    in the library are resolved before dlopen() returns. If this
    cannot be done, an error is returned.  Otherwise binding is
    lazy: symbol values are first resolved when needed.

This last quoted paragraph may be the root of the problem.
If you are changing a library and the dynamic link loader 
gets to the 'new' file on a lazy time frame you could be linking
to a new lib incompat with your old application.

I suspect the environment variable  LD_BIND_NOW  should help

    export  LD_BIND_NOW=true

Once 'ld' has forced the libraries to be loaded then the file and
inode is open and things should be stable.

Should be easy enough to test.... let us know.

	T o m  M i t c h e l l 
	May your cup runneth over with goodness and mercy
	and may your buffers never overflow.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]