Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Mar 2002 11:28:27 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.ORG>
To:        "M. Warner Losh" <imp@village.org>
Cc:        current@FreeBSD.ORG, obrien@FreeBSD.ORG
Subject:   Re: turning off malloc's AJ by default
Message-ID:  <Pine.NEB.3.96L.1020324112220.47668e-100000@fledge.watson.org>
In-Reply-To: <20020323.172335.39636005.imp@village.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sat, 23 Mar 2002, M. Warner Losh wrote:

> In message: <20020323155500.A18666@dragon.nuxi.com>
>             "David O'Brien" <obrien@FreeBSD.ORG> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020324112220.47668e-100000>