On Thursday 12 December 2024 00:33:28 Brasilia Standard Time Jeremy Rifkin via
Std-Proposals wrote:
> I was able to get it to segfault a couple times. So, there does seem to be
> something here but it does not seem to be a standards issue.

So could I. It took 15 minutes running to get to one, but I did get a crash.

Program terminated with signal SIGSEGV, Segmentation fault.
#0 ___pthread_detach (th=140624175019712) at pthread_detach.c:48

https://codebrowser.dev/glibc/glibc/nptl/pthread_detach.c.html#48

   0x00007fe5af499490 <+18>: lock cmpxchg %rdi,0x620(%rdi)
   0x00007fe5af499499 <+27>: jne 0x7fe5af4994c6
=> 0x00007fe5af49949b <+29>: testb $0x10,0x308(%rdi)

Given we executed that cmpxchg on %rdi+0x620, %rdi was valid on function
entry, but has become invalid between those two instructions.

There's indeed another thread which GDB identifies as having this pthread_t id,
that is exiting and is in madvise()
(gdb) bt
#0 0x00007fe5af518c8b in __GI_madvise () at ../sysdeps/unix/syscall-
template.S:117
#1 0x00007fe5af49840a in advise_stack_range (mem=0x7fe56d7fb000,
size=8392704, pd=140623369713344, guardsize=<optimized out>)
    at /usr/src/debug/glibc-2.40/nptl/allocatestack.c:194
#2 start_thread (arg=<optimized out>) at pthread_create.c:553

The value of pd matches this pthread_detach.

I don't think the race is with the madvise(), unless we have a kernel bug.
    __madvise (mem, freesize - PTHREAD_STACK_MIN, MADV_DONTNEED);

MADV_DONTNEED says a new access will be successful and the addresses it
advised on are nowhere near the crashing address.

There may be a three-way race instead because the TCBs are reused.

Anyway, Phil needs to file a bug.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering