Closed testock closed 4 years ago
Does your program work as expected if you compile with --no-optimize-format-calls?
No, it also fails. (I'm using a different test program now) format_test.m.txt
Without --no-optimize-format-calls::
MacBook-Pro-2% mmc --make format_test Making Mercury/int3s/format_test.int3 Making Mercury/ints/format_test.int Making Mercury/cs/format_test.c Making Mercury/os/format_test.o Making format_test MacBook-Pro-2% ./format_test Try to print s("test"): test Try to print s("4"): 4 Try to print i(4): Mercury runtime: caught segmentation violation This may have been caused by a stack overflow, due to unbounded recursion. exiting from signal handler zsh: segmentation fault ./format_test
With --no-optimize-format-calls:
MacBook-Pro-2% rm -r Mercury format_test format_test.mh format_test.err MacBook-Pro-2% mmc --make --no-optimize-format-calls -E format_test Making Mercury/int3s/format_test.int3 Making Mercury/ints/format_test.int Making Mercury/cs/format_test.c Making Mercury/os/format_test.o Making format_test MacBook-Pro-2% ./format_test
Mercury runtime: caught segmentation violation This may have been caused by a stack overflow, due to unbounded recursion. exiting from signal handler zsh: segmentation fault ./format_test
`
It looks like you have one of the low-level C grades as your default grade? Which one is it? Also, what C compiler (and version thereof) are you using?
(I've tried the test program with macOS 10.12 using clang 4.2.1 -- clang 9.0.0 in Apples number -- with both the hlc.gc and none.gc grades and it works fine.)
According to the -V output, the grade is hlc.gc. mmc-V.txt I checked usr/local/mercury-20.01/lib/mercury/conf/Mercury.config says: conf.zip
MERCURY_STDLIB_DIR=/usr/local/mercury-20.01/lib/mercury MERCURY_DEFAULT_OPT_LEVEL=-O2 MERCURY_DEFAULT_GRADE=hlc.gc <------ MERCURY_C_COMPILER=gcc MERCURY_C_COMPILER_TYPE=clang_4_2_1 <------ MERCURY_MATH_LIB=-lm MERCURY_JAVA_COMPILER=/usr/bin/javac MERCURY_JAVA_INTERPRETER=/usr/bin/java MERCURY_TARGET_ARCH=x86_64-apple-darwin19.2.0 <-----
I just checked and it looks like the Apple number for clang is 11.0.0 (sorry I didn't put this in my previous remark): MacBook-Pro-2% clang --version Apple clang version 11.0.0 (clang-1100.0.33.8) Target: x86_64-apple-darwin19.4.0 Thread model: posix
It works now. I upgraded XCode and command line tools and rebuilt mercury. Apparently there was a problem with the clang 11.0.0 and stack alignment. Other projects have reported similar issues. Clang 11.0.3 seems to work fine.
Thanks, and apologies for the inconvenience.
Could you please send us a link to someplace that describes those problems with clang 11.0.0? I would like to find out exactly which clang versions are affected, so we can add an entry to Mercury's autoconfiguration to warn users who would be affected.
No problem. Here is the discussion that I found: https://github.com/jedisct1/libsodium/issues/848#issuecomment-540803104
Yesterday when I checked with lldb I got the stack alignment error they describe:
MacBook-Pro-2% lldb format_test (lldb) target create "format_test" Current executable set to '/Users/testock/repositories/p99/tmp/format_test' (x86_64). (lldb) run Process 5959 launched: '/Users/testock/repositories/p99/tmp/format_test' (x86_64) Try to print s("test"): test Try to print s("4"): 4 Process 5959 stopped
libdyld.dylib`_dyld_fast_stub_entry: 0x7fff719d4711 <+0>: pushq %rbp Target 0: (format_test) stopped.
The steps for the fix were as follows:
When compiled with mercury-20.01 to the default grade on MacOS 10.15.4, the following line causes a segfault:
io.format("Successful test: %s has %d solutions\n", [s(Code), i(Solution)], !IO)
...
Successful test: 1 has *** Mercury runtime: caught segmentation violation *** This may have been caused by a stack overflow, due to unbounded recursion. exiting from signal handler zsh: segmentation fault ./count
The problems seems to be caused by the integer processing. I tried the later rotd releases and had the same problem, however, when compiled using the java grade, the program runs as expected. Further, the problem seems to be only with integer and float values. Strings, that is s(X), work fine.