Re: Potential spiped 1.6.1 release -- please test

[Colin Percival <cperciva@tarsnap.com>]

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