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:
>
> cc -o test test.c -lpthread -L/usr/local/lib/gcc5 -lgcc_s -rpath
> /usr/local/lib/gcc5
>
>
> #include
> #include
>
> void *
> thr( void *arg ) {
> return( NULL );
> }
>
> int
> main( void ) {
> pthread_t thread;
>
> for( int i = 1; i < 20; i++ ) {
> fprintf( stderr, "%d\n", i );
> pthread_create( , NULL, thr, NULL );
> pthread_join( thread, NULL );
> }
> return( 0 );
> }
>
>
> The backtrace looks like this:
>
> Thread 7 received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 100511 of process 1886]
> uw_frame_state_for (context=
> context at entry
> =0x7fffdfffddc0,
> fs=
> fs at entry
> =0x7fffdfffdb10)
> 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=
> context at entry
> =0x7fffdfffddc0,
> fs=
> fs at entry
> =0x7fffdfffdb10)
> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249
> #1 0x000800a66ecb in _Unwind_ForcedUnwind_Phase2 (
> exc=
> exc at entry=0x800658730, context=context at entry
> =0x7fffdfffddc0)
> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:155
> #2 0x000800a67200 in _Unwind_ForcedUnwind (exc=0x800658730,
> stop=0x8008428b0 , stop_argument=0x0)
> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:207
> #3 0x000800842224 in _Unwind_ForcedUnwind (ex=0x800658730,
> stop_func=0x8008428b0 , stop_arg=0x0)
> at /usr/src/lib/libthr/thread/thr_exit.c:106
> #4 0x00080084269f in thread_unwind ()
> at /usr/src/lib/libthr/thread/thr_exit.c:172
> #5 0x0008008424d6 in _pthread_exit_mask (status=0x0, mask=0x0)
> at /usr/src/lib/libthr/thread/thr_exit.c:254
> #6 0x000800842359 in _pthread_exit (status=0x0)
> at /usr/src/lib/libthr/thread/thr_exit.c:206
> #7 0x00080082ccb1 in thread_start (curthread=0x800658500)
> at /usr/src/lib/libthr/thread/thr_create.c:289
> #8 0x7fffdfdfe000 in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
>
>
> 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 => /usr/local/lib/gcc7/libstdc++.so.6 (0x800844000)
libm.so.5 => /lib/libm.so.5 (0x800bd8000)
libgcc_s.so.1 => /usr/local/lib/gcc7/libgcc_s.so.1 (0x800e05000)
libthr.so.3 => /lib/libthr.so.3 (0x80101c000)
libc.so.7 => /lib/libc.so.7 (0x801244000)
# ./a.out
. . . (omitted) . . .
Segmentation fault (core dumped)
It was the -Wl,-rpath=/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 .
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
