On Tue, Dec 17, 2002 at 05:06:06PM -0500, Brian F. Feldman wrote:
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
> > Whoop. Ok, here's a new patch. I think this covers all the cases.
> > I've done some testing and it appears to do the right thing, please
> > look it over (the last patch
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Whoop. Ok, here's a new patch. I think this covers all the cases.
> I've done some testing and it appears to do the right thing, please
> look it over (the last patch had type-o's and didn't cover the correct
> cases).
I haven't tested,
Whoop. Ok, here's a new patch. I think this covers all the cases.
I've done some testing and it appears to do the right thing, please
look it over (the last patch had type-o's and didn't cover the correct
cases).
-Matt
Index: kern/
oops, sorry, I blew that patch. exitingcnt would have to be incremented
unconditionally.
-Matt
Index: kern/kern_exit.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v
retrieving rev
Here's another go at a patch (untested).
-Matt
Index: kern/kern_exit.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v
retrieving revision 1.187
diff -u -r1.187 kern_exit.c
---
It's a big mess. exit1() sets up vm->vm_freer = p and then
vmspace_exitfree() tests that and calls vmspace_dofree(). It
looks like vm->vm_freer is acting like an exit-lock, so only
one process/thread actually frees the vmspace. But there are
still some serious race conditions
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> What about something like this. If the vm_refcnt is still being
> decremented too early, could it be moved to just before the thread_exit()
> call?
The problem that had to be fixed by removing this race was that two
processes with the same
Jake Burkholder <[EMAIL PROTECTED]> wrote:
> Apparently, On Sat, Dec 14, 2002 at 07:37:31PM -0500,
> Brian F. Feldman said words to the effect of;
>
> > John Baldwin <[EMAIL PROTECTED]> wrote:
> > >
> > > On 12-Dec-2002 Kris Kennaway wrote:
> > > > I got this on an alpha tonight. It was un
What about something like this. If the vm_refcnt is still being
decremented too early, could it be moved to just before the thread_exit()
call?
-Matt
Index: kern/kern_exit.c
=
:P_WEXIT is set, so the process won't get swapped out. The problem is that
:the vmspace refcnt is 0 when swapout_procs is called, since it was
:decremented in exit1. The refcnt is incremented before p_flag is tested
:for P_WEXIT, the swapout is skipped because its found to be set, and then
:vmsp
:The problem appears to be that swapout_procs() is swapping out a process
:that is in the process of exiting (in exit1()) and having already
:relinquished its vmspace, but has not set PRS_ZOMBIE yet (which would be
:preventing the swapout). It's clearly not correct for a process in exit1()
:t
Apparently, On Sat, Dec 14, 2002 at 07:37:31PM -0500,
Brian F. Feldman said words to the effect of;
> John Baldwin <[EMAIL PROTECTED]> wrote:
> >
> > On 12-Dec-2002 Kris Kennaway wrote:
> > > I got this on an alpha tonight. It was under heavy load at the time
> > > (18 simultaneous packa
John Baldwin <[EMAIL PROTECTED]> wrote:
>
> On 12-Dec-2002 Kris Kennaway wrote:
> > I got this on an alpha tonight. It was under heavy load at the time
> > (18 simultaneous package builds had just been spawned on the machine).
> > Any ideas?
> >
> > Slab at 0xfc00042d3fb8, freei 2 = 0.
> > p
On 12-Dec-2002 Kris Kennaway wrote:
> I got this on an alpha tonight. It was under heavy load at the time
> (18 simultaneous package builds had just been spawned on the machine).
> Any ideas?
>
> Slab at 0xfc00042d3fb8, freei 2 = 0.
> panic: Duplicate free of item 0xfc00042d22e0 from zon
14 matches
Mail list logo
