Possible pthreads race bug on macOS Sierra

cancel.c

/*
for i in `seq 100000`; do ./a.out $i ; done && echo ' All is well!'
*/
#include <assert.h>
#include <unistd.h>
#include <stdio.h>
#include <pthread.h>

void *interp(void *param) {
    (void)param;

    char ch;
    while (read(0, &ch, sizeof ch) > 0)
        ;

    puts("Should never be reached");

    return NULL;
}

int main(int argc, char *argv[]) {
    int ret;
    pthread_t pthread;
    ret = pthread_create(&pthread, NULL, interp, NULL);
    assert(ret == 0);


    ret = pthread_cancel(pthread);
    assert(ret == 0);
    ret = pthread_join(pthread, NULL);
    assert(ret == 0);

    printf("\r%s", argv[argc-1]);

    return 0;
}

Compile the code and run for i in `seq 100000`; do ./a.out $i ; done && echo ' All is well!'.

After a short while (Usually before reaching 1000), the command will hang.

LLDB inspection shows that the thread is blocking on read as expected. If the user call pthread_cancel(pthread) manually on main's frame, the thread is cancelled.

So it seems, there's a race between pthread_create and pthread_cancel, which leads to the cancellation request to be lost. Inspection of the libc source didn't show any problems however. Maybe the issue is with the pthread trampoline? Regardless, this violates POSIX, as a pthread_t handle ought to be usable as soon as pthread_create returns.

The expected behavior, seen on other Unices, e.g. Linux is the command terminating at 100000 All is well!.