This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: A possible libc/dlmopen/pthreads bug
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Vivek Das Mohapatra <vivek at collabora dot com>, libc-help at sourceware dot org
- Cc: nd at arm dot com
- Date: Wed, 24 Jan 2018 16:52:24 +0000
- Subject: Re: A possible libc/dlmopen/pthreads bug
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <alpine.DEB.2.20.1801241345460.22921@noise.cbg.collabora.co.uk>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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.