Loop-detection in assoc_find..
dormando at rydia.net
Thu Apr 24 19:20:41 UTC 2008
Trond and I actually spotted a ton of the refcount leaks last night
(well trond discovered them;). At my next opportunity I'll be posting a
patch which should fix most/all of them.
We're still a bit stumped as to the assoc_find bug, I'll post as much
information as I can once I get a chance, but I'm not sure at all how it
gets that way.
Looks like it can re-associate an item back into a hash bucket right
after evicting it? But maybe not? This bug is likely an incredibly
simple one-liner we just can't figure out how to reproduce. I wrote a
bunch of hash bucket torture tests and ran them for several days. No dice.
If there're any devs working on the binary protocol still, we should
probably drop everything and look at this assoc_find bug. It hits very,
very few people but it exists and we should fix it now.
That + refcount and I'll cut a 1.2.6 in short order.
Miguel DeAvila wrote:
> On Friday 18 April 2008 13:25:38 Trond Norbye wrote:
>> We have had some discussions lately about a loop in assoc_find, and
>> since we currently haven't been able to reproduce this problem in our
>> test environment I think that we should add loop detection into the
>> assoc_find routine.
>> The following is a patch (for the binary branch) that implements this.
> I don't think the patch is sufficient. The loop that I encountered involved three
> items (A -> B -> C -> A) ... the patch only detects loops between adjacent items.
> Also, the 'expanding' variable was false (at least in the core file that I have).
> Lastly ... not sure if this is related, but we also seem to have a out-of-memory/refcount-leak
> (see this thread http://email@example.com/msg02871.html )
> We definitely have servers though that suffer from the out-of-memory errors that don't hang
> in assoc_find, so I'm not sure if they are related.
> Let me know if there is anything I can do to help.
More information about the memcached