Investigate segfault issue with stats

[kevyang]

@thinkingfish reported an issue where if a stats command is issued twice, a segfault occurs. Also, stats output is not terminated by "END\r\n"

[kevyang]

Saving this output for further reference:

$ lldb ./pelikan_twemcache ../template/twemcache.conf 
(lldb) target create "./pelikan_twemcache"
Current executable set to './pelikan_twemcache' (x86_64).
(lldb) settings set -- target.run-args  "../template/twemcache.conf"
(lldb) r
Process 25216 launched: './pelikan_twemcache' (x86_64)
load config from ../template/twemcache.conf
set up the ccommon::log module
Set up the ccommon::debug module
create logger with filename twemcache.log cap 4194304
create logger with filename twemcache.cmd cap 2097152
Process 25216 stopped
* thread #2: tid = 0x6e475e, 0x0000000100006550 pelikan_twemcache`reply_destroy_all(rep=0x0000000141e80e38) + 48 at reply.c:42, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x0000000100006550 pelikan_twemcache`reply_destroy_all(rep=0x0000000141e80e38) + 48 at reply.c:42
   39       struct reply *nr, *r = *rep;
   40   
   41       while (r != NULL) {
-> 42           nr = STAILQ_NEXT(r, next);
   43           reply_destroy(&r);
   44           r = nr;
   45       }
(lldb) bt
* thread #2: tid = 0x6e475e, 0x0000000100006550 pelikan_twemcache`reply_destroy_all(rep=0x0000000141e80e38) + 48 at reply.c:42, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x0000000100006550 pelikan_twemcache`reply_destroy_all(rep=0x0000000141e80e38) + 48 at reply.c:42
    frame #1: 0x0000000100003269 pelikan_twemcache`_admin_event(arg=0x0000000141c2c100, events=<unavailable>) + 969 at admin.c:197
    frame #2: 0x00000001000180dc pelikan_twemcache`event_wait(evb=0x0000000141d00600, timeout=<unavailable>) + 572 at cc_kqueue.c:291
    frame #3: 0x00000001000039a2 pelikan_twemcache`admin_evloop + 18 at admin.c:333
    frame #4: 0x0000000100003990 pelikan_twemcache`admin_evloop(arg=<unavailable>) + 16
    frame #5: 0x00007fff8ab6e899 libsystem_pthread.dylib`_pthread_body + 138
    frame #6: 0x00007fff8ab6e72a libsystem_pthread.dylib`_pthread_start + 137
    frame #7: 0x00007fff8ab72fc9 libsystem_pthread.dylib`thread_start + 13

[seppo0010]

you should attach a link to the commit/PR that fixed this @kevyang

[kevyang]

Yep sorry, I forgot. #61