Re: [proposal] Add detection of thread ID in pthread-related interfaces

[Szabolcs Nagy <nsz@port70.net>]

* pengyuanhong <pengyuanhong@huawei.com> [2019-06-11 11:36:59 +0000]:
> I find that all pthread-related interfaces directly access the input
> parameter `pthread_t` without any check. If I pass an invalid thread ID
> (e.g. an exited thread ID) to these interfaces, then segment fault
> happens.
> 
> Both glibc and freebsd can do simple detection of thread ID(pthread_t)
> passed by user and return ESRCH when no thread can be found. They

that's a historical bug in posix: it required ESRCH
which is not possible when the thread id is reused,
so all such requirments were removed in posix 2008
https://collaboration.opengroup.org/austin/interps/documents/14366/AI-142.txt

passing invalid id is simply undefined now, an
implementation may still detect the condition and
then posix recommends ESRCH in the rationale
presumably for backward compatibility:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_join.html

but since applications must not rely on ESRCH,
it has questionable value: the obvious safe and
secure handling of ub is guaranteed immediate
crash: the api contract got violated, the
application is misbehaving so there is no reason
to believe returning an error will make it
non-misbehave.

the only way forward is to fix the broken
application code, the runtime and tooling can
only help by providing better diagnostics
about what went wrong.

> put all threads in a list or hash table, and update this list or table every
> time a thread is created or exits.
> 
> >From the user's point of view, segment fault is unbearable and is not
> *         recoverable in most cases. Instead, returning an error of ESRCH
> *         seems more acceptable.