Re: A possible libc/dlmopen/pthreads bug

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

On 24/01/18 13:59, Vivek Das Mohapatra wrote:
> Apologies for the exegesis: It seems to me that the copy of libc in the
> private namespace has somehow managed to scribble on the linked list
> pointed to by __stack_user, overwriting a key address.
> 
> Is my analysis correct? Is there something I could or should have done to
> avoid this?
> 
> A while ago (https://sourceware.org/ml/libc-help/2018-01/msg00002.html)
> I suggested a dlmopen flag RTLD_UNIQUE or similar which would cause the
> existing mapping of the target library in the main namespace/link-map to be
> re-used instead of creating a new one: I believe this would prevent this
> problem (and others detailed in that message) from occurring - any thoughts?

i don't know what you are doing, but it's hard to imagine
that two libcs (or libpthreads) would work in the same
process: if they can run code on the same thread they
cannot both control the tcb (and will clobber each other's
global state through that).

same for signal handlers (for internal signals) or
brk syscall, or stdio buffering, etc. the libc has to
deal with process global/thread local state that must
be controlled by the same code consistently otherwise
bad things happen.