[Bug libstdc++/95989] New: Segmentation fault compiling with static libraries and using jthread::request_stop

[Bug libstdc++/95989] New: Segmentation fault compiling with static libraries and using jthread::request_stop

[webrown.cpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

            Bug ID: 95989
           Summary: Segmentation fault compiling with static libraries and
                    using jthread::request_stop
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: antal.buss at ualberta dot ca
                CC: webrown.cpp at gmail dot com
  Target Milestone: ---
                CC: webrown.cpp at gmail dot com

A simple program creating a jthread and later calling request_stop on the
created thread produces a segmentation fault when the program is compiled
against the static libraries but works fine using dynamic libraries.

--- Comment #1 from Antal Buss <antal.buss at ualberta dot ca> ---
Created attachment 48811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48811&action=edit
Preprocessed file

--- Comment #2 from Antal Buss <antal.buss at ualberta dot ca> ---
Created attachment 48812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48812&action=edit
Compiler output

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 95990 has been marked as a duplicate of this bug. ***

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 95991 has been marked as a duplicate of this bug. ***

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Does -Wl,--whole-archive -lpthread make it work?

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[antal.buss at ualberta dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #6 from Antal Buss <antal.buss at ualberta dot ca> ---
Unfortunately no, I'm compiling with (suggested in stackoverflow):

g++-10 -Wall -Wextra -o test --static -std=c++20 test.cc -lrt -pthread 
-Wl,--whole-archive -lpthread -Wl,--no-whole-archive

but still producing segmentation fault.

Running it through gdb I got:

Thread 1 "test" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) up
#1  0x0000000000402edc in __gthread_self() ()
(gdb) up
#2  0x000000000040314f in std::stop_token::_Stop_state_t::_M_request_stop() ()

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-06-30

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This happens with std::thread too, not just std::jthread.

#include <thread>

int main() {
  std::thread t;
  if (t.get_id() == std::this_thread::get_id())
    throw 1;
  t.join();
}

It looks like the weak pthread_self() symbol is being called.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
pthread_self seems to be defined in libc.a not libpthread.a so using
--whole-archive around -lpthread doesn't help.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

Florian Weimer <fw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at gcc dot gnu.org

--- Comment #9 from Florian Weimer <fw at gcc dot gnu.org> ---
Jonathan and I discussed this off this bug.

The issue is the weak declaration of pthread_self in the libstdc++ headers.

For glibc (at least since 2.1, possibly 2.0), there is no reason to have a weak
declaration because the symbol lives in libc itself, so it is always available
(both with static and dynamic linking). But if the symbol reference is weak and
the symbol is not pulled in for some other reason, then the function is not
linked in even if it is called.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I have a fix for std::this_thread::get_id() but we also need the same fix in
<stop_token> and I'd rather refactor that first to only need to fix it in one
place.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #11 from Florian Weimer <fw at gcc dot gnu.org> ---
It turns out that libc.a did not contain pthread_self until glibc 2.27.  The
symbol was only present in libc.so.6 (as a weird forwarder, for compatibility
with long-defunct LinuxThreads).

This means there could be some fallout from requiring a definition of
pthread_self in the statically linked case, in the form of linking failures
without -lpthread on older glibc (such 2.17, as including in Red Hat Enterprise
Linux 7).

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Antal Buss from comment #1)
> Created attachment 48811 [details]
> Preprocessed file

For convenience, that is:

#include <thread>

int main() {
  auto t = std::jthread([](){});
  t.request_stop();
  return 0;
}


Both this testcase and the one in comment 7 work fine on RHEL 7, so this does
appear to be a regression caused by the changes for
https://sourceware.org/bugzilla/show_bug.cgi?id=22635

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=22635

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm testing this:

diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h
index 965247602ac..0af84a781e5 100644
--- a/libgcc/gthr-posix.h
+++ b/libgcc/gthr-posix.h
@@ -684,7 +684,12 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
 static inline __gthread_t
 __gthread_self (void)
 {
+#if __GLIBC_PREREQ(2, 27)
+  /* See PR libstdc++/95989  */
+  return pthread_self ();
+#else
   return __gthrw_(pthread_self) ();
+#endif
 }

 static inline int
diff --git a/libstdc++-v3/include/std/thread b/libstdc++-v3/include/std/thread
index 0445ab1e319..2772dd3950e 100644
--- a/libstdc++-v3/include/std/thread
+++ b/libstdc++-v3/include/std/thread
@@ -364,13 +364,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
     inline thread::id
     get_id() noexcept
     {
-#ifdef __GLIBC__
+#if defined __GLIBC__ && ! __GLIBC_PREREQ(2, 27)
       // For the GNU C library pthread_self() is usable without linking to
-      // libpthread.so but returns 0, so we cannot use it in single-threaded
-      // programs, because this_thread::get_id() != thread::id{} must be true.
-      // We know that pthread_t is an integral type in the GNU C library.
+      // libpthread, but prior to version 2.27 the version in libc returns 0,
+      // which breaks the invariant this_thread::get_id() != thread::id{}.
+      // We know that pthread_t is a scalar type in the GNU C library,
+      // so just use (__gthread_t)1 as the ID of the main (and only) thread.
       if (!__gthread_active_p())
-       return thread::id(1);
+       return thread::id((__gthread_t)1);
 #endif
       return thread::id(__gthread_self());
     }

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #13)
> I'm testing this:
> 
> diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h
> index 965247602ac..0af84a781e5 100644
> --- a/libgcc/gthr-posix.h
> +++ b/libgcc/gthr-posix.h
> @@ -684,7 +684,12 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
>  static inline __gthread_t
>  __gthread_self (void)
>  {
> +#if __GLIBC_PREREQ(2, 27)

Hmm, maybe we should just check #ifdef __GLIBC__ here, since it's available in
libc even before glibc 2.27 (it returns 0 rather than a real tid before 2.27,
but that's OK).

> +  /* See PR libstdc++/95989  */
> +  return pthread_self ();
> +#else
>    return __gthrw_(pthread_self) ();
> +#endif
>  }
>  
>  static inline int
> diff --git a/libstdc++-v3/include/std/thread
> b/libstdc++-v3/include/std/thread
> index 0445ab1e319..2772dd3950e 100644
> --- a/libstdc++-v3/include/std/thread
> +++ b/libstdc++-v3/include/std/thread
> @@ -364,13 +364,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>      inline thread::id
>      get_id() noexcept
>      {
> -#ifdef __GLIBC__
> +#if defined __GLIBC__ && ! __GLIBC_PREREQ(2, 27)

And maybe we shouldn't change this check either.

If we make it depend on the glibc version then because this function is inline
a program could have two different definitions inlined if different objects
were compiled by different versions of gcc, or against different versions of
glibc. One object could inline the version returning thread::id(1) and another
could inline the version returning thread::id(__gthread_self()). This could
result in two different IDs for the main thread of a single-threaded program.
So maybe we should just stick to returning thread::id(1) for all glibc
versions.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #14)
> > --- a/libgcc/gthr-posix.h
> > +++ b/libgcc/gthr-posix.h
> > @@ -684,7 +684,12 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
> >  static inline __gthread_t
> >  __gthread_self (void)
> >  {
> > +#if __GLIBC_PREREQ(2, 27)
> 
> Hmm, maybe we should just check #ifdef __GLIBC__ here, since it's available
> in libc even before glibc 2.27 (it returns 0 rather than a real tid before
> 2.27, but that's OK).

Except that as Florian said above, it's missing from libc.a prior to 2.27 so if
we used it unconditionally, you wouldn't be able to link statically.

> > --- a/libstdc++-v3/include/std/thread
> > +++ b/libstdc++-v3/include/std/thread
> > @@ -364,13 +364,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >      inline thread::id
> >      get_id() noexcept
> >      {
> > -#ifdef __GLIBC__
> > +#if defined __GLIBC__ && ! __GLIBC_PREREQ(2, 27)
> 
> And maybe we shouldn't change this check either.
> 
> If we make it depend on the glibc version then because this function is
> inline a program could have two different definitions inlined if different
> objects were compiled by different versions of gcc, or against different
> versions of glibc. One object could inline the version returning
> thread::id(1) and another could inline the version returning
> thread::id(__gthread_self()). This could result in two different IDs for the
> main thread of a single-threaded program. So maybe we should just stick to
> returning thread::id(1) for all glibc versions.

I've decided I'm not too concerned about this. There are probably not many
users of std::this_thread::get_id() in programs not linked with -lpthread, and
any such code will have to deal with a change here once all pthreads symbols
move into glibc's libc anyway. When that happens __gthread_active_p will always
be true. Let's just go ahead and use pthread_self() when it's known to work
(i.e. glibc 2.27 and later).

Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558737.html

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:08b4d325711d5c6f68ac29443aba3fd7aa173ac8

commit r11-5183-g08b4d325711d5c6f68ac29443aba3fd7aa173ac8
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Nov 19 21:07:06 2020 +0000

    libstdc++: Avoid calling undefined __gthread_self weak symbol [PR 95989]

    Since glibc 2.27 the pthread_self symbol has been defined in libc rather
    than libpthread. Because we only call pthread_self through a weak alias
    it's possible for statically linked executables to end up without a
    definition of pthread_self. This crashes when trying to call an
    undefined weak symbol.

    We can use the __GLIBC_PREREQ version check to detect the version of
    glibc where pthread_self is no longer in libpthread, and call it
    directly rather than through the weak reference.

    It would be better to check for pthread_self in libc during configure
    instead of hardcoding the __GLIBC_PREREQ check. That would be
    complicated by the fact that prior to glibc 2.27 libc.a didn't have the
    pthread_self symbol, but libc.so.6 did.  The configure checks would need
    to try to link both statically and dynamically, and the result would
    depend on whether the static libc.a happens to be installed during
    configure (which could vary between different systems using the same
    version of glibc). Doing it properly is left for a future date, as that
    will be needed anyway after glibc moves all pthread symbols from
    libpthread to libc. When that happens we should revisit the whole
    approach of using weak symbols for pthread symbols.

    For the purposes of std::this_thread::get_id() we call
    pthread_self() directly when using glibc 2.27 or later. Otherwise, if
    __gthread_active_p() is true then we know the libpthread symbol is
    available so we call that. Otherwise, we are single-threaded and just
    use ((__gthread_t)1) as the thread ID.

    An undesirable consequence of this change is that code compiled prior to
    the change might inline the old definition of this_thread::get_id()
    which always returns (__gthread_t)1 in a program that isn't linked to
    libpthread. Code compiled after the change will use pthread_self() and
    so get a real TID. That could result in the main thread having different
    thread::id values in different translation units. This seems acceptable,
    as there are not expected to be many uses of thread::id in programs
    that aren't linked to libpthread.

    An earlier version of this patch also changed __gthread_self() to use
    __GLIBC_PREREQ(2, 27) and only use the weak symbol for older glibc. Tha
    might still make sense to do, but isn't needed by libstdc++ now.

    libstdc++-v3/ChangeLog:

            PR libstdc++/95989
            * config/os/gnu-linux/os_defines.h (_GLIBCXX_NATIVE_THREAD_ID):
            Define new macro to get reliable thread ID.
            * include/bits/std_thread.h: (this_thread::get_id): Use new
            macro if it's defined.
            * testsuite/30_threads/jthread/95989.cc: New test.
            * testsuite/30_threads/this_thread/95989.cc: New test.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:b11cbbbb74b0e357652a1f1f0d937455310a6389

commit r10-9055-gb11cbbbb74b0e357652a1f1f0d937455310a6389
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Nov 19 21:07:06 2020 +0000

    libstdc++: Avoid calling undefined __gthread_self weak symbol [PR 95989]

    Since glibc 2.27 the pthread_self symbol has been defined in libc rather
    than libpthread. Because we only call pthread_self through a weak alias
    it's possible for statically linked executables to end up without a
    definition of pthread_self. This crashes when trying to call an
    undefined weak symbol.

    We can use the __GLIBC_PREREQ version check to detect the version of
    glibc where pthread_self is no longer in libpthread, and call it
    directly rather than through the weak reference.

    It would be better to check for pthread_self in libc during configure
    instead of hardcoding the __GLIBC_PREREQ check. That would be
    complicated by the fact that prior to glibc 2.27 libc.a didn't have the
    pthread_self symbol, but libc.so.6 did.  The configure checks would need
    to try to link both statically and dynamically, and the result would
    depend on whether the static libc.a happens to be installed during
    configure (which could vary between different systems using the same
    version of glibc). Doing it properly is left for a future date, as that
    will be needed anyway after glibc moves all pthread symbols from
    libpthread to libc. When that happens we should revisit the whole
    approach of using weak symbols for pthread symbols.

    For the purposes of std::this_thread::get_id() we call
    pthread_self() directly when using glibc 2.27 or later. Otherwise, if
    __gthread_active_p() is true then we know the libpthread symbol is
    available so we call that. Otherwise, we are single-threaded and just
    use ((__gthread_t)1) as the thread ID.

    An undesirable consequence of this change is that code compiled prior to
    the change might inline the old definition of this_thread::get_id()
    which always returns (__gthread_t)1 in a program that isn't linked to
    libpthread. Code compiled after the change will use pthread_self() and
    so get a real TID. That could result in the main thread having different
    thread::id values in different translation units. This seems acceptable,
    as there are not expected to be many uses of thread::id in programs
    that aren't linked to libpthread.

    An earlier version of this patch also changed __gthread_self() to use
    __GLIBC_PREREQ(2, 27) and only use the weak symbol for older glibc. Tha
    might still make sense to do, but isn't needed by libstdc++ now.

    libstdc++-v3/ChangeLog:

            PR libstdc++/95989
            * config/os/gnu-linux/os_defines.h (_GLIBCXX_NATIVE_THREAD_ID):
            Define new macro to get reliable thread ID.
            * include/std/stop_token (_Stop_state_t::_M_request_stop):
            Use new macro if it's defined.
            (_Stop_state_t::_M_remove_callback): Likewise.
            * include/std/thread (this_thread::get_id): Likewise.
            * testsuite/30_threads/jthread/95989.cc: New test.
            * testsuite/30_threads/this_thread/95989.cc: New test.

    (cherry picked from commit 08b4d325711d5c6f68ac29443aba3fd7aa173ac8)

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|---                         |10.3
         Resolution|---                         |FIXED

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 10.3

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The test fails on a SPARC64/Linux box with:

GNU C Library (Debian GLIBC 2.32-4) stable release version 2.32.
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 10.3.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.

It looks like we have the same problem with pthread_join now:

Thread 1 "95989" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000105670 in __gthread_join (
    __value_ptr=<error reading variable: dwarf2_find_location_expression:
Corrupted DWARF expression.>, 
    __threadid=<error reading variable: dwarf2_find_location_expression:
Corrupted DWARF expression.>)
    at
/home/ebotcazou/build/sparc64-linux-gnu/libstdc++-v3/include/sparc64-linux-gnu/bits/gthr-default.h:669
#2  std::thread::join (this=0x7fefffff0b0)
    at /home/ebotcazou/src/libstdc++-v3/src/c++11/thread.cc:112
#3  0x0000000000103164 in std::jthread::join (this=0x7fefffff0a8)
    at /home/ebotcazou/install/include/c++/12.0.0/thread:160
#4  0x00000000001030e8 in std::jthread::~jthread (this=0x7fefffff0a8, 
    __in_chrg=<optimized out>)
    at /home/ebotcazou/install/include/c++/12.0.0/thread:130
#5  0x0000000000100d88 in test01 () at 95989.cc:33
#6  0x0000000000100ea8 in main () at 95989.cc:52

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[lightningdzeyenr at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

Jackson Huff <lightningdzeyenr at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lightningdzeyenr at gmail dot com

--- Comment #20 from Jackson Huff <lightningdzeyenr at gmail dot com> ---
Have there been any updates regarding segfaults with pthread_join? I'm also
getting a segfault but with the C++20 jthread::detach() function instead.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jackson Huff from comment #20)
> Have there been any updates regarding segfaults with pthread_join? I'm also
> getting a segfault but with the C++20 jthread::detach() function instead.

There isn't enough context to give a useful answer. It's not clear if your
question is related to this bug report at all, as you're talking about a
different function. You haven't said if you're linking statically or
dynamically, or which OS you're using, or which version of GCC.

There was an update fixing some weak symbol issues for Glibc >= 2.34 (see
r12-5108) and this specific bug is fixed now (the failing test was a different
problem).

I suggest you open a new bug with all the necessary information (see
https://gcc.gnu.org/bugs/ for what's needed) or ask on the gcc-help mailing
list instead.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[lightningdzeyenr at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #22 from Jackson Huff <lightningdzeyenr at gmail dot com> ---
See bug 104852

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Alexandre Oliva <aoliva@gcc.gnu.org>:

https://gcc.gnu.org/g:21edd841611a97442a6b95e8ec7e91ff8fd3a451

commit r13-6461-g21edd841611a97442a6b95e8ec7e91ff8fd3a451
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Fri Mar 3 15:59:36 2023 -0300

    link pthread_join from std::thread ctor

    Like pthread_create, pthread_join may fail to be statically linked in
    absent strong uses, so add to user code strong references to both when
    std::thread objects are created.


    for  libstdc++-v3/ChangeLog

            PR libstdc++/104852
            PR libstdc++/95989
            PR libstdc++/52590
            * include/bits/std_thread.h (thread::_M_thread_deps): New
            static implicitly-inline member function.
            (std::thread template ctor): Pass it to _M_start_thread.
            * src/c++11/thread.cc (thread::_M_start_thread): Name depend
            parameter, force it live on entry.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #24 from Jonathan Wakely <redi at gcc dot gnu.org> ---
>             * testsuite/30_threads/jthread/95989.cc: New test.

This testcase fails on FreeBSD 14:

Starting program:
/home/gcc/build/x86_64-unknown-freebsd14.0/libstdc++-v3/testsuite/95989.exe 
[New LWP 106082 of process 5331]

Thread 2 received signal SIGABRT, Aborted.
Sent by thr_kill() from pid 5331 and user 1001.
[Switching to LWP 106082 of process 5331]
thr_kill () at thr_kill.S:4
warning: 4      thr_kill.S: No such file or directory
(gdb) bt
#0  thr_kill () at thr_kill.S:4
#1  0x000000000042803f in __raise (s=s@entry=6) at
/usr/src/lib/libc/gen/raise.c:50
#2  0x000000000043c779 in abort () at /usr/src/lib/libc/stdlib/abort.c:64
#3  0x0000000000400cbc in uw_init_context_1
(context=context@entry=0x7fffdfffdd50,
outer_cfa=outer_cfa@entry=0x7fffdfffdf80, outer_ra=0x425546 <thread_unwind+54>)
at /mnt/gcc-src/libgcc/unwind-dw2.c:1336
#4  0x00000000004146a6 in _Unwind_ForcedUnwind (exc=0x80082d940, stop=0x4256f0
<thread_unwind_stop>, stop_argument=stop_argument@entry=0x0) at
/mnt/gcc-src/libgcc/unwind.inc:212
#5  0x0000000000425546 in thread_unwind () at
/usr/src/lib/libthr/thread/thr_exit.c:172
#6  0x00000000004254af in _pthread_exit_mask (status=0x0, mask=mask@entry=0x0)
at /usr/src/lib/libthr/thread/thr_exit.c:254
#7  0x000000000042541b in _Tthr_exit (status=0x19e62) at
/usr/src/lib/libthr/thread/thr_exit.c:206
#8  0x0000000000424f2d in thread_start (curthread=0x80082d700) at
/usr/src/lib/libthr/thread/thr_create.c:289
#9  0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
(gdb) fr 3
#3  0x0000000000400cbc in uw_init_context_1
(context=context@entry=0x7fffdfffdd50,
outer_cfa=outer_cfa@entry=0x7fffdfffdf80, outer_ra=0x425546 <thread_unwind+54>)
at /mnt/gcc-src/libgcc/unwind-dw2.c:1336
1336      gcc_assert (code == _URC_NO_REASON);

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989

--- Comment #25 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #24)
> >             * testsuite/30_threads/jthread/95989.cc: New test.
> 
> This testcase fails on FreeBSD 14:

Related PRs there: PR 103444 and PR 82635; it might be the case
MD_FALLBACK_FRAME_STATE_FOR is broken for newer freebsd now too.