dmesg, gdb and output could help 2011/7/13 <[email protected]>: > > Comment #16 on issue 99 by [email protected]: Memcached 1.4.2 server > segmentation fault > http://code.google.com/p/memcached/issues/detail?id=99 > > Hi, > > Thank you for checking in, and yes, I am still watching this ticket as it > still continues to be an issue for me. I manually apply my patch on every > upgrade to eliminate the "Segmentation fault". The patched memcached runs > indefinitely until it is manually restarted after a version upgrade (months > at a time). > > Here is the information you requested: > > memcached: 1.4.6-rc1 > OS: linux 32 bit > libevent: 2.0.12 > gcc: 4.4.4-r2 > kernel: 2.6.30-r8 > > I did a default build of memcached from the source downloaded from the > memcached repository. I was able to get a SIGSEGV from a single request > using the same test script included with the original bug filing (using a > new size of 524288): > > ./memcached -l localhost -vvv > slab class 1: chunk size 80 perslab 13107 > slab class 2: chunk size 104 perslab 10082 > slab class 3: chunk size 136 perslab 7710 > slab class 4: chunk size 176 perslab 5957 > slab class 5: chunk size 224 perslab 4681 > slab class 6: chunk size 280 perslab 3744 > slab class 7: chunk size 352 perslab 2978 > slab class 8: chunk size 440 perslab 2383 > slab class 9: chunk size 552 perslab 1899 > slab class 10: chunk size 696 perslab 1506 > slab class 11: chunk size 872 perslab 1202 > slab class 12: chunk size 1096 perslab 956 > slab class 13: chunk size 1376 perslab 762 > slab class 14: chunk size 1720 perslab 609 > slab class 15: chunk size 2152 perslab 487 > slab class 16: chunk size 2696 perslab 388 > slab class 17: chunk size 3376 perslab 310 > slab class 18: chunk size 4224 perslab 248 > slab class 19: chunk size 5280 perslab 198 > slab class 20: chunk size 6600 perslab 158 > slab class 21: chunk size 8256 perslab 127 > slab class 22: chunk size 10320 perslab 101 > slab class 23: chunk size 12904 perslab 81 > slab class 24: chunk size 16136 perslab 64 > slab class 25: chunk size 20176 perslab 51 > slab class 26: chunk size 25224 perslab 41 > slab class 27: chunk size 31536 perslab 33 > slab class 28: chunk size 39424 perslab 26 > slab class 29: chunk size 49280 perslab 21 > slab class 30: chunk size 61600 perslab 17 > slab class 31: chunk size 77000 perslab 13 > slab class 32: chunk size 96256 perslab 10 > slab class 33: chunk size 120320 perslab 8 > slab class 34: chunk size 150400 perslab 6 > slab class 35: chunk size 188000 perslab 5 > slab class 36: chunk size 235000 perslab 4 > slab class 37: chunk size 293752 perslab 3 > slab class 38: chunk size 367192 perslab 2 > slab class 39: chunk size 458992 perslab 2 > slab class 40: chunk size 573744 perslab 1 > slab class 41: chunk size 717184 perslab 1 > slab class 42: chunk size 1048576 perslab 1 > <31 server listening (auto-negotiate) > <32 send buffer was 107520, now 268435456 > <32 server listening (udp) > <32 server listening (udp) > <32 server listening (udp) > <32 server listening (udp) > <33 new auto-negotiating client connection > 33: going from conn_new_cmd to conn_waiting > 33: going from conn_waiting to conn_read > 33: going from conn_read to conn_parse_cmd > 33: Client using the ascii protocol > <33 set test 0 10 524288 > 33: going from conn_parse_cmd to conn_nread >> >> NOT FOUND test >> 33 STORED > > 33: going from conn_nread to conn_write > 33: going from conn_write to conn_new_cmd > 33: going from conn_new_cmd to conn_waiting > 33: going from conn_waiting to conn_read > <34 new auto-negotiating client connection > 33: going from conn_read to conn_closing > <33 connection closed. > 34: going from conn_new_cmd to conn_waiting > 34: going from conn_waiting to conn_read > 34: going from conn_read to conn_parse_cmd > 34: Client using the ascii protocol > <34 get test >> >> FOUND KEY test >> 34 sending key test >> 34 END > > 34: going from conn_parse_cmd to conn_mwrite > Segmentation fault > > --- > > After doing a clean build using the same patch file I provided you, the > daemon seems to be stable again (100 successful requests using the same test > script). Thanks for looking into this once more, and let me know if you > need additional information. > > thom > >
-- Roberto Spadim Spadim Technology / SPAEmpresarial
