Re: corrupted real-time input stream

[Carl Reynolds <redhat-install-list hyperbole-software com>]

Bret Stern wrote:

>  
>
>
> > > > > >> When the server reads the data from the buffer file, it is asking for 128K bytes. It gets 128K, but the end of the input from about 85K is filled with 0s. If I save the buffer file to another location and 'od' the file, I can see that the data being written to the buffer file is correct and does not contain the area of 0s returned by the read. I tried changing the length requested by the read so that it was only asking for 32K bytes at a time, but the data still contains 0s from about 80K on. 
> > > > > >>  <snip...>
> > > > > >>
> > > > > >>When the server reads the data from the buffer file, it is 
> >
> > > asking for 
> >
> > > > > >>128K bytes. It gets 128K, but the end of the input from 
> >
> > > about 85K is 
> >
> > > > > >>filled with 0s. If I save the buffer file to another 
> >
> > > location and 'od'
> >
> > > > > >>the file, I can see that the data being written to the 
> >
> > > buffer file is 
> >
> > > > > >>correct and does not contain the area of 0s returned by the read.
> > > > > >> <snip...>
> > > > > >>
> > >
> > > > > It sounds like the buffer may be initialized with '0', with the 
> > > > > exception of the note you make regarding the different file 
> >
> > > location.
> >
> > > > > 
> > > > > Perhaps the buffer already exists (hidden)?? When running your 
> > > > > program, do you check if the buffer already exists?
> > > > > 
> > > > > Debugging is about as much fun as one person can have!
> > > > > 
> > > > > 
> > > > > 
> >
> > > Bret thanks for your response, I had ensured that the file 
> > > buffer doesn't exist before running the program. I don't 
> > > think that is the problem.
> > >
> > > "Debugging is about as much fun as one person can have!" (legally)
> > >
> > >
> > >
> > > Carl.
>
>
> Carl,
>
> I don't know the language you're using, but if it was C (for example)
> i would set a breakpoint and step through the code. If you set
> a watch on the buffer, do that. If not, add a temporary
> print function, that prints the buffer data to a text file
> so you can see what happens as the program progresses.
>
> Also, many times, it's best to walk-away, then come back with
> a clear mind. I've spent huge amounts of time tracking
> program bugs, it's actually time well spent.
>
> Did the upgrade have any effect on data type sizes?
>  
> Can you read in one byte at a time (and loop) to the
> "chunk" you are setting your current file read.
>  
>  
> What's different about saving to the other location, file permissions ??
>  
> Create a program log to see any helpful details.
>  
>  
> Is there a driver that might have changed?
>  
>  
> OK, that's it from me.
>  
>  
> Cheers

I wanted to say thanks, especially to Bret. for your help solving this 
problem. It turns out that when the other programmer upgraded our 
kernel, he also updated the drivers and one of the new drives was 
creating data with enough difference that the program couldn't processes 
it.

I still don't know why the program logs were reflecting that the data 
from the read and to the write contained vast areas of 0s. Possibly 
since this is a real-time program and the data was being updated as the 
program was printing it to the log file, but that would mean we should 
have been seeing areas of 0s in the buffer file as well.

I guess that's a mystery that will have to go un-solved for now.



Thanks again for your help,
Carl.