Problem with mangled caf files in CAFOpenArtRead() (storage/timecaf/caf.c bug?)
roche at exalead.com
Mon Dec 13 13:12:44 UTC 2004
As a followup to a problem we encountered
with INN on a large spool, I discovered that there might be a problem in
the CAFOpenArtRead() function.
OS: Digital alpha (Tru64 5.1)
INN version: 2.4.1
When a .CF file is truncated for any reason (in our case, probably a
memory shortage that crashed INN), the .CF header apparently contains
references (file offset) of messages that are beyond the file.
In our case, the file size was:
and the article offset was:
Problem: the 'lseek(fd, tocent.Offset, SEEK_SET) < 0)' (at caf.c:592) is
successful (no error returned by the system - this is probably 'legal'
to seek beyond a file boundary) and the mmap (at timecaf.c:463,
'private->mmapbase = mmap(NULL, private->mmaplen, PROT_READ, MAP_SHARED,
fd, tmpoff)') returns a pointer to the "ghost" area. BUT reading in this
"ghost" area lead to a BUS error (process stopped with a 'Bus error
(core dumped)' message)
The mapped memory region is alive in the system mmap table:
bash-2.01$ pmap 180210
flags vaddr size off
r-- 10000 2000 0
r-- 12000 2000 0
rw- 14000 2000 0
rw- 16000 36e000 0
r-- 384000 6000 7b4000 <<<< THIS ONE
rwx 11fff0000 10000 0
(the '0x7b4000' is the file offset, == 8077312, which is higher than the
filesize, 8072404 bytes)
And nor the program or debugger can not read this zone:
0x384000: Failed to read data.
I know that the file is probably truncated, but would it be possible to
handle out-of-bound indexes with mmap() ?
I can provide more information (the session is still under debugger) if
More information about the inn-bugs