Re: make buildworld broken at r317821 (libsysdecode)

In message <CA+K5SrNDL=LKRJm0PEgyme8VTHZeAry8XN_W4AMOkycDC_jUNw_at_mail.gmail.c
om>
, Andrey Fesenko writes:
> On Fri, May 5, 2017 at 8:41 PM, Kyle Evans <kevans91_at_ksu.edu> wrote:
> > On Fri, May 5, 2017 at 9:31 AM, Kyle Evans <kevans91_at_ksu.edu> wrote:
> >
> >> On May 5, 2017 8:39 AM, "Dimitry Andric" <dim_at_freebsd.org> wrote:
> >>
> >>
> >> This appears to be caused by bsdgrep. :-/ The build for lib/libsysdecode
> >> uses a shell script, mkioctls, to generate a ioctl.c file at build time.
> >> This script contains the following fragment:
> >>
> >> ioctl_includes=$(
> >>         cd $includedir
> >>         find -H -s * -name '*.h' | \
> >>         egrep -v '(.*disk.*|net/pfvar|net/if_pfsync)\.h' | \
> >>                 xargs egrep -l \
> >> '^#[    ]*define[       ]+[A-Za-z_][A-Za-z0-9_]*[       ]+_IO[^a-z0-9_]' |
> >>                 awk '{printf("#include <%s>\\n", $1)}'
> >> )
> >>
> >> The idea is that all headers are searched for defines of ioctl macros,
> >> which start with _IO.  The -l option to egrep is used to print only the
> >> matching filenames, not the matched content itself.
> >>
> >> However, this option seems to be broken in bsdgrep, as it *does* display
> >> the matched content:
> >>
> >> $ gnugrep -l printf /usr/include/stdio.h
> >> /usr/include/stdio.h
> >>
> >> $ bsdgrep -l printf /usr/include/stdio.h
> >> #define __SSTR  0x0200          /* this is an sprintf/snprintf string */
> >> /usr/include/stdio.h
> >>
> >> I did a quick check, and this option seems to have been accidentally
> >> broken by r317703 [1] ("bsdgrep: fix -w flag matching with an empty
> >> pattern").
> >>
> >> Ed, Kyle, any idea where the problem might be?
> >>
> >> -Dimitry
> >>
> >> [1] https://svnweb.freebsd.org/base?view=revision&revision=317703
> >>
> >>
> >> Hi,
> >>
> >> This is addressed by https://reviews.freebsd.org/D10607
> >>
> >
> > FYI- This has now been committed as r317842. Apologies for the breakage,
> > and thanks for the reports!
> 
> Build not fixed (but is built slightly, a little more) :(
> 
> # uname -a
> FreeBSD des.local 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r317592: Sat
> Apr 29 21:32:04 MSK 2017     root_at_des.local:/usr/obj/usr/src/sys/DES
> amd64
> 
> # svnlite info
> Path: .
> Working Copy Root Path: /usr/src
> URL: https://svn0.eu.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: https://svn0.eu.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 317842
> Node Kind: directory
> Schedule: normal
> Last Changed Author: emaste
> Last Changed Rev: 317842
> Last Changed Date: 2017-05-05 20:35:05 +0300 (Fri, 05 May 2017)
> 
> # make -j1 buildworld
>                                     make[1]: "/usr/src/Makefile.inc1"
> line 160: SYSTEM_COMPILER: Determined that CC=cc matches the source
> tree.  Not bootstrapping a cross-compiler.
> ...
> ===> lib/clang/libllvmminimal (obj,all,install)
> /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal created for
> /usr/src/lib/clang/libllvmminimal
> /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/Support created
> for /usr/src/lib/clang/libllvmminimal
> /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/TableGen created
> for /usr/src/lib/clang/libllvmminimal
> c++  -O2 -pipe -I/usr/src/lib/clang/include
> -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD
> -D__STDC_LIMIT_M
> ACROS -D__STDC_CONSTANT_MACROS
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknow
> n-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\"
> -ffunction-sections -fdata-sections -MD -MF.depend.Support_APInt.o
>  -MTSupport/APInt.o -Qunused-arguments
> -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions
> -fno-rtti  -stdli
> b=libc++ -Wno-c++11-extensions  -c
> /usr/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o
> c++: error: unable to execute command: Segmentation fault (core
> dumped)
> c++: error: clang frontend command failed due to signal (use -v to see
> invocation)
> FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on
> LLVM 4.0.0)
> Target: x86_64-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
> c++: note: diagnostic msg: PLEASE submit a bug report to
> https://bugs.freebsd.org/submit/ and include the crash backtrace, p$
> eprocessed source, and associated run script.
> ...

You have a bad DIMM. I had this same problem on my laptop but not on my 
servers downstairs. That suggested that since all four machines were 
running the same software the difference between them was hardware. 
Replacing the memory in my laptop made this problem go away.

I have a question for you. Do you use ZFS? ZFS exercises memory quite 
aggressively. I also had this problem when I replaced my UFS filesystems 
with ZFS on my testbed many moons ago. It even suffered random kernel 
panics. Here again, replacing the memory resolved the issue.


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_cschubert.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.