A possible libc/dlmopen/pthreads bug

Szabolcs Nagy szabolcs.nagy@arm.com
Wed Jan 24 19:34:00 GMT 2018

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.

More information about the Libc-help mailing list