Hi Ronny, On Tue, Aug 7, 2012 at 1:56 PM, Ronny Pfannschmidt <ronny.pfannschm...@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. _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
