[Python-Dev] Crash in new "trashcan" mechanism.

[Christian Tismer]

Vladimir Marangozov wrote:
> 
> Christian Tismer wrote:
> >
> > Vladimir Marangozov wrote:

[yup, good looking patch]

> where _PyTrash_deposit_object returns 0 on success, -1 on failure. This
> gives another last chance to the system to finalize the object, hoping
> that the stack won't overflow. :-)
> 
> My point is that it is better to control whether _PyTrash_deposit_object
> succeeds or not (and it may fail because of PyList_Append).
> If this doesn't sound acceptable (because of the possible stack overflow)
> it would still be better to abort in _PyTrash_deposit_object with an
> exception "stack overflow on recursive finalization" when PyList_Append
> fails. Leaving it unchecked is not nice -- especially in such extreme
> situations.

You bet that I *would* raise an exception if I could. Unfortunately
the destructors have no way to report an error, and they are
always called in a context where no error is expected (Py_DECREF macro).

I believe this *was* quite ok, until __del__ was introduced.
After that, it looks to me like a design flaw.
IMHO there should not be a single function in a system that needs heap
memory, and cannot report an error.

> Currently, if something fails, the object is not finalized (leaking
> memory). Ok, so be it. What's not nice is that this happens silently
> which is not the kind of tolerance I would accept from the Python runtime.

Yes but what can I do? This isn't worse than before. deletion errors
die silently, this is the current concept. I don't agree with it,
but I'm not the one to change policy. In that sense, trashcan
was just compliant to a concept, without saying this is a good concept. :-)

> As to the bug: it's curious that, as Mark reported, without the trashcan
> logic, things seem to run fine. The trashcan seems to provoke (ok, detect ;)
> some erroneous situation. I'd expect that if the trashcan macros are
> implemented as above, the crash will go away (which wouldn't solve the
> problem and would obviate the trashcan in the first place :-)

I think trashcan can be made *way* smarter:

Much much more better would be to avoid memory allocation
in trashcan at all. I'm wondering if that would be possible.
The idea is to catch a couple of objects in an earlier recursion
level, and use them as containers for later objects-to-be-deleted.
Not using memory at all, that's what I want. And it would
avoid all messing with errors in this context.

I hate Java dieing silently, since it has not enough memory
to tell me that it has not enough memory :-)

but-before-implementing-this-*I*-will-need-to-become-*way*-smarter - 
   ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com