[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Potential spiped 1.6.1 release -- please test

On 2020-02-08 13:05, Peter Pentchev wrote:
> Apparently glibc really, really doesn't believe in cancelling a thread
> that has already completed... I'm not really sure what to think about
> that, since, well, the thread hasn't been joined yet, so technically it
> still exists, albeit in a zombie-like state - and a little test program
> of mine shows that even after a thread has exited and pthread_cancel()
> returns ESRCH, a call to pthread_join() will succeed and will provide
> the correct value returned by the thread function. I'm not sure whether
> this is glibc or the Linux kernel or something else - the behavior is
> the same on three systems I've tested it on: [...]
Ok, this is definitely a bug: pthread_cancel is absolutely supposed to
work on threads which have exited but not joined yet.

Can you produce a minimal test case which exhibits this so that it can
be reported upstream (to glibc or Linux kernel folks -- I'm not sure who
but hopefully they can forward to each other if we get it wrong)?

> So I could keep the check for ESRCH as a Debian-specific patch, or you
> could make it conditional on __linux__ or __gnu_linux__ or something
> similar. What do you think?

My general policy with "operating system doesn't do what POSIX says it
should" is to have "#ifdef POSIXFAIL_FOO" in the code and a test as part
of libcperciva/POSIX/posix-cflags.sh which defines that macro on the
appropriate systems (which might just be "anything Linux" for now, but in
the future might depend on the version of glibc).

Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid