delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/12/09/13:58:34

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs
Date: Tue, 9 Dec 2003 12:58:04 -0600 (CST)
From: Brian Ford <ford AT vss DOT fsi DOT com>
X-X-Sender: ford AT eos
To: Jeff Gilchrist <jsgilchrist AT hotmail DOT com>
cc: cygwin AT cygwin DOT com
Subject: Re: 1.5.5-1: problem with read() on Athlon MP in WinXP
In-Reply-To: <BAY2-F139W9F0qnqEBQ0001a7e3@hotmail.com>
Message-ID: <Pine.GSO.4.58.0312091254400.28297@eos>
References: <BAY2-F139W9F0qnqEBQ0001a7e3 AT hotmail DOT com>
MIME-Version: 1.0

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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019