On Sat, Apr 19, 2014 at 2:45 PM, dormando <[email protected]> wrote:

> > One machine was an i7 with TSX, thus the lock elision segfaults. The
> other is a much older Core2 machine. Enough differences there to cause
> > problems, especially if we are dealing with threading-type things?
>
> Can you give me a summary of what the core2 machine gave you? I've built
> on a core2duo and nehalem i7 and they all work fine. I've also torture
> tested it on a brand new 16 core (2x8) xeon.
>

I ran the test suite on the Core2 a number of times (at least 5). Sometimes
it completes without failure, other times I still get these two failures.
This is with `sleep 3` changed to `sleep 8`.

#   Failed test 'slab1 now has 60 used chunks'
#   at t/lru-crawler.t line 57.
#          got: '90'
#     expected: '60'

#   Failed test 'slab1 has 30 reclaims'
#   at t/lru-crawler.t line 59.
#          got: '0'
#     expected: '30'
# Looks like you failed 2 tests of 189.
t/lru-crawler.t ...... Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/189 subtests


>
> > On the i7 machine, I think we're still experiencing segfaults. Running
> just the LRU test; note the two "undef" values showing up again:
> >
>
> Ok. I might still be goofing the lock somewhere. Can you see if memcached
> is crashing at all during these tests? Inside the test script you can see
> it's just a few raw commands to copy/paste and try yourself.
>
> You can also use an environment variable to start a memcached external to
> the tests within a debugger:
>     if ($ENV{T_MEMD_USE_DAEMON}) {
>         my ($host, $port) = ($ENV{T_MEMD_USE_DAEMON} =~
> m/^([^:]+):(\d+)$/);
>
> T_MEMD_USE_DAEMON="127.0.0.1:11211" or something, I think. haven't used
> that in a while.
>
>
Simple repro, running standalone, no other commands have been issued:
$ nc localhost 11211
lru_crawler enable
OK
lru_crawler crawl 1
OK
lru_crawler disable

SIGSEGV happens, here is the backtrace (surprised to see it in
start_thread...):

(gdb) bt
#0  0x00007ffff79881c8 in __lll_unlock_elision () from
/usr/lib/libpthread.so.0
#1  0x00007ffff7982fc7 in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#2  0x0000000000414f61 in item_crawler_thread (arg=<optimized out>) at
items.c:771
#3  0x00007ffff797f0a2 in start_thread () from /usr/lib/libpthread.so.0
#4  0x00007ffff76b4d1d in clone () from /usr/lib/libc.so.6

It does NOT segfault if you run enable immediately followed by disable,
with no `crawl 1` in between.

-- 

--- 
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.

Reply via email to