-- 

Phil Bouchard Founder & CEO T: (819) 328-4743 E: phil_at_[hidden] | www.fornux.com 320-345 de la Gauchetière Ouest | Montréal (Qc), H2Z 0A2 Canada

Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.

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



--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals