Date: Sun, 12 Jul 1998 01:49:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: freebsd@magnet.geophysik.tu-freiberg.de (Holm Tiffe) Cc: tlambert@primenet.com, freebsd-current@FreeBSD.ORG Subject: Re: Arrgh ! resubscribing again again again.... Message-ID: <199807120149.SAA18536@usr08.primenet.com> In-Reply-To: <199807111457.QAA05465@magnet.geophysik.tu-freiberg.de> from "Holm Tiffe" at Jul 11, 98 04:57:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > This is normal. > > Terry, I think I don't understand fully what you have written later, but one > thing I know: > > It is ok, that sendmail dies when it forks when netscape is running, but > it is all but not ok, when sendmails childs are dying when no netscape > is running anymore ! Then force NetScape to uncache the objects that it has places int the X server's shared memroy segment. The problem is that objects in the shared memory segment are not reference counted, and Netscape does nto explicitly free them. You could argue that this is an X server bug (ie: the server should reference count the objects, and decrement the reference count when Netscape's connection goes away, removing the object when the reference goes to zero), and you could argue that this is a Netscape bug. Either way, you can "fix" the galloping memory problem by disabling the shared memory extensions so that Netscape can't use them, and then no matter who is really at fault, the memory leak will go away. > When this case is ok, then the swap/VM algorithms are bad and faulty! There is still a process context claiming ownership of the memory, and it is therefore not being released back to the system. The faulty behaviour lies in pilot error, of one kind or another. > Any time, when the system was under high load, I have to kill the > daemons per hand and to restart (or reboot). This can't be ok. You don't *have* to do that. You *could* shutdown your X server and restart it. You simply choose to have your demons die, instead of doing this and/or limiting the amount of VM available to the X server and Netscape, or disabling the X shm extensions. > This is a way to crash a FreeBSD with a userland program. Not a correctly configured FreeBSD, which will have memoryuse, datasize, and stacksize limits that will prevent this problem. > I don't have seen this behavior before Jan/98, when the above behavior > is correct, then please give us the old VM - System back. > Better to have a slow VM then a faulty one. There are a number of known VM bugs; I can, for example, randomly corrupt open files by using mmap() in particular ways (having to do with the page becoming disassociated from the vnode backing it, but not from the address space of the process doing the mapping, and therefore subject to erroneous reuse). I don't believe this (and the other known probls) are what you are seeing, however. You should try reproducing the problem with the shm extensions disabled. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807120149.SAA18536>