Bugs found while working on global thread list

Bugs found while working on global thread list

[Rich Felker]

1. __dl_thread_cleanup, used to free the thread-local dlerror buffer,
calls free from a context where the thread is no longer in a
consistent state, which is invalid now what free may be defined by the
application. The simplest fix seems to be queuing the buffer to a
global list where it will be seen and freed by some future call to dl
functions; this precludes unbounded (memory leak) growth.

2. dlsym for RTLD_NEXT or RTLD_DEFAULT walks the symbol-defining DSOs
list without holding any lock on it, and the full DSOs list for
addr2dso lookup. This is intentional in some sense, to avoid heavy
overhead, but it seems incorrect and unsafe, as it can cause a
definition which is only temporarily-global (as part of an in-progress
dlopen with RTLD_LOCAL) or not-yet-committed (as part of an
in-progress dlopen that eventually fails) to spuriously return success
for a symbol that should be seen as undefined. I think this may be
salvagable with some atomic sentinels, but it's probably better
(simpler, clearly correct without complex reasoning) to just use a
rwlock. (This issue was found looking at whether dlsym would be a
place to perform deferred free of buffers for #1 above.)

Re: Bugs found while working on global thread list

[Rich Felker]

3. Not exactly a bug, but found looking at cruft/bloat in struct
pthread: the start function pointer and argument are reused in a
hackish way for timer threads. There are actually a lot of ugly hacks
in the whole way SIGEV_THREAD timers are implemented, that could be
eliminated by either waiting for the signal (rather than handling it)
or doing away with use of signals and kernel timers entirely for
SIGEV_THREAD, and instead implementing it all in userspace with
clock_nanosleep.