SIGSEGV in /bin/sh after r322740 -> r322776 update

[Konstantin Belousov]

On Tue, Aug 22, 2017 at 05:28:36AM -0700, David Wolfskill wrote:
> On Tue, Aug 22, 2017 at 02:59:23PM +0300, Konstantin Belousov wrote:
> > ...
> > > lldb's notion of the backtrace was fairly non-useful:
> > > g1-252(11.1-S)[7] lldb -c sh.core
> > > (lldb) target create --core "sh.core"
> > > Core file '/home/david/sh.core' (x86_64) was loaded.
> > > (lldb) bt
> > > * thread #1, name = 'sh', stop reason = signal SIGSEGV
> > >   * frame #0: 0x0000000800b6ee08
> > >     frame #1: 0x0000000800000003
> > > (lldb) 
> > I am not sure how to get the interesting information with lldb,
> > try gdb.
> 
> freebeast(12.0-C)[11] gdb -c sh.core 
> GNU gdb (GDB) 8.0 [GDB v8.0 for FreeBSD]
> ...
> Type "apropos word" to search for commands related to "word".
> [New LWP 100182]
> Core was generated by `sh -c cc --version || echo 0.0.0'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x0000000800b6ee08 in ?? ()
> (gdb) bt
> #0  0x0000000800b6ee08 in ?? ()
> #1  0x0000000000000000 in ?? ()
> (gdb) 
> 
> > Disassemble the code around the faulting %rip.
> 
> Sorry; I haven't done very much with any debugger other than the
> one in Perl in ... decades.  Checking the gdb docs online, the only
> reference to "disassembly" reads "23.3.3.22 Disassembly In Guile",
> which seems rather far off the mark.

$ gdb /bin/sh sh.core
(gdb) bt
(gdb) info registers
(gdb) disassemble

> 
> I'm afraid I'll need a bit more detail.
> 
> >Also provide the first
> > 100 lines of verbose dmesg of the boot on the affected machine.
> 
> Well, a copy of the complete (verbose) dmesg.boot from *yesterday*
> (r322740) is at
> <http://www.catwhisker.org/~david/FreeBSD/history/freebeast.12_dmesg.txt>
> 
> I grabbed a copy of the dmesg.boot for today, and have attached
> "head -100" from it to this message.
Thank you.

> 
> > Is it only /bin/sh which faults ?
> 
> Well, /bin/csh doesn't seem to be giving me any trouble as I use
> it interactively.  I don't recall seeing evidence that anything
> that isn't invoking /bin/sh is having a problem; on the other hand,
> there is a lot of the system I don't normally use.  But things like
> "svn info" work, as does "svnlite info" (big difference there is
> that former is a port, built under stable/11, while the latter would
> be part of base).
> 
> > Does system boot into multiuser ?
> 
> Yes; it does.  But checking /var/log/messages, I see:

Ok, can you rebuild kernel and libc from scratch ?  I.e. remove your
object directories.