From: Steven W. <sw...@il...> - 2002-08-26 22:10:53
|
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] |