<holding his head down in shame> i've just checked in a new version of file.c which does exactly what you recommended... adds a '\0' at the end of the buffer.
-matt Today, Jason A. Smith wrote forth saying... > On Mon, 2002-08-26 at 18:10, Steven Wagner wrote: > > 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... :( > > See, the problem wasn't in your code after all. :) It should be > sufficient to just append a null char to the end of the read in buffer > after it checks for a read error, something like: > > buffer[read_len] = '\0'; > > But Matt should make this call I guess. I am surprised that nothing > else ever triggered this bug. Aren't there other /proc entries that are > read in which could change in size? > > ~Jason > > >
