This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: A possible libc/dlmopen/pthreads bug
On 24/01/18 17:25, Adhemerval Zanella wrote:
In fact I think Vivek examples of running process with two different libcs
are working mainly because the different glibc define and access the shared
resources in same manner. I bet it will break the moment we change some
state internal layout or semantic (for instance the __stack_user struct size).
even if the two libc has same code and same layout for
internal data structures it is completely broken:
there are two copies of the libc global data section
with inconsistent content.
if printf called twice via different libcs they get
buffered independently, but write to the same fd, so
the observable effect on stdout can be out of order,
fflush on namespace boundary does not help since the
locks of one libc don't work on the other, the writes
can happen concurrently.
setxid has to coordinate with all threads via signals,
even with the ones created by the other libc.
same for atfork handlers: the handlers of the other
libc has to run too.
same of tls/tsd dtors: at thread exit the other libc
tls/tsd data should be freed too.
the dynamic loader + libc + libpthread needs to have
one unique instance or some apis won't work across
all instances.