Date: Fri, 20 Aug 1999 13:58:48 +0100 (BST) From: "Dr H. T. Leung" To: Oliver Jennrich cc: pgcc AT delorie DOT com Subject: Re: Something hogs memory... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 Precedence: bulk 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