[Bug dynamic-link/18684] dlmopen a DSO that dlopen's into RTLD_GLOBAL segfaults.

["glibc at v dot ewheeler.net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18684

--- Comment #3 from Eric Wheeler <glibc at v dot ewheeler.net> ---
Created attachment 13661
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13661&action=edit
1-line patch plus comments originally written by Carlos O'Donell


Here is a summary of related comments from Michael Kerrisk from here:
  https://sourceware.org/legacy-ml/libc-alpha/2015-07/msg00628.html

---------------------------------------------------------------------

[...]

This is precisely the use case the Solaris dlmopen() does support:
isolation of load namespaces, while allowing DSOs inside a namespace
to share symbols via RTLD_GLOBAL.
> 
> This trick fails for the same reason that calling dlmopen
> with RTLD_GLOBAL would fail if you removed the check in dlfcn/dmlopen.c
> (dlmopen_doit). When you go to add the DSO to the global
> search list you find there is no search list setup. In the case of
> the application we have rtld setup the global search list.
> 
> Which begs the question? What should the global search list
> be for a new namespace? I propose that the global search
> list for a new namespace should be a copy of the symbol search
> list (scope) of the first DSO loaded into the namespace with
> RTLD_GLOBAL, and subsequent RTLD_GLOBAL loads into the namespace
> add to that list.

The above is what Solaris appears to provide.

[...]

One other deviation that I note from Solaris. The dlopen() man page
currently says:

       If filename is NULL, then the returned handle is  for
       the  main  program.

And this is what glibc currently does *regardless* of the namespace
from which the dlopen(NULL, flags) call is made. But, in the context
of dlmopen(LM_ID_NEWLM) namespaces, I'd expect this call to return 
something like "the root of the this namespace". And that is what
Solaris appears to do.

[...]

The dlmopen() seems to have been added to Solaris to support
precisely the use cases that Carlos describes, and the glibc
implementation doesn't support those cases at all.

-- 
You are receiving this mail because:
You are on the CC list for the bug.