The reason I couldn't reproduce it on trunk is because I'd already fixed the problem :-) In looking through the code trying to figure out where it might be going wrong, I had spotted that those fields should probably have been reset and made that change. I'd also wrongly concluded that that could not have been the source of the error. And since I had no way to reproduce the error any way, I couldn't tell. I never saw a failure on my system using the dir command to create the file. I was only able to get the version using the echo command to fail. But that's fine, once I could reproduce the problem, debugging it was simple.
The reason it was failing for the second file is was reusing the same stream object from the first pass. Since this was done using the bifs(), the stream object is created in a lookup table indexed by the stream name. This table only gets cleared when the program terminates. So going through the sequence of read/close/read reopens the stream object. The close released the buffer, the open reallocated the buffer (seemingly getting the original back with most of the data intact). And because the buffer positioning information had not been reinitialized, the read operations were assuming there was good data in the buffer, resulting in the corruption. Rick On Fri, Apr 24, 2009 at 8:34 AM, Mark Miesfeld <[email protected]> wrote: > On Fri, Apr 24, 2009 at 3:37 AM, Rick McGuire <[email protected]> wrote: > >> Ok, I've been able to reproduce Walter's bug. I was trying to >> reproduce this using the trunk build, but it fails when I run on the >> beta build. Curious, because this should be the same code still! > > I could reproduce it with the trunk build though. > > I got up early to let you know I saw what the problem was, but I > didn't quite know how to fix it. I'll have to look closely at where > you reset bufferedInput back to 0. > > What I didn't understand is that for the last stream init, the one > that produced the error, when the SysFile object was constructed, > bufferedInput is set to 0. But, when it got to _read() for the first > linein(), it was no longer at 0. I couldn't see how the sequence was > any different for that second file then it was for the first file. > Yet for the first file, when it got to that _read(), bufferedInput was > 0 as it needed to be. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensign option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
