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

[Dimitry Andric]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20180625/48e413f6/attachment.sig>