From owner-freebsd-current@freebsd.org Fri May 5 23:44:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4920D5F50F for ; Fri, 5 May 2017 23:44:08 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AE91143C; Fri, 5 May 2017 23:44:08 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 6mtBdrDJHETFp6mtCduct5; Fri, 05 May 2017 17:44:00 -0600 X-Authority-Analysis: v=2.2 cv=dZbw5Tfe c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=tJ8p9aeEuA8A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=Rq28YkthQPViCLEV6AIA:9 a=CjuIK1q_8ugA:10 a=CVUIqAa21KwA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 7C712BC5; Fri, 5 May 2017 16:43:57 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v45Nhsxq082981; Fri, 5 May 2017 16:43:55 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201705052343.v45Nhsxq082981@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Andrey Fesenko cc: Kyle Evans , Alastair Hogge , Vladimir Zakharov , Ed Maste , freebsd-current , Dimitry Andric Subject: Re: make buildworld broken at r317821 (libsysdecode) In-Reply-To: Message from Andrey Fesenko of "Fri, 05 May 2017 21:02:04 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 May 2017 16:43:54 -0700 X-CMAE-Envelope: MS4wfGPGlK5MgRkHVOQBSEtcsHCNrx+DUVlSqObAZU8Z9C4ZH/AXoxc/XIOUZnoty5T8umjZAZLZJFLPQd5RojQTh1qjNWet80wpRyA+3AgIOy2kEio0/sAi 29dgUN4MhXm2Mc59BGoUchGLvDxW3mb3hLptnfeYEy8wlhA76MqRxCL88/n8GGIu8F7KrsEnoPmNO8OafQKfojj5hPtV2uWeNvMtscNvEsPdZzICR1Fll/g8 l7E8FSBQjF5vE8adG3njM3pWeGsZi2GYF4hyj2JB7OfZexq1jyy6Q6r7Vcn9Ipo8ZxBq6cMgLKf7S4P0cik9Txa105e7/4Sd4Vd1cNj3cB4DdUNNVRYHakDZ 1wlBNCQj X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 23:44:09 -0000 In message , Andrey Fesenko writes: > On Fri, May 5, 2017 at 8:41 PM, Kyle Evans wrote: > > On Fri, May 5, 2017 at 9:31 AM, Kyle Evans wrote: > > > >> On May 5, 2017 8:39 AM, "Dimitry Andric" 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@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 FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.