[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] writes:
> }> I didn't know if you were talking about "not incrementing" when the
> }> process exits or when it rforked. If you rfork(RFMEM), you'd want to
> }> increment the vm_refcnt I'm pretty sure (and it does).
> }
> }No, you really don't.
>
> I do
[EMAIL PROTECTED] writes:
}> I didn't know if you were talking about "not incrementing" when the
}> process exits or when it rforked. If you rfork(RFMEM), you'd want to
}> increment the vm_refcnt I'm pretty sure (and it does).
}
}No, you really don't.
I don't know or we don't want to increment th
[EMAIL PROTECTED] wrote:
> I didn't know if you were talking about "not incrementing" when the
> process exits or when it rforked. If you rfork(RFMEM), you'd want to
> increment the vm_refcnt I'm pretty sure (and it does).
No, you really don't.
You have a number of references on the vm (one per
[EMAIL PROTECTED] writes:
}] You'd actually think that not incrementing in the RFMEM case, but
}] then decrementing if the RFMEM reference goes from 1->0 would be
}] the correct thing to do.
I didn't know if you were talking about "not incrementing" when the
process exits or when it rforked. If y
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] writes:
> }Heh. That's a Biiig snip. I had a huge caveat on the code
> }doing what it did where it did it, if you'll remember. 8-).
>
> Sorry, Terry it was no slight on you (and it looked fine to me too). I just
> wanted to get something in the
[EMAIL PROTECTED] writes:
}Heh. That's a Biiig snip. I had a huge caveat on the code
}doing what it did where it did it, if you'll remember. 8-).
Sorry, Terry it was no slight on you (and it looked fine to me too). I just
wanted to get something in the list archives in case some poor sod d
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] writes:
> [ suggested fix ]
> [ snip ]
> }This looks right, to me.
>
> Sigh. With the fix as in current (decrement the vm_refcnt in the if statement)
> the system panics on boot with a "vmspace already free" message.
> With my version of the fix (only
[EMAIL PROTECTED] writes:
[ suggested fix ]
[ snip ]
}This looks right, to me.
Sigh. With the fix as in current (decrement the vm_refcnt in the if statement)
the system panics on boot with a "vmspace already free" message.
With my version of the fix (only decrement if vm_refcnt) not 1 by calling
[EMAIL PROTECTED] wrote:
> }> You could say that X11 shouldn't use SHMs the way it does now yeah. =)
> }The real problem is that over the UNIX domain socket, it doesn't
> }get client disconnect notificiations necessary for resource tracking,
> }AND browser use of these resources is practically the
FWIW,
This has been fixed in current, kern/kern_exit.c revision 1.147.
Someone should MFC it.
Callum Gibson [EMAIL PROTECTED]
Global Markets IT, Deutsche Bank, Australia 61 2 9258 1620
### The opinions in this message are mine and not Deutsche's ###
To Unsubsc
I have a theory (and a patch) if you're willing to hear it.
[EMAIL PROTECTED] writes:
}> I'd like to take a step further and say it's in SYSVSHM design. All a
}> program has to do is forget to do a shm_detach() and you're f#$%ed.
}Heh. I could make the same argument about "open"...
Except that
"Rogier R. Mulhuijzen" wrote:
> >This is a bug in the MIT shared memory extension for X design,
> >and can't be fixed for long running programs with lots of
> >bitmaps.
>
> I'd like to take a step further and say it's in SYSVSHM design. All a
> program has to do is forget to do a shm_detach() and
At 22:06 8-4-2002 -0700, Terry Lambert wrote:
>All you are doing is marking the segment as removed. The segment
>remains attached by the processes which have it open, and those
>references don't go awaya until the processes in question detach
>the segments, and the reference count goes to zero.
At 8:45 PM +1000 4/9/02, [EMAIL PROTECTED] wrote:
>Please don't make me use the kernel debugger... waa
I believe Terry suggested:
...set the DISPLAY environment variable so that it uses a
real network connection, instead of a UNIX domain socket
(and thus allows the use of the MIT SH
[EMAIL PROTECTED] writes:
}I believe this will give incorrect information, as it's pretty
}obvious that any bug here has to be in the Linux ABI treatment
}of the _exit() resource tracking cleanup of the segments when a
}proce (or "Linux thread") exits. The information "-p" gives is
}the last acce
Andrew wrote:
> On Tue, 9 Apr 2002 [EMAIL PROTECTED] wrote:
> > I replied privately to Terry, but I perhaps should have mentioned also
> > that some of these segments were days old and they were definitely not
> > in use by any process. I logout at the end of every day.
>
> Have you tried ipcs -p
[EMAIL PROTECTED] wrote:
> I replied privately to Terry, but I perhaps should have mentioned also
> that some of these segments were days old and they were definitely not
> in use by any process. I logout at the end of every day.
Logging out does not necessarily stop all processes, or remove
the
At the risk of clogging up -hackers with this, I'm not going crazy...
[EMAIL PROTECTED] writes:
}> I replied privately to Terry, but I perhaps should have mentioned also
}> that some of these segments were days old and they were definitely not
}> in use by any process. I logout at the end of ever
On Tue, 9 Apr 2002 [EMAIL PROTECTED] wrote:
> I replied privately to Terry, but I perhaps should have mentioned also
> that some of these segments were days old and they were definitely not
> in use by any process. I logout at the end of every day.
Have you tried ipcs -p?
Andrew
To Unsubscr
I replied privately to Terry, but I perhaps should have mentioned also
that some of these segments were days old and they were definitely not
in use by any process. I logout at the end of every day.
[EMAIL PROTECTED] writes:
}All you are doing is marking the segment as removed. The segment
}rema
[EMAIL PROTECTED] wrote:
> I'm running FreeBSD 4.5-RELEASE on 2 machines. Yesterday one of them
> ran out of shared memory segments (used by wine, X11 and mozilla).
> Fine, clean them up. However although I could list them with ipcs,
> the vast majority could not be removed, even as root with ipcr
Hi,
I'm running FreeBSD 4.5-RELEASE on 2 machines. Yesterday one of them
ran out of shared memory segments (used by wine, X11 and mozilla).
Fine, clean them up. However although I could list them with ipcs,
the vast majority could not be removed, even as root with ipcrm failing
with "Invalid argum
22 matches
Mail list logo
