From owner-freebsd-current Sun Nov 8 17:15:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17211 for freebsd-current-outgoing; Sun, 8 Nov 1998 17:15:49 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17201 for ; Sun, 8 Nov 1998 17:15:45 -0800 (PST) (envelope-from green@unixhelp.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.8.8/8.8.7) with ESMTP id UAA09906; Sun, 8 Nov 1998 20:03:46 -0500 (EST) Date: Sun, 8 Nov 1998 20:03:45 -0500 (EST) From: Brian Feldman X-Sender: green@janus.syracuse.net To: Julian Elischer cc: Eivind Eklund , dg@root.com, John Fieber , current@FreeBSD.ORG Subject: Re: The infamous dying daemons bug In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yech, that really isn't good having your process's memory disappearing under you... anyone have any idea why for instance I don't have this problem, nor do many others? Cheers, Brian Feldman On Sun, 8 Nov 1998, Julian Elischer wrote: > yes we have. > > It's been a while since we looked at it closely but it appeared that > a page of useful memeory was suddenly unmapped from the process. > > we were hoping that switching to a newer version of FreeBSD > would solve it be we're still seeing it in 3.0 based systems. > > > On Sun, 8 Nov 1998, Brian Feldman wrote: > > > Is it just me or has noone actually captured the corefiles, compiled > > whatever died -g, and tried to debug exactly what caused the sig11? Not > > the underlying cause, just the "actual" cause (like a certain register > > being a wrong value). > > > > Cheers, > > Brian Feldman > > > > On Sun, 8 Nov 1998, Eivind Eklund wrote: > > > > > On Sun, Nov 08, 1998 at 07:17:11AM -0800, David Greenman wrote: > > > > >On Sun, Nov 08, 1998 at 09:22:50AM -0500, John Fieber wrote: > > > > >> One question: Is the problem "sticky"? By that I mean, if it is > > > > >> triggered by a memomry shortage, is something in the kernel > > > > >> corrupted that tends to kill/corrupt daemons from that point in > > > > >> time on, or is it just something that affects isolated processes. > > > > > > > > > >All daemons running at that point seems to get something corrupted. > > > > >If you restart the daemon, it won't happen again until you again run > > > > >out of memory (or whatever it is that trigger the corruption). > > > > > > > > brk(2) will fail and return ENOMEM if the system is low on swap space. > > > > > > phkmalloc() checks for this. > > > > > > Anyway; why does it do this? It does not look like it actually needs > > > to do this, and if we do a memory overcommit, it seems to me that we > > > could do it all the way (or at least have a sysctl to make it do it > > > all the way). I'm also sorely missing a sysctl to turn off memory > > > overcommit... (I don't know the VM system well enough to implement it > > > myself, and I feel very uncomfortable with doing changes in it.) > > > > > > > If the application (phk malloc or the caller of malloc?) isn't > > > > prepared for this, it may end up with a NULL pointer that it doesn't > > > > expect - perhaps not even tripping over it until sometime later. > > > > > > I'm pretty sure this is not the problem. Inactive daemons seems start > > > dying, and I don't always get the "out of swap space" message that > > > comes with setting swap_pager_full. > > > > > > The symptoms are that when the daemon fork after a 'daemons dying > > > occurrance', they will immediately get a sig11 on the child fork. > > > > > > Eivind. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message