freebsd13+clang+openmp bug in dlpolyselect
Job #1919713 failed for ff1dcfe9:
This seemingly happens only on freebsd 13.0, and might lead to sporadic failures. The fact that it failed for full_p30_JL is just because full_p30_JL uses dlpolyselect
many times, and it seems that the failure probability is in the whereabouts of 1 in 50, which doesn't make it trivial to reproduce.
Commit 7c646142 is sweeping things under the rug, but I'm still hesitant as to whether this kind of thing could be worth investigating. It might be a bug that we can hardly do anything about, but it could as well be our fault.
To reproduce (assuming you have all sorts of things installed, such as docker, kvm, and such, and that you're in the proper unix group):
git clone git@gitlab.inria.fr:cado-nfs/cado-nfs
cd cado-nfs
git submodule update --init --remote --recursive
make -C /tmp/cado-nfs/ci/utilities/tanker/
ci/debug.sh "checks on freebsd13.0 system with clang"
# (takes a few minutes!)
export CC=clang CXX=clang++ CFLAGS="-O0 -g -W -Wall -std=c11" CXXFLAGS="-O0 -g -W -Wall -std=c++11"
export force_build_tree=/tmp/build
eval $(gmake show)
gmake cmake
gmake -j2 dlpolyselect
while gdb -ex r -ex q --args $build_tree/polyselect/dlpolyselect -N 701173953068971112417987441927 -easySM 350586976534485556208993720963 -df 3 -dg 2 -area 367001600.0 -Bf 2048.0 -Bg 4096.0 -bound 3 -modm 5 -modr 0 -t 2 ; do : ; done
(getting out of this crazy loop is a bit tricky, but from gdb you can do do shell mv (path to dlpolyselect) (path to dlpolyselect).moved
)
I've tried a few things that could help alleviate the problem, but at the moment none worked. Well, taking out the schedule(dynamic) in the main for loop does, but that isn't a satisfactory answer.