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/[email protected]/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
