[Varnish] #684: Varnish 2.1.1 hangs with critbit enabled

Varnish varnish-bugs at varnish-cache.org
Thu Apr 22 10:17:46 CEST 2010


#684: Varnish 2.1.1 hangs with critbit enabled
----------------------+-----------------------------------------------------
 Reporter:  dormando  |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 I'm able to run varnish 2.1.x with critbit as the default hash table for
 1-15 minutes, then a full thread hang happens.

 combined thread stack:

    6011
    5844
 __lll_lock_wait,_L_lock_106,pthread_mutex_lock,Lck__Lock,hcb_lookup,HSH_Lookup,cnt_lookup,CNT_Session,wrk_do_cnt_sess,wrk_thread_real,start_thread,clone
     153
 writev,WRW_Flush,WRW_FlushRelease,RES_WriteObj,cnt_deliver,CNT_Session,wrk_do_cnt_sess,wrk_thread_real,start_thread,clone
       3
 __lll_lock_wait,_L_lock_106,pthread_mutex_lock,Lck__Lock,hcb_deref,HSH_DerefObjCore,cnt_miss,CNT_Session,wrk_do_cnt_sess,wrk_thread_real,start_thread,clone
       1
 pthread_cond_wait@@GLIBC_2.3.2,Lck_CondWait,wrk_herder_thread,start_thread,clone
       1
 poll,CLS_Poll,CLI_Run,child_main,start_child,mgt_sigchld,vev_sched_signal,vev_schedule,MGT_Run,main
       1 nanosleep,TIM_sleep,wrk_herdtimer_thread,start_thread,clone
       1 nanosleep,TIM_sleep,vca_sess_timeout_ticker,start_thread,clone

 Most are locked within HSH_Lookup

 example full backtrace:
 #0  0x00007f225f328e74 in __lll_lock_wait () from /lib64/libpthread.so.0
 #1  0x00007f225f324874 in _L_lock_106 () from /lib64/libpthread.so.0
 #2  0x00007f225f3242e0 in pthread_mutex_lock () from
 /lib64/libpthread.so.0
 #3  0x0000000000421e19 in Lck__Lock (lck=<value optimized out>, p=0x44d0f8
 "hcb_lookup", f=0x44ce1b "hash_critbit.c", l=454)
     at cache_lck.c:78
 #4  0x000000000042e820 in hcb_lookup (sp=<value optimized out>,
 noh=0x7f1476804a20) at hash_critbit.c:454
 #5  0x000000000041cb51 in HSH_Lookup (sp=0x7f148f09b008,
 poh=0x7f15103e6798) at cache_hash.c:345
 #6  0x0000000000411b10 in cnt_lookup (sp=0x7f148f09b008) at
 cache_center.c:786
 #7  0x0000000000413f90 in CNT_Session (sp=0x7f148f09b008) at steps.h:38
 #8  0x0000000000424a78 in wrk_do_cnt_sess (w=0x7f15103f9e60, priv=<value
 optimized out>) at cache_pool.c:294
 #9  0x0000000000423d5d in wrk_thread_real (qp=0x7f225ea0b2e0,
 shm_workspace=<value optimized out>, sess_workspace=65536,
     nhttp=64, http_space=<value optimized out>, siov=128) at
 cache_pool.c:183
 #10 0x00007f225f322367 in start_thread () from /lib64/libpthread.so.0
 #11 0x00007f225ebfdf7d in clone () from /lib64/libc.so.6

 Running with `-h classic` is running much longer so far.

 nothing in the varnish stats or params looks off. vcl is identical to
 working(ish) 2.0 series aside from the obj->beresp replacement.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/684>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator




More information about the varnish-bugs mailing list