Date:	Fri, 20 Aug 1999 13:58:48 +0100 (BST)
From:	"Dr H. T. Leung" <htl10 AT cus DOT cam DOT ac DOT uk>
To:	Oliver Jennrich <oliver DOT jennrich AT colorado DOT edu>
cc:	pgcc AT delorie DOT com
Subject:	Re: Something hogs memory...
In-Reply-To:	<m3672bk6aq.fsf@onehertz.Colorado.EDU>
Message-ID:	<Pine.SOL.3.96.990820133808.4247D-100000@ursa.cus.cam.ac.uk>
MIME-Version:	1.0
X-MIME-Autoconverted:	from QUOTED-PRINTABLE to 8bit by delorie.com id IAA25951
Reply-To:	pgcc AT delorie DOT com
X-Mailing-List:	pgcc AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

That reminds me of a curious thing with egcs-compiled curl 5.0/5.2 binary
sigmentation-faulting with an assignment like this

> config.useragent= "curl/" CURL_VERSION " (" OS CURL_SSL")"; 

and the problem was fixed by 

> config.useragent= strdup("curl/" CURL_VERSION " (" OS CURL_SSL")"); 

While gcc 2.7.x was perfectly happy with the former. I think your problem
was probably related. See the curl mailing list archive for entries under
my name in December 1998 towards the top in: 

http://curl.haxx.nu/archive-pre_5_10/

On 19 Aug 1999, Oliver Jennrich wrote:

> 
> Hi folks,
> 
> first of all, I'm not on the list, so any 'cc:' to me would be greatly
> appreciated.
> 
> I think I discovered a bug, although I'm not sure that it is *really*
> a pgcc bug, but then, gcc.486 does not show this behaviour.
> 
> It is kind of complicated because it involves NAG's Fortran95 (no it
> is *not* their bug). The string concatenation hogs memory. This is
> easily demonstrated by the following code:
> 
> Program MEMTEST
>   !
>   !  Shows a memory leak when compiled with NAG f95 compiler.
>   !
>   use f90_unix_env
>   use f90_unix_proc
>   !
>   character                :: command*32, text,dummy*32
>   integer                  :: pid
>   !
>   open(8,file='/dev/null')
>   pid=getpid()                       ! get process ID
>   write(command,'(i10)') pid
>   command='ps vp '//command
>   do n=1,100
>      write(8,*) 'sample ',n
>      do i=1,10000
>         text=' '                       
>         text=trim(text)//' abc'      ! HOG
>         write(8,'(a)') text
>      end do
>      if (n == 1) call system(command) ! memory after first inner loop
>   end do
>   call system(command)               ! memory after last inner loop
>   !
> end program memtest
> 
> Depending on the existence of the line marked 'HOG' the program
> allocates huge amounts of mem.
> 
> With HOG:
>   PID TTY STAT TIME  PAGEIN TSIZ DSIZ  RSS   LIM %MEM COMMAND
> 29144  ?  S    0:00     155   32 1343  536    xx  0.4 ./memtest 
>   PID TTY STAT TIME  PAGEIN TSIZ DSIZ  RSS   LIM %MEM COMMAND
> 29144  ?  S    0:04     155   32 5211 4404    xx  3.4 ./memtest 
> 
> Without HOG:
>   PID TTY STAT TIME  PAGEIN TSIZ DSIZ  RSS   LIM %MEM COMMAND
> 29155  ?  S    0:00     123   31 1304  492    xx  0.3 ./memtest 
>   PID TTY STAT TIME  PAGEIN TSIZ DSIZ  RSS   LIM %MEM COMMAND
> 29155  ?  S    0:02     123   31 1304  492    xx  0.3 ./memtest 
> 
> You might argue that this is not a bug at all, but then, using the
> gcc.486 as the C-Compiler NAG_f95 uses, it becomes:
> 
>   PID TTY STAT TIME  PAGEIN TSIZ DSIZ  RSS   LIM %MEM COMMAND
> 29166  ?  S    0:00     126   31 1304  504    xx  0.3 ./memtest 
>   PID TTY STAT TIME  PAGEIN TSIZ DSIZ  RSS   LIM %MEM COMMAND
> 29166  ?  S    0:04     126   31 1304  504    xx  0.3 ./memtest 
> 
> with and without the HOG-line.
> 
> For those of you not familiar with Fortran-syntax: '//' concatenates
> strings, much as strcat() does.
> 
> The compilers in question are:
> gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)
> and
> gcc version 2.7.2.3  
> 
> If it is of any help I can provide anyone with the preprocessed
> .i-Files andør the preprocessed C files, f95 produces.
> 
> 
> 
> -- 
> Oliver Jennrich		JILA, University of Colorado @ Boulder
> 
> Gravity. It's not just a good idea, it's the law!
> 

          --------------------------------------------------
"What you don't care cannot hurt you."            Chap. 7a, AMS-NS

- Raw text -