Re: clang on 12-CURRENT traps on its internal assertion when build kernel under nanobsd.sh control

On 22 Jun 2018, at 16:18, Lev Serebryakov <lev_at_FreeBSD.org> wrote:
> 
> I tripped over very strange, but repeateable (in my conditions) bug in
> clang on 12-CURRENT. This message will be rather long, as I need to
> describe all details.
...
> /usr/bin/cc -target x86_64-unknown-freebsd12.0
> --sysroot=/usr/obj/nanobsd/data/src/amd64.amd64/tmp
> -B/usr/obj/nanobsd/data/src/amd64.amd64/tmp/usr/bin  -O2 -pipe
> -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
> -I/data/src/sys/netgraph/bluetooth/include
> -I/data/src/sys/netgraph/bluetooth/drivers/ubtbcmfw
> -DHAVE_KERNEL_OPTION_HEADERS -include
> /usr/obj/nanobsd/data/src/amd64.amd64/sys/D2500CC/opt_global.h -I.
> -I/data/src/sys -I/data/src/sys/contrib/ck/include -fno-common -g
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
> -I/usr/obj/nanobsd/data/src/amd64.amd64/sys/D2500CC   -MD
> -MF.depend.ubtbcmfw.o -MTubtbcmfw.o -mcmodel=kernel -mno-red-zone
> -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables
> -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef
> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function
> -Wno-error-pointer-sign -Wno-error-shift-negative-value
> -Wno-address-of-packed-member  -mno-aes -mno-avx  -std=iso9899:1999 -c
> /data/src/sys/netgraph/bluetooth/drivers/ubtbcmfw/ubtbcmfw.c -o ubtbcmfw.o
> 
> *****
> Assertion failed: ((!RequiresNullTerminator || BufEnd[0] == 0) &&
> "Buffer is not null terminated!"), function init, file
> /data/src/contrib/llvm/lib/Support/MemoryBuffer.cpp, line 48.
> *****

Which file system is /data/src/sys/netgraph/bluetooth/drivers/ubtbcmfw/ubtbcmfw.c
on?  Is your obj directory on another file system?

I'm roughly guessing there is some sort of problem with memory mapping,
or the file system itself, since the assertion is similar to what was
reported here:

http://lists.llvm.org/pipermail/cfe-dev/2014-May/037059.html

-Dimitry