Mail Archives: pgcc/1999/08/21/12:03:56
Yes, if you had followed the url for the Curl mailing list, you would have
read that the initial quick-and-dirty fix for getting a non-seg-faulting
binary with egcs (1.1.x, x=1 or 2, can't remember) was to comment out a
"free *" somewhere. But then the gcc 2.7.x-compiled binary doesn't mind
one or the other, and that indicates that egcs 1.1.x deals with (memory
assignment of) string functions slightly differently than gcc 2.7.x.
On Fri, 20 Aug 1999, David Ford wrote:
> Just a note, in the below, you would certainly get a segfault if you
> attempted to free the assignment later.
>
> -d
>
> "Dr H. T. Leung" wrote:
>
> > 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!
- Raw text -