Date: Wed, 23 Aug 2017 12:35:05 -0700 From: Mark Millard <markmi@dsl-only.net> To: Tijl Coosemans <tijl@FreeBSD.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-ID: <9AD3F17A-1410-44FD-B688-ACFE6AFE38BF@dsl-only.net>
next in thread | raw e-mail | index | archive | help
Tijl Coosemans tijl at FreeBSD.org wrote on Wed Aug 23 14:38:27 UTC 2017 : > The following program segfaults for me on amd64 when linked like this: >=20 > cc -o test test.c -lpthread -L/usr/local/lib/gcc5 -lgcc_s -rpath = /usr/local/lib/gcc5 >=20 > -------------------------------- > #include <pthread.h> > #include <stdio.h> >=20 > void * > thr( void *arg ) { > return( NULL ); > } >=20 > int > main( void ) { > pthread_t thread; >=20 > for( int i =3D 1; i < 20; i++ ) { > fprintf( stderr, "%d\n", i ); > pthread_create( &thread, NULL, thr, NULL ); > pthread_join( thread, NULL ); > } > return( 0 ); > } > -------------------------------- >=20 > The backtrace looks like this: >=20 > Thread 7 received signal SIGSEGV, Segmentation fault. > [Switching to LWP 100511 of process 1886] > uw_frame_state_for (context=3D > context at entry > =3D0x7fffdfffddc0,=20 > fs=3D > fs at entry > =3D0x7fffdfffdb10) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 > 1249 /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c: No such = file or directory. > (gdb) bt > #0 uw_frame_state_for (context=3D > context at entry > =3D0x7fffdfffddc0,=20 > fs=3D > fs at entry > =3D0x7fffdfffdb10) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 > #1 0x0000000800a66ecb in _Unwind_ForcedUnwind_Phase2 ( > exc=3D > exc at entry=3D0x800658730, context=3Dcontext at entry > =3D0x7fffdfffddc0) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:155 > #2 0x0000000800a67200 in _Unwind_ForcedUnwind (exc=3D0x800658730,=20 > stop=3D0x8008428b0 <thread_unwind_stop>, stop_argument=3D0x0) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:207 > #3 0x0000000800842224 in _Unwind_ForcedUnwind (ex=3D0x800658730,=20 > stop_func=3D0x8008428b0 <thread_unwind_stop>, stop_arg=3D0x0) > at /usr/src/lib/libthr/thread/thr_exit.c:106 > #4 0x000000080084269f in thread_unwind () > at /usr/src/lib/libthr/thread/thr_exit.c:172 > #5 0x00000008008424d6 in _pthread_exit_mask (status=3D0x0, mask=3D0x0) > at /usr/src/lib/libthr/thread/thr_exit.c:254 > #6 0x0000000800842359 in _pthread_exit (status=3D0x0) > at /usr/src/lib/libthr/thread/thr_exit.c:206 > #7 0x000000080082ccb1 in thread_start (curthread=3D0x800658500) > at /usr/src/lib/libthr/thread/thr_create.c:289 > #8 0x00007fffdfdfe000 in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 >=20 >=20 > It happens with gcc6 as well, but not with base libgcc_s. > Can anyone reproduce this? Have there been any changes to stack > unwinding recently (last few months)? This example might make a good addition to bugzilla 221288 that has some material from a more complicated example of problems mixing /usr/local/lib/gcc7/libgcc_s.so.1 and pthread. (Threading need not be the only problem context.) Here the source code is nice and short where the C++ example was large enough that I did not bother to submit it and I've not made a smaller example. The bigger C++ example had: # ldd a.out a.out: libstdc++.so.6 =3D> /usr/local/lib/gcc7/libstdc++.so.6 = (0x800844000) libm.so.5 =3D> /lib/libm.so.5 (0x800bd8000) libgcc_s.so.1 =3D> /usr/local/lib/gcc7/libgcc_s.so.1 = (0x800e05000) libthr.so.3 =3D> /lib/libthr.so.3 (0x80101c000) libc.so.7 =3D> /lib/libc.so.7 (0x801244000) # ./a.out . . . (omitted) . . . Segmentation fault (core dumped) It was the -Wl,-rpath=3D/usr/local/lib/gcc7 that forced the gcc7 variant of libgcc_s to be used. Any combination that had /lib/libthr.so.3 mixed with /usr/local/lib/gcc7/libgcc_s.so.1 failed. Any combination that had /lib/libthr.so.3 mixed with /lib/libgcc_s.so.1 worked. Of course /lib/libthr.so.3 was built based on /lib/libgcc_s.so.1 . =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9AD3F17A-1410-44FD-B688-ACFE6AFE38BF>