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

On Tue, 22 Aug 2017 11:12:02 -0700 David Wolfskill wrote: > On Tue, Aug 22, 2017 at 08:08:57PM +0200, Hartmann, O. wrote: > > On Tue, 22 Aug 2017 06:38:36 -0700 > > David Wolfskill wrote: > > > > I also ran into this problem after "upgrading" to

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

On Tue, Aug 22, 2017 at 08:08:57PM +0200, Hartmann, O. wrote: > On Tue, 22 Aug 2017 06:38:36 -0700 > David Wolfskill wrote: > > I also ran into this problem after "upgrading" to r322769 and now I > have on ALL systems, I did this "upgrade", a wrecked system which isn't >

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

On Tue, 22 Aug 2017 06:38:36 -0700 David Wolfskill wrote: I also ran into this problem after "upgrading" to r322769 and now I have on ALL systems, I did this "upgrade", a wrecked system which isn't even capable of compiling a new kernel or world. I can understand that

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

On Tue, Aug 22, 2017 at 08:43:27PM +0300, Konstantin Belousov wrote: > ... > Try this. The patch helped ae@, it seems. > I will commit it anyway in a hour, but more confirmations or nacks > would be good. This patch has some debugging bits which add noise on > console when a process traps. If

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

On Tue, Aug 22, 2017 at 09:07:03AM -0700, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 06:34:42PM +0300, Konstantin Belousov wrote: > > ... > > > Bisection time? Or if there's another approach (or even a suggestion > > > for a revision to try first), I'm up for it. 9And yes, I'll just > > >

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

On 22 August 2017 at 09:38, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: >> ... >> > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your >> > > object directories. >> > >> > I think I'll need a working

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

On Tue, Aug 22, 2017 at 06:34:42PM +0300, Konstantin Belousov wrote: > ... > > Bisection time? Or if there's another approach (or even a suggestion > > for a revision to try first), I'm up for it. 9And yes, I'll just > > be rebuilding the kernel for the rest of this exercise, I think. > > That

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

On Tue, Aug 22, 2017 at 08:17:38AM -0700, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: > > ... > > > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your > > > > object directories. > > > > > > I think I'll need a working /bin/sh

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

On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: > ... > > > 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

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

Same here, when running `adjkerntz -i` while upgrading from r322737 to r322776. On Tue, Aug 22, 2017, Konstantin Belousov wrote: > $ gdb /bin/sh sh.core > (gdb) bt > (gdb) info registers > (gdb) disassemble # gdb `which adjkerntz` adjkerntz.core ... Core was generated by `adjkerntz -i'. Program

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

On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: > ... > > > 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

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 ||

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

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

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

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

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

On Tue, Aug 22, 2017 at 08:15:56AM -0400, Ed Maste wrote: > On 22 August 2017 at 07:46, David Wolfskill wrote: > > > > lldb's notion of the backtrace was fairly non-useful: > > g1-252(11.1-S)[7] lldb -c sh.core > > Try: > % lldb /bin/sh -c sh.core freebeast(12.0-C)[12]

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

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

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

On 22 August 2017 at 07:46, David Wolfskill wrote: > > lldb's notion of the backtrace was fairly non-useful: > g1-252(11.1-S)[7] lldb -c sh.core Try: % lldb /bin/sh -c sh.core ___ freebsd-current@freebsd.org mailing list

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

On Tue, Aug 22, 2017 at 04:46:27AM -0700, David Wolfskill wrote: > Started with: > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #445 > r322740M/322745:1200040: Mon Aug 21 04:35:19 PDT 2017 > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > >