Date: Tue, 22 Aug 2017 16:19:58 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: David Wolfskill <david@catwhisker.org>, current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822131958.GE1700@kib.kiev.ua> In-Reply-To: <20170822124617.GN1130@albert.catwhisker.org> References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170822131958.GE1700>