Jason A. Smith wrote:
On Mon, 2002-08-26 at 17:01, Steven Wagner wrote:
You could try checking for EOF or other errors, but I fear this would
only hide the real problem which is what is causing the corruption of
the proc_net_dev.buffer in the first place.
After thinking about this problem a little bit more, I think I might
know what is causing the problem. The only thing I can think is that at
one point, the size of the contents in /proc/net/dev must decrease
slightly, maybe because of the way it is formatted. In the
monitor-core/lib/file.c:slurpfile function, it just calls the system's
read function and checks for errors. The system read call will not pad
the end of your buffer with a null to let you know where it ends, so if
you are over-writing an existing buffer filled with unknown contents the
only way you know where the buffer you just read in ends is by the
number returned from the read call.
Because of this, I think the correct fix is to have the slurpfile
function pad the end of the buffer it just read in with a null char upon
successful reads.
Might as well just change slurpfile to zero out the buffer before each use.
But I'm going to leave that one up to Matt or somebody else, since it
will affect several Linux metrics and I have some Tru64 work that I have to
do over again... :(
Anyway that should fix the problem, provided that procfs is formatting the
file correctly and that the error pops up in the buffer. [duh]
