This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: setrlimit()/C++ new() seg fault
- To: wmglo at dent dot med dot uni-muenchen dot de
- Subject: Re: setrlimit()/C++ new() seg fault
- From: othman at cs dot wustl dot edu
- Date: Wed, 10 Nov 1999 10:22:30 -0600 (CST)
- cc: gcc at gcc dot gnu dot org
- Reply-To: othman at cs dot wustl dot edu
Hi Wolfram,
Thank you very much for your response.
On 10 Nov, Wolfram Gloger wrote:
> If you really want to prevent excessive memory allocation, the limit
> to set is RLIMIT_AS, not RLIMIT_DATA (as the latter can be easily
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?
> circumvented) but this has nothing to do with gcc.
Right.
> I can reproduce this. It seems that the mechanism to throw exceptions
> is depending on malloc() still working. If you reduce the data limit
> so low as you've done in your sample, then malloc() will always return
> NULL.
Okay, that makes sense. Thanks for the clarification.
> 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?
In any case, you've certainly answered my questions. Thanks so much for
your help!
-Ossama
--
Ossama Othman <othman@cs.wustl.edu>
Center for Distributed Object Computing, Washington University, St. Louis
58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26