Comment #1 on issue 387 by [email protected]: error of lru_crawler
https://code.google.com/p/memcached/issues/detail?id=387
Not sure yet how that happens. Were you able to catch it in a debugger and
print a bit more information around the crawler and LRU's?
cache_lock is held with it_flags is being set to 1, and also when it's set
to 0.. and the thread that checks for != 1 is the only place that can set
it to 0. So worst case the loop gets a false-negative and skips that lru's
crawler for that iteration.
crawler_link_q() is only ever called when it first kicks off a crawl.
the crawler isn't signaled until after all new crawlers are initialized,
and lru_crawler_lock is held for the entire time the crawler is active.
This possibly means that crawler_unlink_q() is failing sometimes? If the
crawler is left in the LRU, it will be ignored by the item alloc and could
fall to the tail. Once in the tail, and another crawl kicks off, it'll find
itself in the tail and fail that assert.
Don't see how unlink_q could fail though... maybe crawler_crawl_q() has a
bug that links the crawler to itself sometimes? So after it delinks it ends
up still in the queue.
Is this happening a lot? Or have you fixed it already? If not, how are you
getting it to trigger?
Would be useful to see the state of the lru that the bad crawler was in. Is
it the only item (both head and tail?), or was anything else in there?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
---
You received this message because you are subscribed to the Google Groups "memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
