Created attachment 13940 [details] The .i file When trying to compile a smallish c project on FreeBSD 10.1, clang crashes. Looking at the clang output it appears clang is having problems with a file called entryGetfsstat.c more specifically the line ".syscallNumber = 18,". This should have been removed by me because it's no longer in use and there is no member in that struct named syscallNumber anymore. Removing this line stops clang from crashing. But that should have been a simple compilation error instead of crashing the whole compiler. Below I included some output from clang and what arguments I passed to clang. I also attached the .i file for entryGetfsstat.c that I believe is causing the crash. Here is a link to a coredump for clang if you want/need. https://mega.co.nz/#!Ml0CALAC!G75nLD1j6zj55nggT862sIbIHWlP5X-P19B0jbTbifE If you need anything else let me know, thanks. Here is the struct clang is having trouble with, and just for clarification removing the line ".syscallNumber = 18," stops the crash. struct syscallEntry entryGetfsstat = { .entryNumber = 14, .syscallNumber = 18, .nameOfSyscall = (char *)"getfsstat", .numberOfArgs = 3, .argNameIndex[0] = (char *)"path", .argTypeIndex[0] = ARG_FILE_DESC, .argNameIndex[1] = (char *)"uid", .argTypeIndex[1] = ARG_UID_T, .argNameIndex[2] = (char *)"gid", .argTypeIndex[2] = ARG_GID_T, .callSyscall = &callGetfsstat, .logSyscall = &logGetfsstat, }; Here's what was passed to clang. -DFREEBSD -o systemFuzzer arguments.c context.c fuzzer.c zmalloc.c log.c getTable.c child.c generateArgs.c object.c socketServer.c syscall.c signals.c maps.c systemFuzzer.c utils.c parser.c main.c fuzzers/fuzzTypes.c fuzzers/fuzzDescriptor.c fuzzers/fuzzSocket.c fuzzers/fuzzFlags.c fuzzers/fuzzPointers.c fuzzers/fuzzBuffer.c fuzzers/fuzzFilePaths.c fuzzers/fuzzSignals.c fuzzers/fuzzUtils.c entries/Common/entryRead.c entries/Common/entryWrite.c entries/Common/entryOpen.c entries/Common/entryClose.c entries/Common/entryWait4.c entries/Common/entryLink.c entries/Common/entryUnlink.c entries/Common/entryChdir.c entries/Common/entryFchdir.c entries/Common/entryMknod.c entries/FreeBSD/entryGetfsstat.c /usr/local/lib/libcrypto.a -lpthread -Ientries/FreeBSD/ -Wall -Werror -Weverything -Wno-deprecated-declarations -g -fstack-protector-all -O2 -Wno-newline-eof -Wno-padded -Wno-format-nonliteral -Wno-missing-variable-declarations -Wno-unused-parameter -Wno-pointer-arith And here's some of clangs output. Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-unknown-freebsd10.1 -S -disable-free -disable-llvm-verifier -main-file-name entryGetfsstat.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -gdwarf-2 -resource-dir /usr/bin/../lib/clang/3.4.1 -O2 -Wall -Werror -Weverything -Wno-deprecated-declarations -Wno-newline-eof -Wno-padded -Wno-format-nonliteral -Wno-missing-variable-declarations -Wno-unused-parameter -Wno-pointer-arith -fconst-strings -fdebug-compilation-dir /usr/home/web/systemFuzzer -ferror-limit 19 -fmessage-length 82 -stack-protector 2 -mstackrealign -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o entryGetfsstat.s -x cpp-output entryGetfsstat.i 1. entries/FreeBSD/entryGetfsstat.c:63:2: current parser token ';' clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.1 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: unable to execute command: Segmentation fault (core dumped) clang: note: diagnostic msg: Error generating preprocessed source(s).
On FreeBSD, you are most likely getting an assertion. On OSX, as far as I know, assertions are disabled in the versions of clang delivered with Xcode. I can reproduce this with clang 3.4.1, when compiling your sample, it gives various error messages about mode_t, then asserts with: Assertion failed: (Val && "isa<> used on a null pointer"), function doit, file contrib/llvm/include/llvm/Support/Casting.h, line 97. This assert doesn't fire with clang 3.5.1 or later, so it has been fixed somewhere between those releases. If you have some time, you can try to bisect to figure out where the exact fix happened on trunk.
It turns out this is fixed by r199571: http://llvm.org/viewvc/llvm-project?rev=199571&view=rev I will import this fix into FreeBSD's version of clang 3.4.1 (currently in stable/10 and stable/9).
https://svnweb.freebsd.org/changeset/base/279289