[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Jun 2019 15:57:42 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: helitao <helitao@...wei.com>,
"Huangqiang (H)" <h.huangqiang@...wei.com>,
Jinyongming <jinyongming@...wei.com>,
leijitang <leijitang@...wei.com>,
"liuyutao (C)" <liuyutao2@...wei.com>,
"Liyu (Marvin, Euler Dept)" <marvin.tms@...wei.com>,
"Threefifteen Wang(Kunfeng)" <threefifteen.wangkunfeng@...wei.com>,
"Wudilong (Michael)" <wudilong@...wei.com>
Subject: Re: [proposal] Add detection of thread ID in pthread-related
interfaces
* pengyuanhong <pengyuanhong@...wei.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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
