Open hololeap opened 3 months ago
I did some more testing and it seems some -march
options trigger the segfault, while others do not. The ones I have tested are:
x86-64-v3
znver1
znver2
generic
x86-64
x86-64-v2
I was advised to build with ASAN and UBSAN, which I accomplished by passing these configure flags:
--ghc-option=-optc-fsanitize=address,undefined
--ghc-option=-optl-fsanitize=address,undefined
--ghc-option=-optc-lasan
When run with UBSAN_OPTIONS="print_stacktrace=1"
, the test suite gave this output:
https://gist.github.com/hololeap/232e2adc9b1a44d831ad6d1740874d0e
It was also pointed out that this code likely comes from here and that it hasn't been updated in a long time, so syncing in more recent code would be an easy first step.
Likely related to these, from cryptonite: issue, proposed fix, (and nixpkgs patch).
@hololeap Would you try the proposed fix and send a PR if resolved?
I ran into this when I was compiling for a Gentoo system. The script for gentoo-haskell passes custom flags for GCC as
--ghc-option=-optc-...
configure flags. I isolated the problem flag down to--ghc-option=-optc-march=znver2
, which is passed in because I have-march=znver2
in my systemCFLAGS
.After it compiles successfully, the test suite is run, which is where the segfault occurs. It segfaults immediately after the
crypton.Curve448.KATs.1
test. After some investigation, I managed to get a stack trace:This seems to point to this line, although why this causes a segfault is above my head:
https://github.com/kazu-yamamoto/crypton/blob/crypton-0.34/cbits/decaf/ed448goldilocks/decaf.c#L1199
Full configuration used: