Below is a bug fix which I have applied to the Metakit CVS head.
This may have been the cause of a few reports I have had over the
years, which I could never reproduce reliably. I do not know how the
bug manifests itself exactly (Max reported new[] returning a pointer
to inaccessible memory in c4_Column::CopyData),
but a problem this deep in the Metakit code base leads me to
recommend updating to the CVS head where possible. The only case
when this bug does definitely not affect MK is if you use it with
memory-mapping disabled.
I have also applied a bug fix to CVS which I recently discovered when
re-opening a datafile and committing again several times (see the
08-01 entry in CHANGES).
Lastly, I decided to revert to maintaining the CHANGES file manually
again, instead of pointing to the possibly long and sometimes
confusing timeline generated by CVStrac.
Will wrap this all up into a new Metakit 2.4.9.6 release if no-one
else brings up other issues in the next week or so.
-jcw
Begin forwarded message:
From: Max Kaehn
Date: October 30, 2006 19:34:23 GMT+01:00
To: [EMAIL PROTECTED]
Subject: A very subtle Metakit bug, with fix
Ran into an interesting one in column.cpp; in c4_Column::UsesMap(),
there's a comparison:
ptr_ - Strategy()._mapStart < Strategy()._dataSize;
This can go wrong in the following circumstance (which I have only
observed intermittently on Linux 2.6 using gcc 3.3.3):
1. mmap puts a file at a low address like 0x100000.
2. malloc puts a buffer at a high address like 0xb8000000.
3. The difference between a malloc'd address and the mmap'd
address is more than 2 gigabytes, so it comes out negative.
This is, of course, less than Strategy()._dataSize, so
c4_Column::UsesMap() returns true for a buffer that
doesn't actually use the map.
The fix:
ptr_ < (Strategy()._mapStart + Strategy()._dataSize);
Thanks for all your work on the database.
_____________________________________________
Metakit mailing list - [email protected]
http://www.equi4.com/mailman/listinfo/metakit
