[Jim]
>>> From a purely theoretical point of view, the current behavior is
>>> wrong.
[Tim]
>> It is, but a segfault is more than just pure theory <wink>.
[Jim]
> I don't know what your point is here.
I didn't know what you were trying to communicate by "From a purely
theoretical point of view". That's all. A segault isn't a theoretical nit,
it's a serious bug. Your phrasing appeared to imply that it wasn't a
serious bug ("wrong" is synonymous with "bug" to me here).
> ...
> I thought that tp_clear was called to break cycles.
Yes.
> Surely, if a class is in a cycle, there are references to it.
Yes.
> Why would one assume that none of these references are instances?
I don't think anyone is assuming that. The assumption is that nobody will
*access* the class's MRO slot again. That's not the same as assuming there
are no instances. It may be in part be a bad assumption that dead instances
can't execute any methods ever again, fed by that gc refuses to break cycles
if an object in the cycle contains a __del__ method. If weakrefs supply
another path for executing from the grave, then the problem is deeper than
the patch addresses.
> ...
> Surely, the original intent is top break something. ;)
> I'd much rather get an attribute error than a segfault or an
> equally fatal C assertion error.
My goal on Python-Dev isn't just to stop Zope3 from segfaulting, feeding it
mysterious AttributeErrors instead. That may be good enough for your
current purposes, but it leaves the language in a still-sickly state.
For example, I've suggested here before that the second call of gc from
finalization may be a bad idea in general, because the interpreter is in a
damaged (largely torn-down) state at that time. That would address a larger
class of shutdown problems, and Zope isn't unique in seeing new shutdown
problems under 2.3.2 (there have been other reports on c.l.py, but so far
only of the "weird information-free msgs from threads at shutdown" flavor
that we first saw in the Zope3 test suite, before cleaning up the stale
threads).
But we don't understand *this* problem well enough yet, and you raised the
real possibility that this one can bite before shutdown. In that case a
robust fix necessarily costs more than just commenting out the second gc
call (which, all by itself, would have been enough to stop your segfaults so
far too).
>> Which assertion fails then? That may be a good clue toward truly
>> understanding what's causing this.
> The assertion that mro is not NULL. :)
LOL -- that shed a lot of light <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4