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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170524133558.GO1622>