--- Comment #5 from Mark Millard <> ---
I suspect this mix of infrastructures ties in to
why standard c++ threading fails under the likes
of g++6 compiles while the code works when compiled
and linked via system clang++ 5. The infrastructure
issues may extend to the libgcc_s that is used as

(The program here is just one that I happen to have
around, not minimized, but standard C++ code only.)

Starting without an explicit -pthread :

g++6 -std=c++14 -Wpedantic -Wall -Wl,-rpath=/usr/local/lib/gcc6 -O2

(So no -pthread explicitly.)

Note the lack of both and in
the below. Also the libgcc_s being from gcc6 materials.

# ldd a.out
a.out: => /usr/local/lib/gcc6/ (0x800844000) => /lib/ (0x800bd9000) => /usr/local/lib/gcc6/ (0x800e06000) => /lib/ (0x80101d000)

leads to:

static inline int
__gthread_create (__gthread_t *__threadid, void *(*__func) (void*),
                  void *__args)
  return __gthrw_(pthread_create) (__threadid, NULL, __func, __args);

getting SIGSEGV from pthread_create not having a good address.

With -pthread the a.out produced gets a SIGSEGV in infrustrature.
Showing similar to the above information:

g++6 -std=c++14 -Wpedantic -Wall -pthread -Wl,-rpath=/usr/local/lib/gcc6 -O2

Note the but the lack of in
the below.  Also the libgcc_s being from gcc6 materials.

# ldd a.out
a.out: => /usr/local/lib/gcc6/ (0x800844000) => /lib/ (0x800bd9000) => /usr/local/lib/gcc6/ (0x800e06000) => /lib/ (0x80101d000) => /lib/ (0x801245000)

(run in /usr/local/bin/gdb :)

Thread 11 received signal SIGSEGV, Segmentation fault.
[Switching to LWP 100288 of process 18022]
uw_frame_state_for (context=context@entry=0x7fffdfdfce20,
fs=fs@entry=0x7fffdfdfcb70) at
1249          return MD_FALLBACK_FRAME_STATE_FOR (context, fs);
(gdb) bt
#0  uw_frame_state_for (context=context@entry=0x7fffdfdfce20,
fs=fs@entry=0x7fffdfdfcb70) at
#1  0x0000000800e1602b in _Unwind_ForcedUnwind_Phase2
(exc=exc@entry=0x80069cc30, context=context@entry=0x7fffdfdfce20) at
#2  0x0000000800e16364 in _Unwind_ForcedUnwind (exc=0x80069cc30,
stop=0x801033450 <thread_unwind_stop>, stop_argument=<optimized out>)
#3  0x00000008010332b3 in _Unwind_ForcedUnwind (ex=<optimized out>,
stop_func=0x7fffdfdfc948, stop_arg=0x80069ca00) at
#4  thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172
#5  _pthread_exit_mask (status=<optimized out>, mask=<optimized out>) at
#6  0x00000008010330db in _pthread_exit (status=0x80069ca00) at
#7  0x0000000801025c0d in thread_start (curthread=0x80069ca00) at
#8  0x00007fffdfbfd000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdfdfd000

Note #3 -> #4 goes from:


So: from system libthr to gcc6's libgcc .

System clang++ 5 with -pthread (link fails without it):

clang++ -std=c++14 -Wpedantic -Wall -pthread cpp_clocks_investigation.cpp 

# ldd a.out
a.out: => /usr/lib/ (0x8008a6000) => /lib/ (0x800b72000) => /lib/ (0x800d90000) => /lib/ (0x800fbd000) => /lib/ (0x8011d3000) => /lib/ (0x8013fb000)

This a.out runs to completion just fine.

You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to