HEAD/i386 r320212: three reproducible panics [see also bugzilla 220404 about a type of problem introduced in head -r329722 ]

[Oleg V. Nauman]

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=<optimized out>)
> > 
> >     at ../../../kern/kern_shutdown.c:386
> > 
> > #3  0xc06e8c5b in vpanic (fmt=<optimized out>,
> > 
> >     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=<optimized out>)
> > 
> >     at ../../../i386/i386/trap.c:978
> > 
> > #6  0xc08eea38 in trap (frame=<optimized out>)
> > 
> >     at ../../../i386/i386/trap.c:704
> > 
> > #7  <signal handler called>
> > #8  0xc6bcda1b in ?? ()
> > #9  0xc0770281 in unp_connect2 (so=<optimized out>, so2=<optimized out>,
> > 
> >     req=<optimized out>) at ../../../kern/uipc_usrreq.c:1497
> > 
> > #10 0xc076ff17 in unp_connectat (fd=<optimized out>, so=<optimized out>,
> > 
> >     nam=<optimized out>, td=<optimized out>)
> >     at ../../../kern/uipc_usrreq.c:1446
> > 
> > #11 0xc076d510 in unp_connect (so=0xc71c9400, nam=0xc662d500,
> > 
> >     td=<optimized out>) at ../../../kern/uipc_usrreq.c:1310
> > 
> > #12 uipc_connect (so=0xc71c9400, nam=0xc662d500, td=<optimized out>)
> > 
> >     at ../../../kern/uipc_usrreq.c:587
> > 
> > #13 0xc076a042 in kern_connectat (td=<optimized out>, dirfd=-100,
> > 
> >     fd=<optimized out>, 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=<optimized out>)
> > 
> >     at ../../../i386/i386/../../kern/subr_syscall.c:132
> > 
> > #16 syscall (frame=<optimized out>) at ../../../i386/i386/trap.c:1103
> > #17 <signal handler called>
> > #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