Re: HEAD/i386 r320212: three reproducible panics [see also bugzilla 220404 about a type of problem introduced in head -r329722 ]
On Friday 30 June 2017 22:45:39 Mark Millard wrote:
> [Just for the 3rd backtrace example. . .]
>
> Oleg V. Nauman oleg at theweb.org.ua wrote on
> Fri Jun 23 16:58:07 UTC 2017 :
>
> .. . .
>
> > __curthread () at ./machine/pcpu.h:225
> > 225 __asm("movl %%fs:%1,%0" : "=r" (td)
> > (kgdb) #0 __curthread () at ./machine/pcpu.h:225
> > #1 doadump (textdump=-968633856) at ../../../kern/kern_shutdown.c:318
> > #2 0xc06e88c4 in kern_reboot (howto=)
> >
> > at ../../../kern/kern_shutdown.c:386
> >
> > #3 0xc06e8c5b in vpanic (fmt=,
> >
> > ap=0xefd5c73c "\340\334\235\300\310\370\266\306\001")
> > at ../../../kern/kern_shutdown.c:779
> >
> > #4 0xc06e8b1b in panic (fmt=0xc092e18e "%s")
> >
> > at ../../../kern/kern_shutdown.c:710
> >
> > #5 0xc08eed21 in trap_fatal (frame=0xefd5c878, eva=)
> >
> > at ../../../i386/i386/trap.c:978
> >
> > #6 0xc08eea38 in trap (frame=)
> >
> > at ../../../i386/i386/trap.c:704
> >
> > #7
> > #8 0xc6bcda1b in ?? ()
> > #9 0xc0770281 in unp_connect2 (so=, so2=,
> >
> > req=) at ../../../kern/uipc_usrreq.c:1497
> >
> > #10 0xc076ff17 in unp_connectat (fd=, so=,
> >
> > nam=, td=)
> > at ../../../kern/uipc_usrreq.c:1446
> >
> > #11 0xc076d510 in unp_connect (so=0xc71c9400, nam=0xc662d500,
> >
> > td=) at ../../../kern/uipc_usrreq.c:1310
> >
> > #12 uipc_connect (so=0xc71c9400, nam=0xc662d500, td=)
> >
> > at ../../../kern/uipc_usrreq.c:587
> >
> > #13 0xc076a042 in kern_connectat (td=, dirfd=-100,
> >
> > fd=, sa=0xc662d500) at
> > ../../../kern/uipc_syscalls.c:505
> >
> > #14 0xc0769f49 in sys_connect (td=0xc6bcda18, uap=0xc6b6f988)
> >
> > at ../../../kern/uipc_syscalls.c:470
> >
> > #15 0xc08ef679 in syscallenter (td=)
> >
> > at ../../../i386/i386/../../kern/subr_syscall.c:132
> >
> > #16 syscall (frame=) at ../../../i386/i386/trap.c:1103
> > #17
> > #18 0x283a4747 in ?? ()
> > Backtrace stopped: Cannot access memory at address 0xbfbfe794
>
> There are problems with a union having fields
> that interfere with each other. The details of
> the layout and interference likely vary from
> TARGET_ARCH to TARGET_ARCH. This is from
> new material added in head -r319722 and
> involves /head/sys/sys/socketvar.h and
> the new union in struct socket.
>
> See bugzilla 220404 and its analysis of a
> repeatable crash on 32-bit powerpc for
> head -r320482 (I'd made a large jump from
> well before -r319722):
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220404
>
> It also involves unp_connect2, unp_connect,
> kern_connectat, sys_connect and is likely
> involved. But different aliasing in the
> union across architectures likely lead to
> varying details for the behavior that results
> from the bad handling of union use.
Subscribed, thank you.
>
> ===
> Mark Millard
> markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEAD/i386 r320212: three reproducible panics [see also bugzilla 220404 about a type of problem introduced in head -r329722 ]
[Just for the 3rd backtrace example. . .]
Oleg V. Nauman oleg at theweb.org.ua wrote on
Fri Jun 23 16:58:07 UTC 2017 :
. . .
> __curthread () at ./machine/pcpu.h:225
> 225 __asm("movl %%fs:%1,%0" : "=r" (td)
> (kgdb) #0 __curthread () at ./machine/pcpu.h:225
> #1 doadump (textdump=-968633856) at ../../../kern/kern_shutdown.c:318
> #2 0xc06e88c4 in kern_reboot (howto=)
> at ../../../kern/kern_shutdown.c:386
> #3 0xc06e8c5b in vpanic (fmt=,
> ap=0xefd5c73c "\340\334\235\300\310\370\266\306\001")
> at ../../../kern/kern_shutdown.c:779
> #4 0xc06e8b1b in panic (fmt=0xc092e18e "%s")
> at ../../../kern/kern_shutdown.c:710
> #5 0xc08eed21 in trap_fatal (frame=0xefd5c878, eva=)
> at ../../../i386/i386/trap.c:978
> #6 0xc08eea38 in trap (frame=)
> at ../../../i386/i386/trap.c:704
> #7
> #8 0xc6bcda1b in ?? ()
> #9 0xc0770281 in unp_connect2 (so=, so2=,
> req=) at ../../../kern/uipc_usrreq.c:1497
> #10 0xc076ff17 in unp_connectat (fd=, so=,
> nam=, td=)
> at ../../../kern/uipc_usrreq.c:1446
> #11 0xc076d510 in unp_connect (so=0xc71c9400, nam=0xc662d500,
> td=) at ../../../kern/uipc_usrreq.c:1310
> #12 uipc_connect (so=0xc71c9400, nam=0xc662d500, td=)
> at ../../../kern/uipc_usrreq.c:587
> #13 0xc076a042 in kern_connectat (td=, dirfd=-100,
> fd=, sa=0xc662d500) at ../../../kern/uipc_syscalls.c:505
> #14 0xc0769f49 in sys_connect (td=0xc6bcda18, uap=0xc6b6f988)
> at ../../../kern/uipc_syscalls.c:470
> #15 0xc08ef679 in syscallenter (td=)
> at ../../../i386/i386/../../kern/subr_syscall.c:132
> #16 syscall (frame=) at ../../../i386/i386/trap.c:1103
> #17
> #18 0x283a4747 in ?? ()
> Backtrace stopped: Cannot access memory at address 0xbfbfe794
There are problems with a union having fields
that interfere with each other. The details of
the layout and interference likely vary from
TARGET_ARCH to TARGET_ARCH. This is from
new material added in head -r319722 and
involves /head/sys/sys/socketvar.h and
the new union in struct socket.
See bugzilla 220404 and its analysis of a
repeatable crash on 32-bit powerpc for
head -r320482 (I'd made a large jump from
well before -r319722):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220404
It also involves unp_connect2, unp_connect,
kern_connectat, sys_connect and is likely
involved. But different aliasing in the
union across architectures likely lead to
varying details for the behavior that results
from the bad handling of union use.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
