Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Jeff Gilchrist" <jsgilchrist AT hotmail DOT com>
To: cygwin AT cygwin DOT com
Subject: 1.5.5-1: problem with read() on Athlon MP in WinXP
Date: Tue, 09 Dec 2003 13:41:24 -0500
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_40d8_64d2_6c44"
Message-ID: <BAY2-F139W9F0qnqEBQ0001a7e3@hotmail.com>
Note-from-DJ: This may be spam

------=_NextPart_000_40d8_64d2_6c44
Content-Type: text/plain; format=flowed

I have a very strange problem using the 1.5.5-1 cygwin so I wanted to post 
the information in case someone has seen this before on another system.

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.

I tried compiling with several different gcc switches to see if it made a 
difference but I get the same result every time.  I used:
gcc test.c -o test
gcc -O3 test.c -o test
gcc -g test.c -o test

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.

Thanks in advance,
Jeff.

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*   
http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca

------=_NextPart_000_40d8_64d2_6c44
Content-Type: application/octet-stream; name="test.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test.c"

I2luY2x1ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVk
ZSA8c3RkbGliLmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KCmludCBtYWluKGlu
dCBhcmdjLCBjaGFyKiBhcmd2W10pCnsKCWNoYXIgKkZpbGVEYXRhID0gTlVM
TDsKCXN0cnVjdCBzdGF0IHN0YXRidWY7Cgl1bnNpZ25lZCBpbnQgZmlsZVNp
emUgPSAwOwoJdW5zaWduZWQgaW50IGk7CglpbnQgaEluZmlsZSA9IC0xOwoJ
aW50IHJldCA9IC0xOwoJCgkvLyByZWFkIGZpbGUKCWhJbmZpbGUgPSBvcGVu
KCJ0ZXN0LmRhdCIsIE9fUkRPTkxZKTsKCS8vIGNoZWNrIHRvIHNlZSBpZiBm
aWxlIGV4aXN0cyBiZWZvcmUgcHJvY2Vzc2luZwoJaWYgKGhJbmZpbGUgPT0g
LTEpCgl7CgkJcmV0dXJuIC0xOwoJfQoJLy8gZ2V0IHNpemUgb2YgZmlsZQoJ
ZnN0YXQoaEluZmlsZSwgJnN0YXRidWYpOwoJZmlsZVNpemUgPSBzdGF0YnVm
LnN0X3NpemU7CgoJRmlsZURhdGEgPSAoY2hhciAqKSBtYWxsb2MoZmlsZVNp
emUpOwoKCXJldCA9IHJlYWQoaEluZmlsZSwgKGNoYXIgKikgRmlsZURhdGEs
IGZpbGVTaXplKTsKCgljbG9zZShoSW5maWxlKTsKCQoJZm9yIChpPTA7IGkg
PCByZXQ7IGkrKykKCQlwcmludGYoIiVjIiwgRmlsZURhdGFbaV0pOwoJCQoJ
ZnJlZShGaWxlRGF0YSk7CgoJcmV0dXJuIDA7Cn0K


------=_NextPart_000_40d8_64d2_6c44
Content-Type: text/plain; charset=us-ascii

--
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/
------=_NextPart_000_40d8_64d2_6c44--