It sounds like you may have two problems here, but this may be the first one:
http://cygwin.com/cygwin-ug-net/using-textbinary.html On Tue, 9 Dec 2003, Jeff Gilchrist wrote: > I have a simple C program that reads in a file using the read() function, > then outputs the data to stdout so if you redirect stdout to a file, the end > result is that you have made a copy of the original. For some reason on > certain files, it does not work on one of my systems. I will attach the .c > code that I used. I also changed the malloc()/free to a new/delete and > compiled with g++ to see if it made a difference but I get the same result. > > The problem is that even though I ask read() to read in enough bytes to get > the entire file, the function will always return that it read in one byte > less than what I requested. If I ask to read 100 bytes in a 1000 byte file, > it will return that it read 99 bytes. If I ask it to read 1000 bytes from > the same 1000 byte file, it will return that it read 999 bytes, etc... > In my case, the test file I am working with is 99931 bytes long and read() > returns that it read 99930 bytes. If I then output that buffer to stdout, > printing one character at a time to stdout, it will for some reason print > out 100139 bytes instead of 99931 bytes (so an extra 208 bytes). Looking at > the stream, the extra 208 bytes are repeated from the last 208 bytes of the > file and a few other characters throughout are different so the buffer is > obviously getting corrupted somehow. > > The system I am running this on is a dual processor AMD Athlon MP-2600+ > machine with 1GB of RAM on Windows XP Pro (with all security patches). > > Now it gets even stranger. Taking two other machines a P4-1.8GHz running > Win2k and a P4-1.4GHZ also running Win2k, the program will compile and run > just fine with the exact same cygwin install (I used the same files to > install cygwin on all 3 machines). The program works as expected on these > single processor P4 machines. I can take the program compiled on the Athlon > and run it on the P4 and it works fine. I can take the program compiled no > the P4 but when I run it on the Athlon it behaves the exact same way as > listed above, it does not output the correct data. > > So it seems that cygwin on my Athlon is compiling the C code fine because I > can run it without any problems on my P4/Win2k boxes. The only time I have > had problems is when I run it on the Athlon. > > So are we seeing a cygwin problem with the Athlon processor? Is it a > dual-processor problem? Is it a WinXP problem? Since it seems the > memory/buffer gets corrupted I ran memtest86 and the GIMPS torture test on > my Athlon machine but both checked out ok. I haven't had any other problems > with software not working properly or things getting corrupted. The cygwin > tools that get bundled seem to work fine (ie: bzip2) so I really don't know > what is going on. Any ideas? > > If you need more info, let me know and I will provide. > cygcheck output from the failing machine is generally useful. Please see http://www.cygwin.com/problems.html for details. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
