Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Wed, 24 May 2017 16:35:58 +0300
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_at_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 ?
Received on Wed May 24 2017 - 11:36:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC