Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Sep 2001 20:22:50 -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:  <20010925032250.57FF03808@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?

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010925032250.57FF03808>