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

On Tue, Aug 22, 2017 at 05:46:17AM -0700, David Wolfskill wrote:
> On Tue, Aug 22, 2017 at 03:34:49PM +0300, Konstantin Belousov wrote:
> > ...
> > $ gdb /bin/sh sh.core
> > (gdb) bt
> > (gdb) info registers
> > (gdb) disassemble
> 
> [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 ?? () from /lib/libc.so.7
> (gdb) bt
> #0  0x0000000800b6ee08 in ?? () from /lib/libc.so.7
> #1  0x0000000800b6eda1 in malloc () from /lib/libc.so.7
> #2  0x00000000004116cd in ?? ()
> #3  0x000000000041193f in ?? ()
> #4  0x0000000000407751 in ?? ()
> #5  0x00000000004074ef in ?? ()
> #6  0x000000000040fb50 in ?? ()
> #7  0x0000000000406892 in ?? ()
> #8  0x00000000004054aa in ?? ()
> #9  0x0000000000405704 in ?? ()
> #10 0x000000000040515b in ?? ()
> #11 0x00000000004111ae in ?? ()
> #12 0x0000000000402ecf in ?? ()
> #13 0x000000080064b000 in ?? ()
> #14 0x0000000000000000 in ?? ()
> (gdb) info registers
> rax            0x800e60fa0      34374815648
> rbx            0x6278c0 6453440
> rcx            0x400    1024
> rdx            0x5a5a5a5a5aff9c9c       6510615555437730972
> rsi            0x7fffffffdf30   140737488346928
> rdi            0x7fffffffdf60   140737488346976
> rbp            0x7fffffffdf20   0x7fffffffdf20
> rsp            0x7fffffffdea0   0x7fffffffdea0
> r8             0xfefefefefefefeff       -72340172838076673
> r9             0x8080808080808080       -9187201950435737472
> r10            0x8006cc000      34366865408
> r11            0x8006cc000      34366865408
> r12            0x6278c0 6453440
> r13            0x8006cc240      34366865984
> r14            0x1f8    504
> r15            0x7fffffffdf30   140737488346928
> rip            0x800b6ee08      0x800b6ee08
> eflags         0x10246  [ PF ZF IF RF ]
> cs             0x43     67
> ss             0x3b     59
> ds             <unavailable>
> es             <unavailable>
> fs             <unavailable>
> gs             <unavailable>
> fs_base        <unavailable>
> gs_base        <unavailable>
> (gdb) disassemble 0x800b6ee08,0x800b6ee08
> Dump of assembler code from 0x800b6ee08 to 0x800b6ee08:
> End of assembler dump.
> (gdb) disassemble 0x800b6ee08
> No function contains specified address.
> (gdb) 
> 
> > ...
> > > I grabbed a copy of the dmesg.boot for today, and have attached
> > > "head -100" from it to this message.
> > Thank you.
> 
> :-}
> 
> > ...
> > > > 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.
> 
> I think I'll need a working /bin/sh to do that.  As noted, I could
> try the stable/11 /bin/sh; on the other hand, if it's dying in a
> library, that's not likely to help a whole lot. :-}
I highly suspect that this is not /bin/sh at all.  Backtrace strongly
suggests that the malloc() has issues, but again I suspect that the
reason is not an issue in malloc, but its use of TLS.

The amd64 changes were to the TLS base register handling.  So you might
try to boot previous kernel.  If this works out without replacing libc
then it is definitely TLS, but I still do not know what is wrong.

> 
> But yes: once we resolve the "working /bin/sh" issue, clearing
> /usr/obj & rebuilding is straighforward and shouldn't take too long.
> 
> Peace,
> david
> -- 
> David H. Wolfskill				david_at_catwhisker.org
> If we wish to eliminate sources of Fake News, start at the top: D. Trump.
> 
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.