Hi Ken, Victor, On Jan 13, 2016, at 3:25 PM, Kenneth Hoste <[email protected]> wrote: > According to our findings, "ulimit -v" must be set to 'unlimited', while > "ulimit -s" must be set to something else than 'unlimited' for the tests to > work. > There may be more going on though, since that's exactly what you have > according to your debug log. > Maybe the stack size limit should be higher? Not sure…
I’ve seen this issue before. I hadn’t debugged it fully, but it appeared to relate to glibc-2.12 of RHEL6 and friends (hello Centos6, hello SL6); AFAIK, the issue goes away with glibc 2.13 and anything greater. If I recall the story right, clang v3.4 and above will fail the sanitiser test, because they are picky for a situation that can indeed imply a race condition (if true, well done! :) - can someone else confirm this? btw. try to install either of clang/3.3 and clang/3.4 to verify the above statement, across glibc cases. > Ward has issued a PR to add a new option to hard disable only the sanitizer > checks, see https://github.com/hpcugent/easybuild-easyblocks/pull/806. > That should go in very soon, and so will be part of the next release > (EasyBuild v2.6.0). Nice to have that as a tuneable. > With that in place, adding "skip_sanitizer_tests = True" will be sufficient > to dance around this issue, as opposed to having to skip *all* tests and > disable bootstrapping, as I mentioned earlier. > We should consider having that enabled by default to skip these troublesome > tests... Ward? I’m inclined to agree, however it’s good to have a better understanding if that introduces an “unsafe" situation. Basically, if behaviour is the same like it used to be with clang/3.3, it may be OK to disable as default even if imperfect; but if the v3.4 sanitiser checks are more strict for a strong reason (race conditions looming ahead), I’d be more skeptical... more input needed. Fotis -- echo "sysadmin know better bash than english" | sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum
