From owner-freebsd-current Sun Mar 24 8:28:41 2002 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 871A237B419; Sun, 24 Mar 2002 08:28:33 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2OGSRk75028; Sun, 24 Mar 2002 11:28:27 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 24 Mar 2002 11:28:27 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "M. Warner Losh" Cc: current@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: turning off malloc's AJ by default In-Reply-To: <20020323.172335.39636005.imp@village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 23 Mar 2002, M. Warner Losh wrote: > In message: <20020323155500.A18666@dragon.nuxi.com> > "David O'Brien" writes: > : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. > : If having 'AJ' by default is deemed not useful (by being removed from the > : DP), it sounds like we should just turn it off. > : > : Unless there is strong objection, I plan on committing this. > > I think we should keep AJ enabled until at least DP2. It has found bugs > in the past, and I suspect that a lot of new code is going in between > now and then. Not clear from your suggestion if you mean the branch or the dp's. My feeling is that a useful strategy is: - -CURRENT has AJ from inception of branch until final DP before release. - DP's don't have AJ AJ generates false positives in the form of third party application behavior changes. When we're replacing things like the threading model, etc, etc, I don't want application failures to be attributed to those feature changes when they originate from memory junking. DP's offer an opportunity for third party developers to explore the new feature set, make sure their applications work with the new primitives, etc. While forcing them to fix memory related bugs is a useful activity, doing it with the DP seems to be a less useful activity. Useful feedback: - New protection settings for signalling break (fooapp) - There appear to be thread problems related to file descriptors and KSE - Changes in mmap behavior result in some applications with custom memory management failing Unuseful feedback: - Some major application coredumps before it even pops up a window due to referencing memory after a free but before it's reallocated, resulting in ten or fifteen such bug reports - Some X11 application usually run without a terminal on stderr dies frequently due to violating a safety constraint; failure mode is reported to us and prevents people from running that application, meaning we don't learn about system bugs - Some applications become incredibly slow and have very high loads, so the DP can't be used out of the box for some server environments where we'd like it to be used to maximize load on the system. With new userland code coming into -CURRENT at a rapid rate, it may be useful in -CURRENT for developers. For DPs, probably not. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message