Date: Mon, 24 Sep 2001 20:31:16 -0700 From: Peter Wemm <peter@wemm.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: Ian Dowse <iedowse@maths.tcd.ie>, Julian Elischer <julian@elischer.org>, hackers@FreeBSD.ORG Subject: Re: VM Corruption - stumped, anyone have any ideas? Message-ID: <20010925033116.6C2C23808@overcee.netplex.com.au> In-Reply-To: <200109250241.f8P2f2p98637@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote: > : > :I did it as part of the KSE work in 5.x. It would be quite easy to do it > :for 4.x as well, but it makes a.out coredumps problematic. > : > :Also, "options UPAGES=4" is a pretty good defensive measure. > : > :Cheers, > :-Peter > :-- > :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > > Well, in 4.x: > > (kgdb) print p->p_addr > $6 = (struct user *) 0xcb7b9000 > (kgdb) print &p->p_addr->u_sigacts > $7 = (struct sigacts *) 0xcb7b9260 > (kgdb) print &p->p_addr->u_stats > $8 = (struct pstats *) 0xcb7b9cd0 > (kgdb) print &p->p_addr->u_kproc > $9 = (struct kinfo_proc *) 0xcb7b9db0 > (kgdb) print &p->p_addr->u_md > $10 = (struct md_coredump *) 0xcb7ba1d0 > (kgdb) print &p->p_addr->u_guard (my new field) > $11 = (u_int32_t *) 0xcb7ba1d0 > (kgdb) > > cb7b9000 start of kstack > cb7ba1d4 end of struct user > cb7bb000 top of kstack > > Leaving us 3628 bytes for the kernel stack. > > Something really weird is going on... I added u_guard to the end > of the struct user structure and there are two or three processes > hitting the guard immediately. All the rest are ok. I'm going > to investigate further but this is very odd. Am I missing something > about the UAREA? Oh, one other thing... When we had PCIBIOS active for pci config space read/write support, we had stack overflows on many systems when the SSE stuff got MFC'ed. The simple act of trimming about 300 bytes from the pcb_save structure was enough to make the difference between it working or not. We are *way* too close to the wire. I asked about raising UPAGES from 2 to 3 before RELENG_4_4 but it never happened. Julian cleaned up a couple of places stuff where we were allocating 2K of local data *twice* on local stack frames. There are some gcc patches floating around that enable you to generate a warning if your local stack frame exceedes a certain amount or the arguments are bigger than a specified amount. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010925033116.6C2C23808>