So what was the bug I was looking for?
We recently switched off_t from 32-bit to 64-bit. Once this change was made, suddenly the "ar" tool would start to generate corrupt archives when objects were deleted from the archive.
It took quite a long time to find out that this snippet in the open function was the root cause:
if (!error && (mode & O_TRUNC))
{
syscall(SYS_ftruncate, fd, 0);
Needless to say, ftruncate was getting a very large length argument passed to it, resulting in the underlying filesystem outright refusing to perform any action -> O_TRUNC would not truncate existing files -> ar generated a corrupt archive when the file shrank.
It's obvious now, but believe me it wasn't easy to find it.
#bugstories
1 comment