Loop-detection in assoc_find..

[dormando]

Crap :)

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.

-Dormando

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://www.mail-archive.com/memcached@lists.danga.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.
> 
> regards,
> 
> Miguel