Date: Wed, 24 May 2017 16:35:58 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: David Wolfskill <david@catwhisker.org>, Dimitry Andric <dim@FreeBSD.org>, current@freebsd.org Subject: Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV Message-ID: <20170524133558.GO1622@kib.kiev.ua> In-Reply-To: <20170524130143.GL1190@albert.catwhisker.org> References: <20170524121033.GL1622@kib.kiev.ua> <F75597F9-86DF-4CD5-B8B0-5169D2D96DD9@FreeBSD.org> <20170524130143.GL1190@albert.catwhisker.org>
index | next in thread | previous in thread | raw e-mail
On Wed, May 24, 2017 at 06:01:43AM -0700, David Wolfskill wrote: > On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote: > > ... > > > building special pic c library > > > --- libc.so.7 --- > > > cc: error: unable to execute command: Segmentation fault (core dumped) > > > cc: error: linker command failed due to signal (use -v to see invocation) > > > *** [libc.so.7] Error code 254 > > > > Looks like your linker is crashing. Can you figure out: > > 1) The exact linker command being run > > 2) The path to the linker executable that crashes > > 3) Backtrace of the crash > > > > -Dimitry > > > > On Wed, May 24, 2017 at 03:10:33PM +0300, Konstantin Belousov wrote: > > ... > > > > If you perform build of r318739 on r318739 (i.e. build of the same sources > > as installed on your machine), does the SIGSEGV occur ? > > > > Anyway, get the core file loaded into gdb and get the backtrace, at least. > > Sorry for the delay; I'm way out of practice with using a debugger... > and I see that gdb isn't in head now. lldb tells me: > > (lldb) bt > * thread #1, name = 'ld', stop reason = signal SIGSEGV > * frame #0: 0x0000000000000000 > (lldb) > > which isn't entirely unexpected, I suppose, given the nature of SIGSEGV. Useful gdb is in ports, devel/gdb. There is nothing in the nature of SIGSEGV which makes lack of the backtrace a reasonable outcome. > > On the build machine, I "cloned" slice 4 to slice 3, then rebooted it > from slice 3, "updated" /usr/src to r318739 and told it to go build > itself (while I continued poking at my laptop). The build machine has > not yet completed the ">>> stage 4.2: building libraries" step -- recall > that I had performed a "make clean" before cloning... -- but it has got > quite a bit beyond the previous point of failure (still building clang). > > I have copied the ld.core and libc.so.7.meta files from the build > machine to <http://www.catwhisker.org/~david/FreeBSD/head/r318781/>; (and > made gzipped copies, as well). > > As far as I can tell, the "ld" command was: > freebeast(12.0-C)[10] ls -lT `which ld` > -r-xr-xr-x 2 root wheel 1706336 May 23 05:29:59 2017 /usr/bin/ld > > This, from: > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #352 r318739M/318739:1200031: Tue May 23 05:16:24 PDT 2017 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > > Late note: ">>> stage 4.2: building libraries" has completed on the > build machine (building r318739 while running r318739). > > I apologize for not getting all the information you (both) requested, but > thought it best to provisde what I can (sooner). If build of r318739 succed, can you try, please, to rebuild the current latest sources, but now with reverted r318750 ?help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170524133558.GO1622>