From owner-freebsd-hackers Mon Sep 24 20:22:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id CC99F37B412 for ; Mon, 24 Sep 2001 20:22:50 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f8P3MoM20444 for ; Mon, 24 Sep 2001 20:22:50 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 57FF03808; Mon, 24 Sep 2001 20:22:50 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Matt Dillon Cc: Ian Dowse , Julian Elischer , hackers@FreeBSD.ORG Subject: Re: VM Corruption - stumped, anyone have any ideas? In-Reply-To: <200109250241.f8P2f2p98637@earth.backplane.com> Date: Mon, 24 Sep 2001 20:22:50 -0700 From: Peter Wemm Message-Id: <20010925032250.57FF03808@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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? Yes. u_md etc isn't used while the process is running. If you're going to have u_guard, it should come directly after u_stats, and *before* u_kproc, u_md etc. I had been contemplating making a fake 'struct user' in userland only in order to keep the a.out coredump reader code happy. The a.out coredump code (see cpu_coredump() in */*/vm_machdep.c) can generate this fake structure in order to keep gdb happy. But then I realized that a.out coredump debugging was almost totally irrelevant these days. Actually I tell a lie. In 4.x, u_kproc *can* be used on a live process.. see the **NASTY** PT_READ_U and PT_WRITE_U code in sys_process.c. It does a fill_eproc() in order to be able to read/write values from there. Nothing uses this stuff. I removed it from -current quite a while ago, and it should be MFC'ed too. 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