Hi Armin, Harald,
On 08/07/2012 11:28 AM, Armin Rigo wrote:
Hi Harald,
On Tue, Aug 7, 2012 at 10:23 AM, Massa, Harald Armin<c...@ghum.de> wrote:
outside of programming there is the concept of having a secret backup
("nest egg"). Would'nt it be a solution to preallocate some bytes on
startup for really, really bad times?
It might help in general, but not in this case: this example causes
and catches multiple MemoryErrors. If you unveil your secret backup
at the first MemoryError, you gained nothing, because the crash occurs
only at the ~25th MemoryError.
I'm under the Impression that that Kind of Error could be evaded by
reserving a special part of the memory pool for strings and internal
objects *after* the general Pool is used up.
My assumption is that most of the time the Memory errors are caused
semi-large allocations/reallocation (like allocate or re-size a
list/array/matrix)
in which case there will still be some memory left to at least print a
stack-trace at interpreter level and quit.
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.
In that case i presume any allocation not needed for a trace would cause
just another memory error in the exception handler.
That should be able to handle most of the normal cases of people trying
to handle something and print out some extra information before failing
Its of course not safe from malicious code or
people just deliberately refusing to fail if there is a memory-error.
but really "evil" code is fine to receive a rpython traceback.
-- Ronny
A bientôt,
Armin.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
