X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 	tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY
X-Spam-Check-By: sourceware.org
X-Yahoo-SMTP: DF9INoyswBDT8O6W.pKjvSST2iQ-
Message-ID: <4BD88351.7090105@yahoo.com>
Date: Wed, 28 Apr 2010 11:49:53 -0700
From: Rob Donovan <hikerman2005-542731 AT yahoo DOT com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Jay K <jay DOT krell AT cornell DOT edu>
CC: cygwin <cygwin AT cygwin DOT com>
Subject: Re: Cygwin Maximum Memory Documentation
References: <1272411106 DOT 9772 DOT ezmlm AT cygwin DOT com> <COL101-W2442C3EC902156FF38B193E6030 AT phx DOT gbl>
In-Reply-To: <COL101-W2442C3EC902156FF38B193E6030@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

Looks like I posted too soon.=20=20

I can run SOME Cygwin/gcc programs up to 2.83GB with the changes I mentione=
d in my first post (yesterday), but not ALL programs (and not anything usef=
ul...).  The problem seems to be with Cygwin's implementation of disk acces=
s functions like fscanf() and fgets().  The following code as written here =
and compiled under gcc/Cygwin (with the gcc line commented out at the top) =
WILL run up to 2.83GB image size.  However, if the fscanf() line is uncomme=
nted the resulting program dies just above a 2GB image size with the error =
"*** fatal error - cmalloc would have returned NULL".  The file tmp contain=
s "hello.\n".  If the program is compiled with fscanf() uncommented using c=
l (Visual Studio C++ compiler - the 2nd compile line commented out below) t=
he program will run up to 2.83GB before it runs out of memory.  fgets() has=
 the same effect as fscanf().  I'm using Task Manager Mem Usage column to w=
atch the memory grow.

I also tested fprintf(stdout,...) strlen() sscanf() calloc() sprintf() fope=
n() fabs() fclose() strtok() strcmp() strdup() strspn() and free() all of w=
hich work fine up to 2.83GB.

My conclusion is that there's something in Cygwin's implementation of disk =
access functions (fscanf(), fgets(), ...?) that stops working when the proc=
ess image size goes over 2GB.  Since the /3GB switch enables user pointers =
above 7FFFFFFF my guess would be something like assumptions made about the =
most significant pointer bit.

/rob



#include <stdlib.h>
#include <stdio.h>

// to compile : gcc -g -Wall -Wpadded -Wl,--large-address-aware -o memory_e=
ater2.x memory_eater2.c
// to compile : cl memory_eater2.c winmm.lib /link /largeaddressaware

int main (int argc, char *argv[])
{
  FILE *f;
  char *buf;
  long c =3D 0;

  while (1 !=3D 2) {
=20=20=20=20=20=20=20=20
    if ((buf =3D (char *) calloc(24,sizeof(char))) =3D=3D NULL) {
      fprintf(stderr,"Problem in %s line %d allocating memory\n",__FILE__,_=
_LINE__);
      return(1);
    }

    c++;

    if ((c % 5000) =3D=3D 0) {

      if ((f =3D fopen("./tmp","r")) =3D=3D NULL) {
	fprintf(stderr,"Problem in %s line %d opening input file\n",__FILE__,__LIN=
E__);
	return(1);
      }

      // fscanf(f,"%s",buf);

      fclose(f);

    }

  }

  return(0);

}




=09=20=20



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple