secp256k1: Segfault running make check with macOS 10.15 SDK (default for Catalina)
This also impacts running the test suite on Bitcoin Core:
% ./autogen.sh
...
% ./configure
...
Build Options:
with endomorphism = no
with ecmult precomp = yes
with external callbacks = no
with jni = no
with benchmarks = yes
with coverage = no
module ecdh = no
module recovery = no
asm = x86_64
bignum = gmp
field = 64bit
scalar = 64bit
ecmult window size = 15
ecmult gen prec. bits = 4
CC = gcc
CFLAGS = -g -O2 -W -std=c89 -pedantic -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -Wno-unused-function -Wno-long-long -Wno-overlength-strings -fvisibility=hidden -O3
CPPFLAGS =
LDFLAGS =
% make
...
% make check
/Applications/Xcode.app/Contents/Developer/usr/bin/make check-TESTS
./build-aux/test-driver: line 107: 70234 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: tests
PASS: exhaustive_tests
============================================================================
Testsuite summary for libsecp256k1 0.1
============================================================================
# TOTAL: 2
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
============================================================================
make[2]: *** [test-suite.log] Error 1
make[1]: *** [check-TESTS] Error 2
make: *** [check-am] Error 2
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 2
- Comments: 28 (18 by maintainers)
I can no longer produce this crash on macOS 10.14 when targeting the 10.15 SDK, using the latest version of XCode (11.2.1). There have been some Apple Clang changes since Xcode 11.1:
11.0.0 (clang-1100.0.33.8)
->11.0.0 (clang-1100.0.33.12)
, so the___chkstk_darwin
issue may have been fixed. Can anyone else confirm?Can any of you retry with
./configure --with-bignum=no
? according to quick googlelibdyld.dylib
is the dynamic linker. and the only dynamic lib here is libgmp, so I’m curious if it’s related. @sjors @fjahrand if that doesn’t help then maybe
./configure --with-asm=no
to make sure this is not the hand written assembly somehowCare to run it through valgrind or something else to get the stack trace?