[pypy-dev] Fatal RPython error: MemoryError

Armin Rigo arigo at tunes.org
Tue Aug 7 15:33:02 CEST 2012


Hi Ronny,

On Tue, Aug 7, 2012 at 1:56 PM, Ronny Pfannschmidt
<Ronny.Pfannschmidt at gmx.de> wrote:
> However in some cases (like the example) the memory error is caused by
> accumulating more and more smaller objects,
> in which case the memory one would use for a Stack-trace is used up and the
> extra pool would be used.

I'm quite unsure how you propose to do that.  We could have a reserve
pool that we activate when trying to print the fatal MemoryError, but
that doesn't really help: the normal stack trace cannot be even
*built* in memory, as it requires allocating PyTraceback objects.
That's the reason why the RPython traceback reported at the start of
this thread is so short: because all other levels in the stack caught
the RPython MemoryError, but failed very quickly when trying to handle
it, throwing *another* RPython MemoryError to the caller.

If you can come up with a more precise scheme, you're welcome.  The
issue is to know when it's ok to reserve from that pool and when we
should raise an RPython MemoryError instead.  A possible answer would
look like "when allocating internal vs user objects", for some
unspecified-yet distinction of internal vs user objects.


A bientôt,

Armin.


More information about the pypy-dev mailing list