bench/nebr_exchange crash on Cygwin/clang

Issue #188 wontfix
Dan Bonachea created an issue

Nightly testing reveals that bench/nebr_exchange reliably crashes on Cygwin-2.10/clang-5.0.1, in debug and opt modes.

Here is a manually obtained crash stack:

#11 0x000000010057cfed in gasneti_defaultSignalHandler (sig=11) at /cygdrive/e/upcnightly/EX-turtle-smp-clang-pshm/runtime/src/gasnet/gasnet_internal.c:710
#12 0x000000018005e56b in _cygtls::call_signal_handler (this=0xffffce00) at /usr/src/debug/cygwin-2.10.0-1/winsup/cygwin/exceptions.cc:1811
#13 0x000000018012132d in sig_send (p=<optimized out>, p@entry=0x0, si=..., tls=tls@entry=0xffffce00) at /usr/src/debug/cygwin-2.10.0-1/winsup/cygwin/sigproc.cc:736
#14 0x000000018005d291 in exception::handle (e=0xffffb5b0, frame=<optimized out>, in=0xffffb0c0, dispatch=<optimized out>) at /usr/src/debug/cygwin-2.10.0-1/winsup/cygwin/exceptions.cc:832
#15 0x000000007788bf7d in ntdll!.chkstk () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#16 0x000000007786043a in ntdll!RtlInitializeResource () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#17 0x000000007788b61e in ntdll!KiUserExceptionDispatcher () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#18 0x000000018015fb10 in logl (x=<optimized out>) at /usr/src/debug/cygwin-2.10.0-1/winsup/cygwin/math/log.def.h:69
#19 0x000000010042349e in std::log (__x=18446744073709551616) at /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/include/c++/cmath:366
#20 0x000000010042315d in std::generate_canonical<double, 53ul, std::mersenne_twister_engine<unsigned long, 64ul, 312ul, 156ul, 31ul, 13043109905998158313ul, 29ul, 6148914691236517205ul, 17ul, 8202884508482404352ul, 37ul, 18444473444759240704ul, 43ul, 6364136223846793005ul> > (__urng=...) at /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/include/c++/bits/random.tcc:3322
#21 0x0000000100423046 in std::__detail::_Adaptor<std::mersenne_twister_engine<unsigned long, 64ul, 312ul, 156ul, 31ul, 13043109905998158313ul, 29ul, 6148914691236517205ul, 17ul, 8202884508482404352ul, 37ul, 18444473444759240704ul, 43ul, 6364136223846793005ul>, double>::operator() (this=0xffffb960) at /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/include/c++/bits/random.h:183
#22 0x0000000100422e86 in std::normal_distribution<double>::operator()<std::mersenne_twister_engine<unsigned long, 64ul, 312ul, 156ul, 31ul, 13043109905998158313ul, 29ul, 6148914691236517205ul, 17ul, 8202884508482404352ul, 37ul, 18444473444759240704ul, 43ul, 6364136223846793005ul> > (this=0xffffba70, __urng=..., __param=...) at /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/include/c++/bits/random.tcc:1800
#23 0x0000000100417c67 in std::normal_distribution<double>::operator()<std::mersenne_twister_engine<unsigned long, 64ul, 312ul, 156ul, 31ul, 13043109905998158313ul, 29ul, 6148914691236517205ul, 17ul, 8202884508482404352ul, 37ul, 18444473444759240704ul, 43ul, 6364136223846793005ul> > (this=0xffffba70, __urng=...) at /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/include/c++/bits/random.h:2031
#24 0x0000000100401852 in make_mesh_local (buf_size=1024, nebr_n=10) at /cygdrive/e/upcnightly/EX-turtle-smp-clang-pshm/runtime/work/dbg/upcxx/bench/nebr_exchange.cpp:93
#25 0x0000000100403953 in main () at /cygdrive/e/upcnightly/EX-turtle-smp-clang-pshm/runtime/work/dbg/upcxx/bench/nebr_exchange.cpp:376

Poking around in an attached debugger, it appears std::log(long double) is crashing trying to call __builtin_logl() on the 80-bit long double with representation {0x8000000000000000, 0x403f} (the high bits of the second word are padding). This should correspond to 2^64, and gdb seems to agree, as does the normal extended-precision IEEE encoding.

I can't explain why the __builtin_logl() operation is crashing, but it's entirely possible this clang package (which is suspicious for other unrelated reasons) doesn't agree with libstdc++ on the representation of long double. FWIW here is the exception apparently thrown, from stack frame 14: {ExceptionCode = 3221225477, ExceptionFlags = 0, ExceptionRecord = 0x0, ExceptionAddress = 0x18015fb10 <logl+496>, NumberParameters = 2, ExceptionInformation = {1, 4300972144, 0 <repeats 13 times>}}

Comments (1)

  1. Dan Bonachea reporter

    This looks very likely to be a platform bug that has nothing to do with our code.

    Also, it's not an officially supported platform

  2. Log in to comment