It doesn't make any sense that it'd actually hang there. There's a loop
in process_command, but given the arguments I see are getting passed
into that function, I don't see any way that would loop either.
Is this something you can catch in the act, or is your stack trace from
a core file? If you're catching it live, I'd be very interested in
seeing what it looks like if you single-step through the code, stepping
until it gets back to wherever you interrupted it (assuming there's an
infinite loop going on here). Looking at the 1.1.12 code I don't see how
it could get stuck but obviously it can since you're seeing it!
This is not something we have ever seen on any version of memcached to
my knowledge.
-Steve
Dean Michael C. Berris wrote:
Hi Everyone,
I've attached the backtrace of the part where the memcached instance is
hanging, which has been encountered by a previous poster
(http://tinyurl.com/2da8nk).
#0 0x0804bfa5 in item_unlink_q (it=0x40e9bd08) at items.c:153
#1 0x0804c470 in item_unlink (it=0x40e9bd08) at items.c:180
#2 0x0804ae43 in process_command (c=0x808e9b8,
command=0x809d8f0 "get 38004118") at memcached.c:628
#3 0x0804b143 in try_read_command (c=0x808e9b8) at memcached.c:770
#4 0x0804b42e in drive_machine (c=0x808e9b8) at memcached.c:870
#5 0x0804b8eb in event_handler (fd=12, which=2, arg=0x808e9b8)
at memcached.c:1112
#6 0x40026b34 in event_process_active (base=0x808ad60) at event.c:256
#7 0x40026d9a in event_base_loop (base=0x808ad60, flags=0) at
event.c:370
#8 0x40026c23 in event_loop (flags=0) at event.c:305
#9 0x08049f6d in main (argc=12, argv=0xbfffde34) at memcached.c:1543
I'd like to ask whether this is already considered a known issue with
1.1.12, and whether this has been fixed in a later release. I've been
looking at the Changes for 1.2.1, and I haven't seen anything relating
to this issue.
Advice and insights would be most appreciated.
--
Dean Michael Berris
<[EMAIL PROTECTED]>
Mobile: +639287291459
YMID: mikhailberis
