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

[Christian Tismer]

Mark Hammond wrote:
> 
> > Can you perhaps tell me what the call stack says?
> > Is it somewhere, or are we in finalization code of the
> > interpreter?
> 
> The crash is in _Py_Dealloc - op is a pointer, but all fields
> (ob_type, ob_refcnt, etc) are all 0 - hence the crash.
> 
> Next up is list_dealloc - op is also trashed - ob_item != NULL
> (hence we are in the if condition, and calling Py_XDECREF() (which
> triggers the _Py_Dealloc) - ob_size ==9, but all other fields are 0.
> 
> Next up is Py_Dealloc()
> 
> Next up is _PyTrash_Destroy()
> 
> Next up is frame_dealloc()
> 
> _Py_Dealloc()
> 
> Next up is eval_code2() - the second last line - Py_DECREF(f) to
> cleanup the frame it just finished executing.
> 
> Up the stack are lots more eval_code2() - we are just running the
> code - not shutting down or anything.

And you do obviously not have any threads, right?
And you are in the middle of a simple, heavy computing
application. Nothing with GUI events happening?

That can only mean there is a bug in the Python core or in
the parser module. That happens to be exposed by trashcan,
but isn't trashcan's fault.

Well. Trashcan might change the order of destruction a little.
This *should* not be a problem. But here is a constructed
situation where I can think of a problem, if we have
buggy code, somewhere:

Assume you have something like a tuple that holds other elements.
If there is a bug, like someone is dereferencing an argument
in an arg tuple, what is always an error.
This error can hide for a million of years:

a contains (b, c, d)

The C function decref's a first, and erroneously then also one
of the contained elements. If b is already deallotted by
decreffing a, it has refcount zero, but that doesn't hurt,
since the dead object is still there, and no mallcos have
taken place (unless there is a __del__ trigered of course).

This eror would never be detected.
With trashcan, it could happen that destruction of a is
deferred, but by chance now the delayed erroneous decref of b
might happen before a's decref, and there may be mallocs
in between, since I have a growing list.

If my code is valid (and it appears so), then I guess
we have such a situation somewhere in the core code.

I-smell-some-long-nightshifts-again - 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