This is the mail archive of the
mailing list for the Cygwin project.
Re: 1.5.5-1: problem with read() on Athlon MP in WinXP
- From: Brian Ford <ford at vss dot fsi dot com>
- To: Jeff Gilchrist <jsgilchrist at hotmail dot com>
- Cc: cygwin at cygwin dot com
- Date: Tue, 9 Dec 2003 12:58:04 -0600 (CST)
- Subject: Re: 1.5.5-1: problem with read() on Athlon MP in WinXP
- References: <BAY2-F139W9F0qnqEBQ0001a7e3@hotmail.com>
It sounds like you may have two problems here, but this may be the first
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.
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html