This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: setrlimit()/C++ new() seg fault
- To: othman at cs dot wustl dot edu
- Subject: Re: setrlimit()/C++ new() seg fault
- From: Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>
- Date: 10 Nov 1999 16:50:47 -0000
- CC: gcc at gcc dot gnu dot org
- References: <199911101618.KAA24597@taumsauk.cs.wustl.edu>
Hello,
> I didn't know that RLIMIT_AS existed. Is it portable? It's not listed
> or mentioned in Richard Stevens' book "Advanced Programming in the UNIX
> Environment" so I assume that it is non-portable. Correct?
I don't know. On some systems it's called RLIMIT_VMEM or `virtual
memory limit'. Anyway, it's available on all my Unix systems.
> > There are several places in gcc/frame.c where malloc() is used without
> > checking for a NULL result, in this case it's
> [snip]
> > which sets the arrays to NULL and therefore you get the crash
> > shortly thereafter.
>
> I was too "scared" to look at the compiler source. :-)
>
> > I don't know whether it's possible or worthwhile to fix this.
>
> Out of curiosity, why would it not be worthwhile?
When operator new throws bad_alloc _and_ one cannot allocate these
relatively small chunks of memory via malloc(), it is to be assumed
that we're in deep trouble anyway, as very few applications are able
to do much without malloc() (even if the exception would get through
to the try block).
Anyway, if it can be fixed easily, I certainly think it should be
fixed.
Regards,
Wolfram.