Date: Thu, 18 Oct 2018 09:29:49 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: Clang segfaults on RPI3 in Alpha9 during buildworld Message-ID: <20181018162949.GA62708@www.zefox.net> In-Reply-To: <3FEA7FF0-2BF7-4517-A8C1-B68C802CF984@yahoo.com> References: <20181017153116.GA61147@www.zefox.net> <3FEA7FF0-2BF7-4517-A8C1-B68C802CF984@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 17, 2018 at 10:18:18AM -0700, Mark Millard wrote: > > > > When clang fails it sometimes produces text like: > > cc: 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. > cc: note: diagnostic msg: > ******************** > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > cc: note: diagnostic msg: /tmp/control-696205.c > cc: note: diagnostic msg: /tmp/control-696205.sh > cc: note: diagnostic msg: > > ******************** > *** [control.lo] Error code 1 > > > The .c and .sh files are intended to help reproduce the problem > without being part of a grander operation like buildworld. (The > names of the .c and .h vary from run to run.) > > Did your example produce such messages? If yes, you may want to > provide some sort of access to the files. if no, you may want > to report that. > > Sometimes the .c is big enough to justify compression if it is to > go into, say, a FreeBSD bugzilla submittal. Some people bundle > the two files into one compressed file. > Clang did all of those things, I put the diagnostic files at http://www.zefox.net/~fbsd/rpi3/clang_trouble/ in case they're worth looking at. It turned out that simply restarting buildworld with -DNO_CLEAN permitted a run to completion. For the moment it looks like it's probably not a clang issue. Sources are updated and a clean-start rebuild is running now. This configuration is new: All storage is on a 128GB Samsung microSD card, arranged in a single partition with 4GB of swap at the end per the Handbook 17.3: mmcsd0: 128GB <SDHC ED4QT 3.0 SN 9B9A5304 MFG 05/2018 by 27 SM> at mmc0 50.0MHz/4bit/65535-block root@www:/usr/src # gpart show mmcsd0s2 => 0 249980985 mmcsd0s2 BSD (119G) 0 57 - free - (29K) 57 241133568 1 freebsd-ufs (115G) 241133625 38856 - free - (19M) 241172481 8808504 2 freebsd-swap (4.2G) It's surprising that Samsung overstates the capacity by ~8GB. The kernel complains about too much swap, but that hasn't caused recognizable problems in the past, on either Pi3 or Pi2. At one point two simultaneous -j4 buildworlds were started by mistake, pushing swap use over 2GB with vm.pageout_oom_seq: 2048 and no distress apart from "indefinite wait...." warnings. Thanks for reading! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181018162949.GA62708>