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<chef@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