bugs in `gc.get_referents()'

[Martin von Loewis]

> One thing I've figured out is that `gc.get_refer{ent,rer}s()' is
> using equality rather than identity testing.  I've opened a bug
> report on this: [1]

Good spotting. This is indeed a serious bug, which could explain a lot
of things. I recommend that you try the patch first to see whether any
of your observed problems go away with ot.

> That does not by itself explain the "wrong referrers reported"
> behaviour.

It might. What if the "wrong referrers" do indeed refer to objects
that compare equal to the referee? If they refer to an object that
compares equal to everything, then it is no surprise they show up in
every get_referrers result.

> Martin von Loewis suggested that "there is a bug in the C type of
> the tp_traverse function of [the bogus referrer] object", but this
> example shows that this must not be the explanation:
>
> >>> refs = gc.get_referents([1,[2.3,4,],5,6,[7,8,],[9,]])
> >>> len(refs)
> 8
> >>> refs[1]
> [<TCPCommsHandler.TCPCommsHandler at 0x85a474c>, <TCPCommsHandler.TCPCommsHandler listening :4052 at 0x85cdadc>]
>
> (I'm pretty sure there is no list anywhere in memory that equals
> that argument to `get_referents()'.)

If you get this result, it would indicate that the TCPCommsHandler is
indeed == to the list of odd numbers. Can you please try whether it
is?

> And by the way, the following two lines consistently segfault when
> used interactively in my running Mojo Nation app (although sometimes
> it takes a while to segfault):
>
> 
> >>> for i in xrange(2**20):
> >>>  refs = gc.get_referents({})

Again, this might go away with the patch. get_referents isn't supposed
to trigger a garbage collection. However, since we are invoking ==,
anything might happen. If a collection happens, and the object being
inspected gets collected (or if the generations get re-organized in
another funny way), then bad things may happen.

> Waiatasecond: if my native code forgets to DECREF, this can't
> possibly screw up the gcmodule!  There's absolutely no different
> between my native code forgetting to DECREF and my native code
> actually keeping a live reference (perhaps the only live reference)
> to an object.

Indeed. If you are saying that only a decref may be missing, and all
increfs are placed properly, then this would be no problem

> By the way I had a look at the implementation of `get_referrers()'
> and I agree that it is simple and looks right.

Except for the apparently-not-so-obvious bug that SequenceContains
will test for equality, not identity. For the moment, I'm willing to
blame everything on that bug :-)

Regards,
Martin