C++ Logo

std-proposals

Advanced search

Re: [std-proposals] std::thread::detach() can segfault

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Thu, 12 Dec 2024 19:36:03 +0000
On Thu, 12 Dec 2024 at 18:34, Phil Bouchard via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Yeah thanks. I am able to reproduce it as well with some derived code.
>
> The problem with GNU Bugzilla is all my email addresses are filtered out
> by their SpamAssassin for some reason.
>

What does that mean?


>
> So anybody else is welcome to report this bug otherwise I'll try again
> tonight.
>
>
> Thanks a lot,
>
> --
> [image: Logo] <https://www.fornux.com/>
> *Phil Bouchard* [image: facebook icon]
> <https://www.linkedin.com/in/phil-bouchard-5723a910/>
> 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
> [image: Banner] <https://static.fornux.com/c-superset/>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 Dec 12, 2024, at 8:47 AM, Thiago Macieira via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2024-12-12 19:37:24