--gr/z0/N6AeWAPJVB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 15, 2006 at 10:36:09AM +0100, David Malone wrote:
> FWIW, in FreeBSD I think we've tracked down all outstanding memory
> corruption bugs in which DIRHASH was implicated and they all turned
> out to be problems in other subsystems that used memory allocations
> of the same size.

As a quick cheesy test, I wonder if we could confirm this, or at least
learn something useful, by moving the problem around?=20

Artificially change the size of the structures allocated by dirhash:
seeing that it is no longer hit by these corruptions, and perhaps what
else is hit instead, may be enlightening.

After all, if this is really the problem, removing the use of dirhash
has removed the victim, not the culprit, and something else may now be
the new victim.

> The DEBUG_MEMGUARD option was quite useful in tracking this down - I
> wonder if something similar might help narrow down what's happening in
> your case?

I presume this surrounds each allocation with extra padding filled
with known content, and checks that the padding is undisturbed later?
That more general solution sounds very useful too; I'm not sure if we
have something like this, but we probably should.

--
Dan.


--gr/z0/N6AeWAPJVB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (NetBSD)

iD8DBQFE66AeEAVxvV4N66cRAtgEAJ4s7xJ37CSMRoZN1oY7skregS8xDQCgwLwr
wv8W7XELh+lJ3f4BYNmu10w=
=twzJ
-----END PGP SIGNATURE-----

--gr/z0/N6AeWAPJVB--