Problem with mangled caf files in CAFOpenArtRead() (storage/timecaf/caf.c bug?)
Xavier Roche
roche at exalead.com
Mon Dec 13 13:12:44 UTC 2004
Hi,
As a followup to a problem we encountered
(<http://groups.google.com/groups?hl=fr&lr=&threadm=cp90co%2469d%241%40news.httrack.net&rnum=1&prev=/groups%3Fas_umsgid%3D%253Ccp90co%252469d%25241%40news.httrack.net%253E%26lr%3D%26hl%3Dfr>)
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:
/usr/local/news/spool/articles/timecaf-00/a9/41d9.CF
8072404
and the article offset was:
8077312
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:
(ladebug) 0x384000/10x
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
you wish.
Regards,
Xavier
More information about the inn-bugs
mailing list