From varnish-bugs at projects.linpro.no  Wed Sep  2 08:07:02 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 02 Sep 2009 08:07:02 -0000
Subject: [Varnish] #549: Crash on vertical tab
Message-ID: <054.ecb7af4b265bc425dab802eeb6c3209f@projects.linpro.no>

#549: Crash on vertical tab
----------------------+-----------------------------------------------------
 Reporter:  kristian  |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 To reproduce, set this as backend:

  echo -e 'HTTP/1.1 200 OK\v\r\n\r\nTest' | nc -l 8133
  (or whatever port)

 backtrace (no assert in trunk at the moment, due to sigseg-on-assert):
 {{{
 (gdb) bt full
 #0  0x00007ffe73938d06 in getframeaddr (level=<value optimized out>) at
 execinfo.c:324
 No locals.
 #1  0x00007ffe7393f1c8 in backtrace (buffer=<value optimized out>,
 size=10) at execinfo.c:65
         i = 2
 #2  0x0000000000422ae5 in pan_ic (func=<value optimized out>, file=<value
 optimized out>, line=<value optimized out>,
     cond=<value optimized out>, err=0, xxx=<value optimized out>) at
 cache_panic.c:273
         l = <value optimized out>
         p = <value optimized out>
         q = 0x0
         sp = <value optimized out>
 #3  0x000000000042129d in http_DissectResponse (w=0x7ffdb0865400,
 htc=<value optimized out>, hp=0x7ffdb0865b78) at cache.h:710
         i = 503
         __func__ = "http_DissectResponse"
 #4  0x000000000041a86d in FetchHdr (sp=0x7ffe6a108008) at
 cache_fetch.c:392
         w = <value optimized out>
         b = 0x7ffe6a10886d "localhost:8081"
         hp = <value optimized out>
         i = 1
         __func__ = "FetchHdr"
 #5  0x0000000000412566 in cnt_fetch (sp=0x7ffe6a108008) at
 cache_center.c:423
         i = <value optimized out>
         transient = <value optimized out>
         hp = <value optimized out>
         hp2 = <value optimized out>
         b = <value optimized out>
         handling = <value optimized out>
         __func__ = "cnt_fetch"
 #6  0x0000000000413ca5 in CNT_Session (sp=0x7ffe6a108008) at steps.h:41
         done = 0
         w = (struct worker *) 0x7ffdb0865400
         __func__ = "CNT_Session"
 #7  0x00000000004240e3 in wrk_do_cnt_sess (w=0x7ffdb0865400, priv=<value
 optimized out>) at cache_pool.c:281
         sess = (struct sess *) 0x7ffe6a108008
         __func__ = "wrk_do_cnt_sess"
 #8  0x0000000000424416 in wrk_thread_real (qp=0x7ffe729200b0,
 shm_workspace=<value optimized out>, sess_workspace=16384)
     at cache_pool.c:176
         ww = {magic = 1670491599, nobjhead = 0x0, nobjcore = 0x0, stats =
 0x7ffdb08653f0, lastused = 1251878643.4236326, cond = {
     __data = {__lock = 0, __futex = 2, __total_seq = 1, __wakeup_seq = 1,
 __woken_seq = 1, __mutex = 0x7ffe72924348, __nwaiters = 0,
       __broadcast_seq = 0},
     __size =
 "\000\000\000\000\002\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000HC\222r?\177\000\000\000\000\000\000\000\000\000",
 __align = 8589934592}, list = {vtqe_next = 0x7ffdb1066400,
 ---Type <return> to continue, or q <return> to quit---
     vtqe_prev = 0x7ffe729200c0}, wrq = 0x7ffe6a108198, wfd = 0x0, werr =
 0, iov = {{iov_base = 0x7ffe6a108828, iov_len = 3}, {
       iov_base = 0x44a824, iov_len = 1}, {iov_base = 0x7ffe6a10882c,
 iov_len = 1}, {iov_base = 0x44a824, iov_len = 1}, {
       iov_base = 0x449a7b, iov_len = 8}, {iov_base = 0x448ada, iov_len =
 2}, {iov_base = 0x7ffe6a108867, iov_len = 20}, {
       iov_base = 0x448ada, iov_len = 2}, {iov_base = 0x7ffe6a10887d,
 iov_len = 47}, {iov_base = 0x448ada, iov_len = 2}, {
       iov_base = 0x7ffdb085f3b0, iov_len = 21}, {iov_base = 0x448ada,
 iov_len = 2}, {iov_base = 0x7ffdb085f3c6, iov_len = 26}, {
       iov_base = 0x448ada, iov_len = 2}, {iov_base = 0x448ada, iov_len =
 2}, {iov_base = 0x0, iov_len = 0} <repeats 49 times>}, niov = 0,
   liov = 0, vcl = 0x0, wlb = 0x7ffdb08633c0 "\r", wlp = 0x7ffdb08633da "",
 wle = 0x7ffdb08653c0 "", wlr = 1, sha256ctx = 0x7ffdb0866070,
   htc = {{magic = 1041886673, fd = 13, ws = 0x7ffdb08658f0, rxbuf = {b =
 0x7ffdb085f3e1 "HTTP/1.1 200 OK\v\r\n\r\nTest\n",
         e = 0x7ffdb085f3f5 "Test\n"}, pipeline = {b = 0x7ffdb085f3f5
 "Test\n", e = 0x7ffdb085f3fa ""}}}, ws = {{magic = 905626964,
       id = 0x44a992 "wrk", s = 0x7ffdb085f3b0 "X-Varnish: 1792453121", f =
 0x7ffdb085f3fa "", r = 0x0, e = 0x7ffdb08633b0 "",
       overflow = 0}}, http = {{magic = 1680389577, ws = 0x7ffdb08658f0,
 conds = 0 '\0', logtag = HTTP_Tx, status = 0, protover = 0, hd = {
         {b = 0x7ffe6a108828 "GET", e = 0x7ffe6a10882b ""}, {b =
 0x7ffe6a10882c "/", e = 0x7ffe6a10882d ""}, {b = 0x449a7b "HTTP/1.1",
           e = 0x449a83 ""}, {b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, {b =
 0x7ffe6a108867 "Host: localhost:8081", e = 0x7ffe6a10887b ""}, {
           b = 0x7ffe6a10887d "User-Agent: lwp-request/5.818 libwww-
 perl/5.820", e = 0x7ffe6a1088ac ""}, {
           b = 0x7ffdb085f3b0 "X-Varnish: 1792453121", e = 0x7ffdb085f3c5
 ""}, {b = 0x7ffdb085f3c6 "X-Forwarded-For: 127.0.0.1",
           e = 0x7ffdb085f3e0 ""}, {b = 0x0, e = 0x0} <repeats 23 times>},
 hdf = '\0' <repeats 31 times>, nhd = 9}, {magic = 1680389577,
       ws = 0x7ffdb08658f0, conds = 0 '\0', logtag = HTTP_Rx, status = 503,
 protover = 0, hd = {{b = 0x0, e = 0x0}, {b = 0x0, e = 0x0}, {
           b = 0x7ffdb085f3e1 "HTTP/1.1 200 OK\v\r\n\r\nTest\n", e =
 0x7ffdb085f3e9 " 200 OK\v\r\n\r\nTest\n"}, {
           b = 0x7ffdb085f3ea "200 OK\v\r\n\r\nTest\n", e = 0x7ffdb085f3ed
 " OK\v\r\n\r\nTest\n"}, {
           b = 0x7ffdb085f3ee "OK\v\r\n\r\nTest\n", e = 0x0}, {b = 0x0, e =
 0x0} <repeats 27 times>}, hdf = '\0' <repeats 31 times>,
       nhd = 5}, {magic = 0, ws = 0x0, conds = 0 '\0', logtag = 0, status =
 0, protover = 0, hd = {{b = 0x0, e = 0x0} <repeats 32 times>},
       hdf = '\0' <repeats 31 times>, nhd = 0}}, bereq = 0x7ffdb0865928,
 beresp1 = 0x0, beresp = 0x7ffdb0865b78, resp = 0x0,
   cacheable = 0, age = 0, entered = 0, ttl = 0, grace = 0, do_esi = 0}
         sha256 = {state = {0, 0, 0, 0, 0, 0, 0, 0}, count = 0, buf = '\0'
 <repeats 63 times>}
         stats = {n_object = 0, n_objecthead = 1}
         stats_clean = 1
         __func__ = "wrk_thread_real"
 #9  0x00007ffe733013ba in start_thread () from /lib/libpthread.so.0
 No symbol table info available.
 #10 0x00007ffe72bcefcd in clone () from /lib/libc.so.6
 No symbol table info available.
 #11 0x0000000000000000 in ?? ()
 No symbol table info available.
 }}}

 Confirmed on trunk and 2.0.4

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/549>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  2 09:08:25 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 02 Sep 2009 09:08:25 -0000
Subject: [Varnish] #549: Crash on vertical tab
In-Reply-To: <054.ecb7af4b265bc425dab802eeb6c3209f@projects.linpro.no>
References: <054.ecb7af4b265bc425dab802eeb6c3209f@projects.linpro.no>
Message-ID: <063.d928b20b5961b22408efc6829e72bb56@projects.linpro.no>

#549: Crash on vertical tab
----------------------+-----------------------------------------------------
 Reporter:  kristian  |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 (In [4221]) Be much more paranoid about control-characters in backend
 responses.

 Fixes #549

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/549#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  2 21:05:58 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 02 Sep 2009 21:05:58 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.8453579f2b2eed9b04307925f9cc8644@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 We are now using varnish with file cache, but we still see explosive
 memory usage (temporary cache storage?)

 {{{
 1.5 GiB +   1.2 MiB =   1.5 GiB       /usr/local/varnish/sbin/varnishd -P
 /var/run/varnish_xxx.pid -a :xxx -f
 /usr/local/varnish/etc/varnish/xxx.xxx.xxx.vcl -T :xxx -s
 file,/usr/local/varnish/var/varnish/xxx/cache.pool,5G -i xxx -n
 /usr/local/varnish/var/varnish/xxx -p thread_pools 4 -p lru_interval 1800
 (2)
 }}}

 Server above is running +/- 15 minutes and caches only (larger) photos
 (150MB/s).

 Does varnish keep populair objects in shared memory?

 Also tried to build against jemalloc and even tried google's tcmalloc
 (thread safe malloc), but both didn't make much difference.


 P.S. Linpro didnt respond to my mails. So im doing a fallback to the
 community ;-)

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:13>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  2 21:10:33 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 02 Sep 2009 21:10:33 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.889c7d64ea12253ebc264c3e19812e32@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 P.S.

 Also changed from stable to trunk version:
 {{{
 varnishd (varnish-trunk SVN 4218)
 Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS
 }}}
 revision of this morning.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:14>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  2 21:20:26 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 02 Sep 2009 21:20:26 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.2d11605d869a8bb507f2efbf4f83ff5e@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 To be very clear (and to spam this ticket :P)....
 We are not doing 150kb/s in cache!

 http://img200.imageshack.us/img200/5404/graphimage.png

 The first 2 gaps in the graph are reboots (because varnish was using the
 complete swap file), the 3th gap is a restart of varnish.


 What im a bit tring to say....
 I dont know what your testing platforms are, but do you guys also test
 with so much traffic pushing through the server?

 Regards.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:15>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  2 22:11:53 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 02 Sep 2009 22:11:53 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.f782e26db8079b53579a709129686a43@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by kb):

 You're telling Varnish to use 5GB, and you're surprised it's using 1.5GB?
 Or are you surprised that it's using 5-6GB?  The latter is expected -- 5GB
 is simply the object cache, not other necessary in-memory structures
 (including pthread stack allocation -- try adding "ulimit -s 1024" to your
 start script).  PHK's explanation is concise.

 If they're using too much RAM for your box, decrease your instances' -s
 parameters until they fit.  Unless you're seeing a resident memory size of
 1.5-2x your -s argument, there's nothing wrong here, IMHO.

 Varnish has been used flawlessly over *much* heavier traffic than yours,
 if that's what you're asking.
 --
 Ken

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:16>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Sep  3 06:28:56 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 03 Sep 2009 06:28:56 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.d73eb1da5ed4618fb53275572f16eb01@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 Thank you for the reply.

 I was a bit supprised it used 1.5GB while the storage is file based. The
 reason i uponed up this ticket was because varnish used 5.8GB shared mem,
 while the storage was 2G malloc. The instance from yesterday is a
 different one. But if varnish itself uses a lot shared memory for
 stack/thread allocations, it is explainable why it uses so much (its not
 the malloc who is using so much memory, but rather varnish itself).

 ulimit is a option to use, although i think its a dirty one.

 Its nice to hear varnish is capable of dealing with much more traffic.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:17>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Sep  3 06:35:31 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 03 Sep 2009 06:35:31 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.eba68356e146cf8d3f06728af675c7a1@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 What i meant was this:

 {{{
   7.1 GiB +   1.2 MiB =   7.1 GiB       /usr/local/varnish/sbin/varnishd
 -P /var/run/varnish_xxx.pid -a :xxx -f
 /usr/local/varnish/etc/varnish/xxx.xxx.xxx.vcl -T :xxx -s
 file,/usr/local/varnish/var/varnish/xxx/cache.pool,5G -i xxx -n
 /usr/local/varnish/var/varnish/xxx -p thread_pools 4 -p lru_interval 1800
 }}}

 It is using 7.1G and using diskcache as backend. If i used malloc here, my
 server would be swapping big time.

 This is without the ulimit.
 Going to try out now...

 To be continued

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:18>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Sep  3 16:03:44 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 03 Sep 2009 16:03:44 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.fe57913872cfef6852dd9e9e5d5312db@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 I restarted the servers this morning with the proposed ulimit's.
 But after a couple of hours it's still eating up my memory.

 ulimit's i set before in the init scripts (right before the start of
 varnishd)
 {{{
 ulimit -l 82000
 ulimit -s 1024
 ulimit -n 131072
 }}}

 After a couple of hours:
 {{{
  Private  +  Shared  =  RAM used        Program

 484.3 MiB +  81.1 MiB = 565.4 MiB       /usr/local/varnish/sbin/varnishd
 -P /var/run/varnish_xxx.pid -a :xxx -f
 /usr/local/varnish/etc/varnish/xxx.xxx.xxx.vcl -T :xxx -s
 file,/usr/local/varnish/var/varnish/xxx/cache.pool,1G -i xxx -n
 /usr/local/varnish/var/varnish/xxx -p thread_pools 4 -p lru_interval 1800
 (2)
 605.0 MiB +  81.1 MiB = 686.1 MiB       /usr/local/varnish/sbin/varnishd
 -P /var/run/varnish_yyy.pid -a :yyy -f
 /usr/local/varnish/etc/varnish/yyy.yyy.yyy.vcl -T :yyy -s
 file,/usr/local/varnish/var/varnish/yyy/cache.pool,1G -i yyy -n
 /usr/local/varnish/var/varnish/yyy -p thread_pools 4 -p lru_interval 1800
 (2)
   1.7 GiB +   1.1 MiB =   1.7 GiB       /usr/local/varnish/sbin/varnishd
 -P /var/run/varnish_zzz.pid -a :zzz -f
 /usr/local/varnish/etc/varnish/zzz.zzz.zzz.vcl -T :zzz -s
 file,/usr/local/varnish/var/varnish/zzz/cache.pool,512m -i zzz -n
 /usr/local/varnish/var/varnish/zzz -p thread_pools 4 -p lru_interval 1800
 (2)
   5.3 GiB +   1.1 MiB =   5.3 GiB       /usr/local/varnish/sbin/varnishd
 -P /var/run/varnish_aaa.pid -a :aaa -f
 /usr/local/varnish/etc/varnish/aaa.aaa.aaa.vcl -T :aaa -s
 file,/usr/local/varnish/var/varnish/aaa/cache.pool,5G -i aaa -n
 /usr/local/varnish/var/varnish/aaa -p thread_pools 4 -p lru_interval 1800
 (2)
  12.2 GiB +   1.0 MiB =  12.2 GiB       /usr/local/varnish/sbin/varnishd
 -P /var/run/varnish_bbb.pid -a :bbb -f
 /usr/local/varnish/etc/varnish/bbb.bbb.bbb.vcl -T :bbb -s
 file,/usr/local/varnish/var/varnish/bbb/cache.pool,3G -i bbb -n
 /usr/local/varnish/var/varnish/bbb -p thread_pools 4 -p lru_interval 1800
 (2)

  Private  +  Shared  =  RAM used        Program
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:19>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Sep  4 01:25:03 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 04 Sep 2009 01:25:03 -0000
Subject: [Varnish] #550: varnish fails to start
Message-ID: <054.ae38316f6d56cef376ccd851e72e5aa3@projects.linpro.no>

#550: varnish fails to start
----------------------+-----------------------------------------------------
 Reporter:  rainer_d  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:     
Component:  varnishd  |     Version:  2.0
 Severity:  normal    |    Keywords:     
----------------------+-----------------------------------------------------
 srv3# /usr/local/sbin/varnishd -d -P /var/run/varnishd.pid -a myip:80 -f
 /usr/local/etc/varnish/default.vcl -T 127.0.0.1:6082 -s file,/var/tmp,50%
 -u www -g www
 NB: Storage size limited to 2GB on 32 bit architecture,
 NB: otherwise we could run out of address space.
 storage_file: filename: /var/tmp/varnish.gNKFLo (unlinked) size 2047 MB.
 Using old SHMFILE
 New Pid 51239

 Debugging mode, enter "start" to start child
 child (51780) Started
 Pushing vcls failed: CLI communication error
 Child (51780) said Closed fds: 4 5 7 8 11 12 14 15
 Child (51780) said Child starts
 Child (51780) said managed to mmap 1917042688 bytes of 2147467264
 Child (51780) said Ready
 k 1 rev 17


 This is on FreeBSD7.2 i386

 Is there a problem with the vcl file?


 backend site {
 .host = "www.site.com";
 .port = "80";
 }

 sub vcl_recv {
         if (req.http.host ~ "^.site.com$") {
                 set req.backend = site;
         }
 }

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/550>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Sep  4 13:16:46 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 04 Sep 2009 13:16:46 -0000
Subject: [Varnish] #551: Varnish Crash: Missing errorhandling code in
	HSH_Prepare(), cache_hash.c line 188
Message-ID: <054.929506018381bcb32841815315546cac@projects.linpro.no>

#551: Varnish Crash: Missing errorhandling code in HSH_Prepare(), cache_hash.c
line 188
----------------------+-----------------------------------------------------
 Reporter:  cheerios  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:     
Component:  varnishd  |     Version:  2.0
 Severity:  normal    |    Keywords:     
----------------------+-----------------------------------------------------
 Varnish 2.0.4 on Debian Etch after roughly two weeks online.

 {{{
 Sep  4 07:28:33 db varnishd[22396]: Child (19965) died signal=6
 Sep  4 07:28:44 db varnishd[22396]: Child (19965) Panic message: Missing
 errorhandling code in HSH_Prepare(), cache_hash.c line 188:
 Condition((p) != 0) not true.  thread = (cache-worker)sp = 0x2aaaeb2e9008
 {   fd = 136, id = 136, xid = 1575450717,   client = 64.255.180.72:43707,
 step = STP_LOOKUP,   handling = hash,   ws = 0x2aaaeb2e9078 { overflow
 id = "sess",     {s,f,r,e} = {0x2aaaeb2e9808,,+16333,(nil),+16384},   },
 worker = 0x7686bc80 {     },     vcl = {       srcname = {
 "input",         "Default",       },     }, },
 Sep  4 07:28:44 db varnishd[22396]: Child cleanup complete
 Sep  4 07:28:46 db varnishd[22396]: child (16741) Started
 Sep  4 07:28:46 db varnishd[22396]: Pushing vcls failed: CLI communication
 error
 Sep  4 07:28:46 db varnishd[22396]: Child (16741) said Closed fds: 4 5 6
 10 11 13 14
 Sep  4 07:28:46 db varnishd[22396]: Child (16741) said Child starts
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/551>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sat Sep  5 09:48:50 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 05 Sep 2009 09:48:50 -0000
Subject: [Varnish] #550: varnish fails to start
In-Reply-To: <054.ae38316f6d56cef376ccd851e72e5aa3@projects.linpro.no>
References: <054.ae38316f6d56cef376ccd851e72e5aa3@projects.linpro.no>
Message-ID: <063.59f46fedb51504badbf8113b3e62e6df@projects.linpro.no>

#550: varnish fails to start
----------------------+-----------------------------------------------------
 Reporter:  rainer_d  |        Owner:  phk
     Type:  defect    |       Status:  new
 Priority:  normal    |    Milestone:     
Component:  varnishd  |      Version:  2.0
 Severity:  normal    |   Resolution:     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by whocares):

 I found that on 32bit systems varnish cannot use the whole 2GB. Thus you
 might want to play with your command line a bit, like for example

   /usr/local/sbin/varnishd -d -P /var/run/varnishd.pid -a myip:80 -f
 /usr/local/etc/varnish/default.vcl -T 127.0.0.1:6082 -s
 file,/var/tmp,'''1.4G''' -u www -g www

 If that works, increase the '''1.4G''' up to the point where varnish stops
 working again.

 hth,
 Stefan

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/550#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sun Sep  6 12:27:29 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sun, 06 Sep 2009 12:27:29 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.71fe762aaacbaa0c9dc9656c6648ed16@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 {{{
   3.9 GiB +   1.0 MiB =   3.9 GiB       /usr/local/varnish/sbin/varnishd
 -P /var/run/varnish_xxx.pid -a :xxx -f
 /usr/local/varnish/etc/varnish/xxx.xxx.xxx.vcl -T :xxx -s
 file,/usr/local/varnish/var/varnish/xxx/cache.pool,512m -i xxx -n
 /usr/local/varnish/var/varnish/xxx -p thread_pools 4 -p lru_interval 1800
 (2)

  Private  +  Shared  =  RAM used        Program
 }}}

 This service is running now for about 2 days...
 Is it expected behavior that it consumes almost 4G while it is using the
 disc cache backend (this process is running with the ulimit commands)

 Reagards...

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:20>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sun Sep  6 12:37:25 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sun, 06 Sep 2009 12:37:25 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.3405f054d3ae58df113f620f04e8fecd@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 P.S. Above instance is serving only static js & css.
 All files together on the source server are about 256M.
 Expire headers on the source server are set at request time + 8 hours and
 nothing fancy is done within the vcl.

 Varnish is serving these files with +/- 250 requests / second, having
 99,9% hit rate.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:21>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep  7 06:03:07 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 07 Sep 2009 06:03:07 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.f23971ab3e26c9164d48ead1f2ed3ac7@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 And after a day it is using 3.5G memory again.... (dispite the ulimit's
 and diskcache)

 I'll keep the service running today. Contact me by mail if you'll like to
 see it with your own eye's (i can provide a limited shell env for those
 who contact me with a linpro email address).

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:22>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep  8 10:50:03 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 08 Sep 2009 10:50:03 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.1888241ce4bda11b1d3a1fd11bac6b89@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 Could there be also an reply to my ticket?

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:23>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep  8 10:56:56 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 08 Sep 2009 10:56:56 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.ce05da709060ad8d4f00c9b25f269656@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by phk):

 I wish I had something sensible to reply...

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:24>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep  8 20:43:39 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 08 Sep 2009 20:43:39 -0000
Subject: [Varnish] #551: Varnish Crash: Missing errorhandling code in
	HSH_Prepare(), cache_hash.c line 188
In-Reply-To: <054.929506018381bcb32841815315546cac@projects.linpro.no>
References: <054.929506018381bcb32841815315546cac@projects.linpro.no>
Message-ID: <063.4db010e05eae890dad231cd8b0992bd2@projects.linpro.no>

#551: Varnish Crash: Missing errorhandling code in HSH_Prepare(), cache_hash.c
line 188
----------------------+-----------------------------------------------------
 Reporter:  cheerios  |        Owner:  phk
     Type:  defect    |       Status:  new
 Priority:  normal    |    Milestone:     
Component:  varnishd  |      Version:  2.0
 Severity:  normal    |   Resolution:     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by kb):

 Just saw this myself on a long-running Varnish process:

 {{{
 #!html
 Sep  7 17:30:34 statcache1 varnishd[30482]: Child (30483) Panic message:
 Missing errorhandling code in HSH_Prepare(), cache_hash.c line 188:
 Condition((p) != 0) not true.  thread = (cache-worker)sp = 0x7f9df03c0008
 {   fd = 5, id = 5, xid = 3735384183,   client = 10.40.201.13:33005,
 step = STP_LOOKUP,   handling = lookup,   err_code = 204, err_reason =
 (null),   ws = 0x7f9df03c0078 { overflow     id = "sess",     {s,f,r,e} =
 {0x7f9df03c0808,,+16362,(nil),+16384},   }, worker = 0x449f8be0 {     },
 vcl = {       srcname = { "input",    "Default",         "my.vcl",     },
 }, },
 }}}

 {{{
 #0  0x00007f9e032c1095 in raise () from /lib/libc.so.6
 #1  0x00007f9e032c2af0 in abort () from /lib/libc.so.6
 #2  0x000000000041b7f7 in pan_ic (func=<value optimized out>, file=<value
 optimized out>, line=<value optimized out>,
     cond=<value optimized out>, err=0, xxx=<value optimized out>) at
 cache_panic.c:317
 #3  0x00000000004162b6 in HSH_Prepare (sp=0x7f9df03c0008, nhashcount=3) at
 cache_hash.c:188
 #4  0x000000000040fc47 in cnt_lookup (sp=0x7f9df03c0008) at
 cache_center.c:592
 #5  0x00000000004113bc in CNT_Session (sp=0x7f9df03c0008) at steps.h:38
 #6  0x000000000041ce11 in wrk_do_cnt_sess (w=0x449f8be0, priv=<value
 optimized out>) at cache_pool.c:398
 #7  0x000000000041c4cb in wrk_thread (priv=0x7f9e0310c1a0) at
 cache_pool.c:310
 #8  0x00007f9e03a913f7 in start_thread () from /lib/libpthread.so.0
 #9  0x00007f9e03366b3d in clone () from /lib/libc.so.6
 #10 0x0000000000000000 in ?? ()
 }}}

 Session workspace overflow?

 Ken

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/551#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  9 07:43:41 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 09 Sep 2009 07:43:41 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.e88e9bbc3278e029c6dd5c2f432ecdb9@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 And this is service you wish me to pay for?

 * I would like to pay, i read all mails regarding to it. I replied to it,
 but never got any answer from it.
 * I have a problem with the product. I ask for support but none is given
 (becaus you guys cant replicate it). Because of this i offer a user
 account on my server to check it out yourself, but that messages is
 ignored...

 What do you want?
 Deliver a good product with decent service and get paid for it? Or a half
 baked product without any profit and maybe some early adopting users?

 Is it possible to get a phone number (from sales) who i can call (and a
 GMT time when i can call to it)?

 Regards

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:25>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  9 07:57:31 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 09 Sep 2009 07:57:31 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.fe1bc6846149c79de699bb3d1df2e7ec@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by phk):

 If you want to get a support/service contract, contact Redpill-Linpro
 (http://www.redpill-linpro.no) they can provide that.

 This however, is the bug-tracking system for the Varnish project, where we
 try to help people as best we can, with the resources we have.

 When I wrote "I wish I had something sensible to reply..." I meant: I have
 no idea what is causing this, and right now, I do not have time to log
 into your system and hunt it down.

 If there is a bug, of course it will be fixed, but finding a bug like
 this, in an application that pushes 111GB in no time, is not trivial.

 Or, as the old saloon sign says:  "Don't shoot the programmer, he's coding
 the best he can"

 Poul-Henning

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:26>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  9 08:09:01 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 09 Sep 2009 08:09:01 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.488d2d66e2300cd52367a8a085d70740@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by tfheen):

 Hi,

 I've checked the mail records and it seems like you should have gotten a
 reply from Jan William Haagensen on Friday 28 August, can you make sure it
 hasn't ended up in a spam filter somewhere?  Or, feel free to contact him
 on +47 21 54 41 14 during daytime hours

 Regards,
 Tollef Fog Heen

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:27>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  9 10:14:37 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 09 Sep 2009 10:14:37 -0000
Subject: [Varnish] #548: Sig 11 crash in trunk 4199
In-Reply-To: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no>
References: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no>
Message-ID: <061.34bc051a8854cb22a5da7601cfb65b1b@projects.linpro.no>

#548: Sig 11 crash in trunk 4199
---------------------------------------------+------------------------------
 Reporter:  anders                           |        Owner:  phk                
     Type:  defect                           |       Status:  new                
 Priority:  normal                           |    Milestone:  Varnish 2.1 release
Component:  varnishd                         |      Version:  trunk              
 Severity:  normal                           |   Resolution:                     
 Keywords:  sig 11 segmentation fault trunk  |  
---------------------------------------------+------------------------------
Changes (by kristian):

  * milestone:  => Varnish 2.1 release

Comment:

 This is a semi-wellknown issue... The backtrace code is bugged, so when
 varnish throws an assert, it all breaks. While this is a real bug that
 should be fixed, the error/assert triggering this is on frame 4:

 #4  0x000000000041b2b5 in HSH_Lookup (sp=0x822acf008, poh=0x7fffbe5ee1e0)

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/548#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  9 10:23:01 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 09 Sep 2009 10:23:01 -0000
Subject: [Varnish] #551: Varnish Crash: Missing errorhandling code in
	HSH_Prepare(), cache_hash.c line 188
In-Reply-To: <054.929506018381bcb32841815315546cac@projects.linpro.no>
References: <054.929506018381bcb32841815315546cac@projects.linpro.no>
Message-ID: <063.09d14e3de2d155a2d26dcf4d5479e79c@projects.linpro.no>

#551: Varnish Crash: Missing errorhandling code in HSH_Prepare(), cache_hash.c
line 188
----------------------+-----------------------------------------------------
 Reporter:  cheerios  |        Owner:  phk
     Type:  defect    |       Status:  new
 Priority:  normal    |    Milestone:     
Component:  varnishd  |      Version:  2.0
 Severity:  normal    |   Resolution:     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by kristian):

 You're indeed running out of session workspace. Normally this is solved by
 increasing the sess_workspace parameter.

 Are you doing ESI or string modification in VCL?

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/551#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  9 10:53:02 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 09 Sep 2009 10:53:02 -0000
Subject: [Varnish] #548: Sig 11 crash in trunk 4199
In-Reply-To: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no>
References: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no>
Message-ID: <061.85dd48dbd201c26d14d7ef2d92e2d404@projects.linpro.no>

#548: Sig 11 crash in trunk 4199
---------------------------------------------+------------------------------
 Reporter:  anders                           |        Owner:  phk                
     Type:  defect                           |       Status:  new                
 Priority:  normal                           |    Milestone:  Varnish 2.1 release
Component:  varnishd                         |      Version:  trunk              
 Severity:  normal                           |   Resolution:                     
 Keywords:  sig 11 segmentation fault trunk  |  
---------------------------------------------+------------------------------
Comment (by anders):

 Some lines around line 506:

 {{{
         if (oc != NULL) {
                 o = oc->obj;
                 CHECK_OBJ_NOTNULL(o, OBJECT_MAGIC);

                 /* We found an object we like */
                 o->refcnt++;
                 if (o->hits < INT_MAX)
                         o->hits++;
                 assert(oh->refcnt > 1);
                 Lck_Unlock(&oh->mtx);
                 assert(hash->deref(oh));
                 *poh = oh;
                 return (oc);
         }
 }}}

 It is "CHECK_OBJ_NOTNULL(o, OBJECT_MAGIC)" which is line 506.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/548#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep  9 10:57:48 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 09 Sep 2009 10:57:48 -0000
Subject: [Varnish] #548: Sig 11 crash in trunk 4199
In-Reply-To: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no>
References: <052.8d61fb47426264944c0cfe079ff0aa0c@projects.linpro.no>
Message-ID: <061.0acfc9b8a5c5ea843103d9aa13793efc@projects.linpro.no>

#548: Sig 11 crash in trunk 4199
---------------------------------------------+------------------------------
 Reporter:  anders                           |        Owner:  phk                
     Type:  defect                           |       Status:  new                
 Priority:  normal                           |    Milestone:  Varnish 2.1 release
Component:  varnishd                         |      Version:  trunk              
 Severity:  normal                           |   Resolution:                     
 Keywords:  sig 11 segmentation fault trunk  |  
---------------------------------------------+------------------------------
Comment (by anders):

 PHK wanted this from frame 4:

 {{{
 (gdb) print *oc
 $1 = {magic = 1294996226, obj = 0x0, objhead = 0xf4ed9fe80,
   timer_when = 1251973909.2994871, flags = 0 '\0', timer_idx = 0, list = {
     vtqe_next = 0x0, vtqe_prev = 0xf4ed9fe98}, lru_list = {
     vtqe_next = 0xf4edb88e0, vtqe_prev = 0x8010450c8}, smp_seg = 0x0,
   ban = 0x0}
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/548#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Sep 11 14:45:44 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 11 Sep 2009 14:45:44 -0000
Subject: [Varnish] #305: 2.0 beta1 cannot be built on MacOSX
In-Reply-To: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no>
References: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no>
Message-ID: <061.31b381a316b805619c688e7c71831fc8@projects.linpro.no>

#305: 2.0 beta1 cannot be built on MacOSX
---------------------+------------------------------------------------------
 Reporter:  191919   |        Owner:  des                      
     Type:  defect   |       Status:  reopened                 
 Priority:  normal   |    Milestone:  Varnish 2.0 code complete
Component:  build    |      Version:  trunk                    
 Severity:  blocker  |   Resolution:                           
 Keywords:           |  
---------------------+------------------------------------------------------
Changes (by rebel):

  * status:  closed => reopened
  * resolution:  fixed =>

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/305#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Sep 11 14:46:46 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 11 Sep 2009 14:46:46 -0000
Subject: [Varnish] #305: 2.0 beta1 cannot be built on MacOSX
In-Reply-To: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no>
References: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no>
Message-ID: <061.1f7a60fb6d415ca08b1418c5c9109122@projects.linpro.no>

#305: 2.0 beta1 cannot be built on MacOSX
---------------------+------------------------------------------------------
 Reporter:  191919   |        Owner:  des                      
     Type:  defect   |       Status:  reopened                 
 Priority:  normal   |    Milestone:  Varnish 2.0 code complete
Component:  build    |      Version:  trunk                    
 Severity:  blocker  |   Resolution:                           
 Keywords:           |  
---------------------+------------------------------------------------------
Comment (by rebel):

 http://varnish.projects.linpro.no/ticket/305

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/305#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Sep 11 14:50:09 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 11 Sep 2009 14:50:09 -0000
Subject: [Varnish] #305: 2.0 beta1 cannot be built on MacOSX
In-Reply-To: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no>
References: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no>
Message-ID: <061.b0b933f50587050468ad8ed3b895df55@projects.linpro.no>

#305: 2.0 beta1 cannot be built on MacOSX
---------------------+------------------------------------------------------
 Reporter:  191919   |        Owner:  des                      
     Type:  defect   |       Status:  reopened                 
 Priority:  normal   |    Milestone:  Varnish 2.0 code complete
Component:  build    |      Version:  trunk                    
 Severity:  blocker  |   Resolution:                           
 Keywords:           |  
---------------------+------------------------------------------------------
Comment (by rebel):

 http://varnish.projects.linpro.no/ticket/305

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/305#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Sep 11 14:50:47 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 11 Sep 2009 14:50:47 -0000
Subject: [Varnish] #305: 2.0 beta1 cannot be built on MacOSX
In-Reply-To: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no>
References: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no>
Message-ID: <061.b56f3b167e6f3ced06167f3bf69d6b8b@projects.linpro.no>

#305: 2.0 beta1 cannot be built on MacOSX
---------------------+------------------------------------------------------
 Reporter:  191919   |        Owner:  des                      
     Type:  defect   |       Status:  reopened                 
 Priority:  normal   |    Milestone:  Varnish 2.0 code complete
Component:  build    |      Version:  trunk                    
 Severity:  blocker  |   Resolution:                           
 Keywords:           |  
---------------------+------------------------------------------------------
Comment (by rebel):

 []http://varnish.projects.linpro.no/ticket/305

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/305#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep 14 09:13:00 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 14 Sep 2009 09:13:00 -0000
Subject: [Varnish] #552: Varnish 2.0.1 crash
Message-ID: <052.15b3509d5d3b728508c1b2905852dd93@projects.linpro.no>

#552: Varnish 2.0.1 crash
----------------------+-----------------------------------------------------
 Reporter:  maka01    |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 Just had varnishd crash on me. I think his has happened before. This is
 Varnish 2.0.1 though, so it's not the latest version. But still, it's an
 issue.

 Sep 14 10:40:02 xxx varnishd[3128]: Child (3129) died signal=6
 Sep 14 10:40:02 xxx varnishd[3128]: Child (3129) Panic message: Assert
 error in http_StatusMessage(), cache_http.c line 150:   Condition(status
 >= 100 && status <= 999)
  not true.  thread = (cache-worker)sp = 0x2aaec7953008 {   fd = 32, id =
 32, xid = 655816107,   client = xxx:xxx,   step = STP_FETCH,   handling =
 PASS,   ws
  = 0x2aaec7953078 {      id = "sess",     {s,f,r,e} =
 {0x2aaec79537b0,,+32,(nil),+8192},   },     worker = 0x7a072cb0 {     },
 vcl = {       srcname = {         "/opt
 /varnish/etc/varnish/xxx.vcl",         "Default",       },     },   obj =
 0x2aaaad16b000 {     refcnt = 1, xid = 655816107,     ws = 0x2aaaad16b028
 {        id = "obj",
      {s,f,r,e} = {0x2aaaad16b358,,0x2aaaad16b358,(nil),+7336},     },
 http = {       ws = 0x2aaaad16b028 {          id = "obj",
 {s,f,r,e} = {0x2aaaad16b358,,0
 x2aaaad16b358,(nil),+7336},       },     },     len = 0,     store = {
 },   }, },
 Sep 14 10:40:02 xxx varnishd[3128]: Child cleanup complete
 Sep 14 10:40:02 xxx varnishd[3128]: child (17247) Started

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/552>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep 14 11:00:06 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 14 Sep 2009 11:00:06 -0000
Subject: [Varnish] #552: Varnish 2.0.1 crash
In-Reply-To: <052.15b3509d5d3b728508c1b2905852dd93@projects.linpro.no>
References: <052.15b3509d5d3b728508c1b2905852dd93@projects.linpro.no>
Message-ID: <061.878830c5cea2b2aaebbd590057a2221b@projects.linpro.no>

#552: Varnish 2.0.1 crash
----------------------+-----------------------------------------------------
 Reporter:  maka01    |        Owner:  phk  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  varnishd  |      Version:  trunk
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by maka01):

 I got another crash right now:

 Sep 14 12:44:17 xxx varnishd[3128]: Child (17247) Panic message: Assert
 error in http_StatusMessage(), cache_http.c line 150:   Condition(status
 >= 100 && status <= 999) not true.  thread = (cache-worker)sp =
 0x2aaec497f008 {   fd = 668, id = 668, xid = 906828176,   client =
 xxx:xxx,   step = STP_FETCH,   handling = PASS,   ws = 0x2aaec497f078 {
 id = "sess",     {s,f,r,e} = {0x2aaec497f7b0,,+32,(nil),+8192},   },
 worker = 0x49010cb0 {     },     vcl = {       srcname = {
 "/opt/varnish/etc/varnish/xxx.vcl",         "Default",       },     },
 obj = 0x2aaab790a000 {     refcnt = 1, xid = 906828176,     ws =
 0x2aaab790a028 {        id = "obj",       {s,f,r,e} =
 {0x2aaab790a358,,0x2aaab790a358,(nil),+7336},     },     http = {       ws
 = 0x2aaab790a028 {          id = "obj",         {s,f,r,e} =
 {0x2aaab790a358,,0x2aaab790a358,(nil),+7336},       },     },     len = 0,
 store = {     },   }, },

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/552#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep 14 11:03:53 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 14 Sep 2009 11:03:53 -0000
Subject: [Varnish] #552: Varnish 2.0.1 crash
In-Reply-To: <052.15b3509d5d3b728508c1b2905852dd93@projects.linpro.no>
References: <052.15b3509d5d3b728508c1b2905852dd93@projects.linpro.no>
Message-ID: <061.35f562e44533fa1137be7afbaf3aecfb@projects.linpro.no>

#552: Varnish 2.0.1 crash
----------------------+-----------------------------------------------------
 Reporter:  maka01    |        Owner:  phk      
     Type:  defect    |       Status:  closed   
 Priority:  normal    |    Milestone:           
Component:  varnishd  |      Version:  trunk    
 Severity:  normal    |   Resolution:  duplicate
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => duplicate

Old description:

> Just had varnishd crash on me. I think his has happened before. This is
> Varnish 2.0.1 though, so it's not the latest version. But still, it's an
> issue.
>
> Sep 14 10:40:02 xxx varnishd[3128]: Child (3129) died signal=6
> Sep 14 10:40:02 xxx varnishd[3128]: Child (3129) Panic message: Assert
> error in http_StatusMessage(), cache_http.c line 150:   Condition(status
> >= 100 && status <= 999)
>  not true.  thread = (cache-worker)sp = 0x2aaec7953008 {   fd = 32, id =
> 32, xid = 655816107,   client = xxx:xxx,   step = STP_FETCH,   handling =
> PASS,   ws
>  = 0x2aaec7953078 {      id = "sess",     {s,f,r,e} =
> {0x2aaec79537b0,,+32,(nil),+8192},   },     worker = 0x7a072cb0 {     },
> vcl = {       srcname = {         "/opt
> /varnish/etc/varnish/xxx.vcl",         "Default",       },     },   obj =
> 0x2aaaad16b000 {     refcnt = 1, xid = 655816107,     ws = 0x2aaaad16b028
> {        id = "obj",
>      {s,f,r,e} = {0x2aaaad16b358,,0x2aaaad16b358,(nil),+7336},     },
> http = {       ws = 0x2aaaad16b028 {          id = "obj",
> {s,f,r,e} = {0x2aaaad16b358,,0
> x2aaaad16b358,(nil),+7336},       },     },     len = 0,     store = {
> },   }, },
> Sep 14 10:40:02 xxx varnishd[3128]: Child cleanup complete
> Sep 14 10:40:02 xxx varnishd[3128]: child (17247) Started

New description:

 Just had varnishd crash on me. I think his has happened before. This is
 Varnish 2.0.1 though, so it's not the latest version. But still, it's an
 issue.
 {{{
 Sep 14 10:40:02 xxx varnishd[3128]: Child (3129) died signal=6
 Sep 14 10:40:02 xxx varnishd[3128]: Child (3129) Panic message: Assert
 error in http_StatusMessage(), cache_http.c line 150:   Condition(status
 >= 100 && status <= 999)
  not true.  thread = (cache-worker)sp = 0x2aaec7953008 {   fd = 32, id =
 32, xid = 655816107,   client = xxx:xxx,   step = STP_FETCH,   handling =
 PASS,   ws
  = 0x2aaec7953078 {      id = "sess",     {s,f,r,e} =
 {0x2aaec79537b0,,+32,(nil),+8192},   },     worker = 0x7a072cb0 {     },
 vcl = {       srcname = {         "/opt
 /varnish/etc/varnish/xxx.vcl",         "Default",       },     },   obj =
 0x2aaaad16b000 {     refcnt = 1, xid = 655816107,     ws = 0x2aaaad16b028
 {        id = "obj",
      {s,f,r,e} = {0x2aaaad16b358,,0x2aaaad16b358,(nil),+7336},     },
 http = {       ws = 0x2aaaad16b028 {          id = "obj",
 {s,f,r,e} = {0x2aaaad16b358,,0
 x2aaaad16b358,(nil),+7336},       },     },     len = 0,     store = {
 },   }, },
 Sep 14 10:40:02 xxx varnishd[3128]: Child cleanup complete
 Sep 14 10:40:02 xxx varnishd[3128]: child (17247) Started
 }}}

Comment:

 I can't remember the exact circumstances of this one, 2.0.1 is long time
 ago for me, but I am pretty certain it has been fixed.

 ...along with countless other problems, bugs and mistakes.

 You should really update to a newer version.

 Poul-Henning

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/552#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep 14 15:03:06 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 14 Sep 2009 15:03:06 -0000
Subject: [Varnish] #546: Varnish eating up my memory
In-Reply-To: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
References: <051.ebec840b24471793276b5ba73ddc9ec2@projects.linpro.no>
Message-ID: <060.84a5add79c707a2af62b573b2b44d38a@projects.linpro.no>

#546: Varnish eating up my memory
----------------------+-----------------------------------------------------
 Reporter:  hp197     |        Owner:  phk                
     Type:  defect    |       Status:  new                
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  trunk              
 Severity:  normal    |   Resolution:                     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by hp197):

 For the record....

 It looks like i've solved my problem.
 I defined a grace period (in sub vcl_fetch: set beresp.grace = 30m;).

 After deleting that line i got memory usage as expected.

 {{{
   3.9 GiB +   1.2 MiB =   3.9 GiB       /usr/local/varnish/sbin/varnishd
 -P /var/run/varnish_xxx.pid -a :xxx -f
 /usr/local/varnish/etc/varnish/xxx.xxx.xxx.vcl -T :xxx -s malloc,3G -i xxx
 -n /usr/local/varnish/var/varnish/xxx -p thread_pools 4 -p lru_interval
 1800 (2)
 }}}

 Could there be an issue in the cleanup of the grace storage?

 Regards

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/546#comment:28>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 15 05:46:09 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 15 Sep 2009 05:46:09 -0000
Subject: [Varnish] #553: Check backends with 'OPTIONS *' request
Message-ID: <049.7866207b1579822fc5a772bd32065ff7@projects.linpro.no>

#553: Check backends with 'OPTIONS *' request
----------------------+-----------------------------------------------------
 Reporter:  ask       |       Owner:  phk          
     Type:  defect    |      Status:  new          
 Priority:  normal    |   Milestone:               
Component:  varnishd  |     Version:  trunk        
 Severity:  normal    |    Keywords:  loadbalancing
----------------------+-----------------------------------------------------
 Perlbal has a great feature where it checks the backend with an 'OPTIONS
 *' request at the start of each backend keep-alive session.  It'd be nice
 to have this in Varnish, too.

 To make this reasonable Perlbal also keeps reusing this same backend
 connection until disconnected, until a configurable number of requests
 have been done or until there are more than N idle backend connections
 (and it'll disconnect some.

 It makes the "bad backend server" detection almost perfect and it makes
 "perfect load balancing" trivial -- just only allow CPUs * 1.5
 simultaneous connections (or whatever) on each backend server and let
 Varnish try opening as many connections as it'd like.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/553>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 15 07:38:05 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 15 Sep 2009 07:38:05 -0000
Subject: [Varnish] #554: Backend Poll uses User-Agent for filtering
Message-ID: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no>

#554: Backend Poll uses User-Agent for filtering
-------------------------+--------------------------------------------------
 Reporter:  mbm          |       Owner:  phk  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishd     |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------
 The attached patch sets the HTTP request used for backend polling to also
 include a User-Agent header. This means that it becomes trivial to filter
 out the Varnish healthchecks from your stats or entire logging.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/554>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 15 07:49:25 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 15 Sep 2009 07:49:25 -0000
Subject: [Varnish] #554: Backend Poll uses User-Agent for filtering
In-Reply-To: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no>
References: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no>
Message-ID: <058.c6af7c4d0c2a723d3d692cc398532865@projects.linpro.no>

#554: Backend Poll uses User-Agent for filtering
-------------------------+--------------------------------------------------
 Reporter:  mbm          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by phk):

 I deliberately did not do this, but mostly because I had no idea what the
 correct behaviour should really be.

 Instead I made it possible to customize the entire request in the backend
 poll declaration (.request = "GET /foo...").

 If clearly marking the polls as coming from Varnish is a desirable
 default, then we should apply your patch, but I want to hear some feedback
 on that first...

 Poul-Henning

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/554#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 15 07:52:44 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 15 Sep 2009 07:52:44 -0000
Subject: [Varnish] #553: Check backends with 'OPTIONS *' request
In-Reply-To: <049.7866207b1579822fc5a772bd32065ff7@projects.linpro.no>
References: <049.7866207b1579822fc5a772bd32065ff7@projects.linpro.no>
Message-ID: <058.50df70a05f2a5d42fe80f8b24a67132d@projects.linpro.no>

#553: Check backends with 'OPTIONS *' request
---------------------------+------------------------------------------------
 Reporter:  ask            |        Owner:  phk    
     Type:  defect         |       Status:  closed 
 Priority:  normal         |    Milestone:         
Component:  varnishd       |      Version:  trunk  
 Severity:  normal         |   Resolution:  invalid
 Keywords:  loadbalancing  |  
---------------------------+------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 I have moved this to our feature-request-page
 (http://varnish.projects.linpro.no/wiki/PostTwoShoppingList)  we try to
 use tickets only for bug reports.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/553#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 15 10:01:40 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 15 Sep 2009 10:01:40 -0000
Subject: [Varnish] #554: Backend Poll uses User-Agent for filtering
In-Reply-To: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no>
References: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no>
Message-ID: <058.b9b99fe2c25549f0a5241957abb437eb@projects.linpro.no>

#554: Backend Poll uses User-Agent for filtering
-------------------------+--------------------------------------------------
 Reporter:  mbm          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by mbm):

 Hi Poul-Henning,

 Thanks for replying. In my experience with other loadbalancer/proxies
 (ZXTMs in particular), you want to be able to filter out the healthchecks
 from your main logs (maybe not from your debug/attack logs). Obviously,
 you can't filter on IP address, because all the requests will also come
 from those IPs - although you can filter on an X-Forwarded-For: or
 similar. If you have a sensible polling interval for making the site high-
 availability (ie on the order of ~1min), then the number of hits to any
 single backend from the poller can be comparatively high. I found it was
 worth filtering out nagios healthchecks and zxtm healthchecks from our
 backends so that our main apache logs contained meaningful hits. When I
 moved to Varnish (at a different place, with slightly different
 requirements). I found that we needed something similar, hence writing
 this patch (and the other one in #481), which helped us to see when badly-
 behaved clients of our service were hitting us very hard.

 I'd certainly be interested in other people's feedback too, and it's
 useful to know that you considered this and I now understand to some
 extent why you didn't include it.

 Cheers

 MBM

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/554#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 15 21:56:52 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 15 Sep 2009 21:56:52 -0000
Subject: [Varnish] #554: Backend Poll uses User-Agent for filtering
In-Reply-To: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no>
References: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no>
Message-ID: <058.12654f959b2fa0cb5fe9968d9847e69a@projects.linpro.no>

#554: Backend Poll uses User-Agent for filtering
-------------------------+--------------------------------------------------
 Reporter:  mbm          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by kb):

 I think phk's point was that you can already do this easily with the
 .request parameter, so the question becomes whether this duplicate
 functionality is better/useful enough to justify the added complexity.

 .request allows you to push arbitrary headers, which is extremely
 flexible.  Enumerating all possible headers as separate options seems like
 wasted complexity, IMVHO.

 Ken

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/554#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep 16 06:29:01 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 16 Sep 2009 06:29:01 -0000
Subject: [Varnish] #524: esi + keepalive + HTTP/1.0 hangs untill
	sess_timeout
In-Reply-To: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no>
References: <054.3f587d287afea2cc76ead53a946033e5@projects.linpro.no>
Message-ID: <063.078ebec465192aad4329a1ac31025f1e@projects.linpro.no>

#524: esi + keepalive + HTTP/1.0 hangs untill sess_timeout
----------------------+-----------------------------------------------------
 Reporter:  nicholas  |        Owner:       
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  build     |      Version:  trunk
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by atppp):

 I can confirm the problem. ab sends HTTP/1.0 requests with Connection:
 Keep-Alive header. Varnish returns plain html without Content-Length, and
 keeps the connection open. This confuses ab since it has no way to tell
 the response has ended.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/524#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep 16 11:43:27 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 16 Sep 2009 11:43:27 -0000
Subject: [Varnish] #554: Backend Poll uses User-Agent for filtering
In-Reply-To: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no>
References: <049.40a81d2308d1d3362c21b690a88acb09@projects.linpro.no>
Message-ID: <058.bd45bbc953a2a5d0749a9835ba9271dd@projects.linpro.no>

#554: Backend Poll uses User-Agent for filtering
-------------------------+--------------------------------------------------
 Reporter:  mbm          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by whocares):

 I agree with phk and Ken: using the .request way is enough flexibility
 (and actually is what we're using here to filter Varnish's keepalive
 requests from our logs)

 Stefan

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/554#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep 16 11:50:23 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 16 Sep 2009 11:50:23 -0000
Subject: [Varnish] #551: Varnish Crash: Missing errorhandling code in
	HSH_Prepare(), cache_hash.c line 188
In-Reply-To: <054.929506018381bcb32841815315546cac@projects.linpro.no>
References: <054.929506018381bcb32841815315546cac@projects.linpro.no>
Message-ID: <063.c2f8557eae8a80d6a2cfec80723dde1e@projects.linpro.no>

#551: Varnish Crash: Missing errorhandling code in HSH_Prepare(), cache_hash.c
line 188
----------------------+-----------------------------------------------------
 Reporter:  cheerios  |        Owner:  phk
     Type:  defect    |       Status:  new
 Priority:  normal    |    Milestone:     
Component:  varnishd  |      Version:  2.0
 Severity:  normal    |   Resolution:     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by cheerios):

 @kristian Yes, we use ESI on every page (custom header). Here's our
 default.vcl in use. I'll look into the sess_workspace param you mentioned.

 {{{
 backend default {
 .host = "127.0.0.1";
 .port = "81";
 .first_byte_timeout = 300s;
 }

 sub vcl_recv {
         if (req.request != "GET" &&
           req.request != "HEAD" &&
           req.request != "PUT" &&
           req.request != "POST" &&
           req.request != "TRACE" &&
           req.request != "OPTIONS" &&
           req.request != "DELETE") {
                     /* Non-RFC2616 or CONNECT which is weird. */
                     pipe;
         }

         # http://varnish.projects.linpro.no/wiki/FAQ/Compression
         if (req.http.Accept-Encoding) {
                 if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {
                     # No point in compressing these
                     remove req.http.Accept-Encoding;
                 } elsif (req.http.Accept-Encoding ~ "gzip") {
                     set req.http.Accept-Encoding = "gzip";
                 } elsif (req.http.Accept-Encoding ~ "deflate") {
                     set req.http.Accept-Encoding = "deflate";
                 } else {
                     # unkown algorithm
                     remove req.http.Accept-Encoding;
                 }
         }

         if (req.request != "GET" && req.request != "HEAD") {
                 pass;
         }

         if (req.http.Expect) {
                 pass;
         }

         if (req.http.Authenticate) {
                 pass;
         }

         lookup;
 }


 sub vcl_fetch {
         remove obj.http.Vary;

         if (req.request == "GET" && obj.http.Content-Type ~ "html" ) {
                 esi;
         }

         if (obj.http.Set-Cookie) {
                 pass;
         }

         if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "no-
 cache" || obj.http.Cache-Control ~ "private") {
                 pass;
         }

         # backend tells varnish what to cache and for how long using
 Varnish-Control header
         if (obj.http.Varnish-Control) {
                 C{
                     char *ttl;
                     ttl = VRT_GetHdr(sp, HDR_OBJ, "\020Varnish-Control:");
                     VRT_l_obj_ttl(sp, atoi(ttl));
                 }C
                 remove obj.http.Cache-Control;
                 remove obj.http.Expires;
                 deliver;
         }

         if (!obj.cacheable) {
                 pass;
         }

         pass;
 }
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/551#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep 16 15:33:32 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 16 Sep 2009 15:33:32 -0000
Subject: [Varnish] #551: Varnish Crash: Missing errorhandling code in
	HSH_Prepare(), cache_hash.c line 188
In-Reply-To: <054.929506018381bcb32841815315546cac@projects.linpro.no>
References: <054.929506018381bcb32841815315546cac@projects.linpro.no>
Message-ID: <063.2dc69126d9eafcae31fd4028c6fffcb3@projects.linpro.no>

#551: Varnish Crash: Missing errorhandling code in HSH_Prepare(), cache_hash.c
line 188
----------------------+-----------------------------------------------------
 Reporter:  cheerios  |        Owner:  phk
     Type:  defect    |       Status:  new
 Priority:  normal    |    Milestone:     
Component:  varnishd  |      Version:  2.0
 Severity:  normal    |   Resolution:     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by kb):

 Possibly unrelated, but modifying obj in vcl_fetch() will cause crashes
 (see #310); I found out the hard way.

 Odd though that setting obj.ttl specifically seems to be safe.

 Ken

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/551#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep 16 16:30:16 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 16 Sep 2009 16:30:16 -0000
Subject: [Varnish] #551: Varnish Crash: Missing errorhandling code in
	HSH_Prepare(), cache_hash.c line 188
In-Reply-To: <054.929506018381bcb32841815315546cac@projects.linpro.no>
References: <054.929506018381bcb32841815315546cac@projects.linpro.no>
Message-ID: <063.820eed1cc8278cb1996e9291e33fec3f@projects.linpro.no>

#551: Varnish Crash: Missing errorhandling code in HSH_Prepare(), cache_hash.c
line 188
----------------------+-----------------------------------------------------
 Reporter:  cheerios  |        Owner:  phk    
     Type:  defect    |       Status:  closed 
 Priority:  normal    |    Milestone:         
Component:  varnishd  |      Version:  2.0    
 Severity:  normal    |   Resolution:  invalid
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 Cheerios: I'm going to close this for now, since this sounds exactly like
 a sess_workspace issue. Feel free to re-open this if you can confirm that
 this is unaffected by sess_workspace. Further discussion should go on the
 mail list though.

 ... and:

 Replying to [comment:4 kb]:
 > Possibly unrelated, but modifying obj in vcl_fetch() will cause crashes
 (see #310); I found out the hard way.

 You mean vcl_hit. The object is safely locked in vcl_fetch, and can be
 modified.

 > Odd though that setting obj.ttl specifically seems to be safe.

 Nah, not really that odd. Setting a ttl fairly atomic, while manipulating
 strings usually means copying and replacing. But this discussion doesn't
 belong here.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/551#comment:5>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Sun Sep 20 22:18:31 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sun, 20 Sep 2009 22:18:31 -0000
Subject: [Varnish] #555: died signal=6  ,
	panic and restart every few sec. to min.
Message-ID: <052.ceb4b4d9f15ca598018bb91e7d89e5e4@projects.linpro.no>

#555: died signal=6  , panic and restart every few sec. to min.
--------------------+-------------------------------------------------------
 Reporter:  skyfox  |        Type:  defect 
   Status:  new     |    Priority:  highest
Milestone:          |   Component:  build  
  Version:  trunk   |    Severity:  normal 
 Keywords:          |  
--------------------+-------------------------------------------------------
 Plz help, anyone have idea howto solve this problem ?


 varnishd -a 0.0.0.0:80 -T 127.0.0.1:3500 -p client_http11=on -f vconf2 -s
 file,/usr/local/varnish/cache.bin,80G -h classic,500009 -p
 listen_depth=4096 -p obj_workspace=32768 -p sess_workspace=32768 -p
 send_timeout=327


 I got this message from /var/log/messages

 Sep 20 21:26:36 x2 varnishd[21933]: Child (21934) died signal=6
 Sep 20 21:26:36 x2 varnishd[21933]: Child (21934) Panic message: Assert
 error in VRT_IP_string(), cache_vrt.c line 693:   Condition((p =
 WS_Alloc(sp->http->ws, len)) != 0) nlient = 211.74.185.119:2909,   step =
 STP_RECV,   handling = error,   err_code = 503, err_reason = (null),   ws
 = 0x2abeb5926078 { overflow     id = "sess",     {s,f,r,e} = cname = {
 "input",         "Default",       },     }, },


 Sep 20 21:26:36 x2 varnishd[21933]: child (21952) Started
 Sep 20 21:26:36 x2 varnishd[21933]: Child (21952) said Closed fds: 4 5 8 9
 11 12
 Sep 20 21:26:36 x2 varnishd[21933]: Child (21952) said Child starts
 Sep 20 21:26:36 x2 varnishd[21933]: Child (21952) said managed to mmap
 85899345920 bytes of 85899345920
 Sep 20 21:26:36 x2 varnishd[21933]: Child (21952) said Ready
 Sep 20 21:28:10 x2 varnishd[21933]: Child (21952) died signal=6
 Sep 20 21:28:10 x2 varnishd[21933]: Child (21952) Panic message: Assert
 error in WS_Release(), cache_ws.c line 170:   Condition(bytes <= ws->e -
 ws->f) not true.  thread = (10:32759,   step = STP_RECV,   handling =
 error,   err_code = 503, err_reason = (null),   ws = 0x2abeb5a65078 {
 id = "sess",     {s,f,r,e} = {0x2abeb5a65808,,+32738,+32
 "Default",       },     }, },


 Thanks alot

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/555>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Wed Sep 23 06:55:17 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 23 Sep 2009 06:55:17 -0000
Subject: [Varnish] #556: varnish error: Manager got SIGINT
Message-ID: <065.ac980ea3ac0e84c103d1ca223c0017cd@projects.linpro.no>

#556: varnish error: Manager got SIGINT
---------------------------------+------------------------------------------
 Reporter:  guobinchn at gmail.com  |        Type:  defect
   Status:  new                  |    Priority:  normal
Milestone:  After Varnish 2.1    |   Component:  build 
  Version:  trunk                |    Severity:  normal
 Keywords:                       |  
---------------------------------+------------------------------------------
 I run varnish-2.0.4 at centos5.2(32bit).  My box: CPU  E5310  1.6G,
 memory:4G ,sata:2t
 sometime i view /var/log/messsages, found follow ,i did nothing.
   Sep 23 04:17:33 localhost /usr/local/varnish/var/cache01/[31906]: child
 (9755) Started
 Sep 23 04:17:34 localhost /usr/local/varnish/var/cache01/[31906]: Child
 (9755) said Closed fds: 3 4 5 8 9 11 12
 Sep 23 04:17:34 localhost /usr/local/varnish/var/cache01/[31906]: Child
 (9755) said Child starts
 Sep 23 04:17:34 localhost /usr/local/varnish/var/cache01/[31906]: Child
 (9755) said Ready
 Sep 23 04:55:12 localhost /usr/local/varnishstage/var/cache01/[31699]:
 '''Manager got SIGINT'''
 Sep 23 04:55:32 localhost /usr/local/varnishstage/var/cache01/[16254]:
 child (16255) Started
 Sep 23 04:55:33 localhost /usr/local/varnishstage/var/cache01/[16254]:
 Child (16255) said Closed fds: 3 4 5 8 9 11 12
 Sep 23 04:55:33 localhost /usr/local/varnishstage/var/cache01/[16254]:
 Child (16255) said Child starts
 Sep 23 04:55:33 localhost /usr/local/varnishstage/var/cache01/[16254]:
 Child (16255) said Ready
 Sep 23 04:56:42 localhost /usr/local/varnishstage/var/cache01/[16254]:
 '''Manager got SIGINT'''
 Sep 23 04:56:56 localhost /usr/local/varnishstage/var/cache01/[16633]:
 child (16634) Started
 Sep 23 04:56:57 localhost /usr/local/varnishstage/var/cache01/[16633]:
 Child (16634) said Closed fds: 3 4 5 8 9 11 12
 Sep 23 04:56:57 localhost /usr/local/varnishstage/var/cache01/[16633]:
 Child (16634) said Child starts
 Sep 23 04:56:57 localhost /usr/local/varnishstage/var/cache01/[16633]:
 Child (16634) said Ready


 I do not know what happed? why varnish crash?

 run parameter
     /usr/local/varnish/sbin/varnishd -P /var/run/varnish.pid -a
 127.0.0.1:4001 -f /usr/local/varnish/etc/varnish.conf -T 127.0.0.1:4000 -t
 604800 -u www -g www -s malloc,2G -p thread_pools 8 -p thread_pool_min 16
 -p thread_pool_max 512 -p acceptor epoll -p auto_restart on -p
 backend_http11 on -p client_http11 off -p connect_timeout 10 -p err_ttl 0
 -p listen_depth 8192 -p lru_interval 30 -p obj_workspace 16384 -p
 overflow_max 90 -p send_timeout 600 -p sess_timeout 2 -p session_linger
 110 -p srcaddr_hash 150001 -p thread_pool_add_delay 10 -p ping_interval 0
 -p between_bytes_timeout 10 -p first_byte_timeout 10 -p max_restarts 3 -p
 sess_workspace 327680 -n /usr/local/varnish/var/cache01/ -h
 classic,1000033

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/556>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Sep 24 11:07:40 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 24 Sep 2009 11:07:40 -0000
Subject: [Varnish] #557: varnishd manpage error: http_workspace should be
	sess_workspace
Message-ID: <053.ef88de8a6e6ff2875794b9980639c361@projects.linpro.no>

#557: varnishd manpage error: http_workspace should be sess_workspace
----------------------------------------------+-----------------------------
 Reporter:  vudumen                           |        Type:  documentation
   Status:  new                               |    Priority:  normal       
Milestone:                                    |   Component:  documentation
  Version:  2.0                               |    Severity:  major        
 Keywords:  varnishd man http sess workspace  |  
----------------------------------------------+-----------------------------
 In the manpage at the runtime parameters section currently it sais the
 following:

      '''http_workspace'''
            The size of the per-session workspace for HTTP protocol data.
 For performance reasons, this space is preallocated, so any change to this
 parameter will only apply to new client sessions.
            The default is 8192 bytes.

 It shoud be sess_workspace instead.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/557>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Sep 24 13:53:23 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 24 Sep 2009 13:53:23 -0000
Subject: [Varnish] #558: PIPE assert
Message-ID: <050.5ea9bbc338695e84e8a95a38812260d9@projects.linpro.no>

#558: PIPE assert
----------------------+-----------------------------------------------------
 Reporter:  kolo      |       Owner:  phk        
     Type:  defect    |      Status:  new        
 Priority:  high      |   Milestone:             
Component:  varnishd  |     Version:  2.0        
 Severity:  critical  |    Keywords:  pipe assert
----------------------+-----------------------------------------------------
 On high load we are geting asserts (and varnish restarts) like this:

 {{{
  Child (29050) Panic message: Assert error in Tcheck(), cache.h line
 648:#012  Condition((t.e) != 0) not true.  thread = (cache-worker)sp =
 0x7f71331f7008 {#012  fd = 232, id = 232, xid = 137189936,#012  client =
 212.20.66.167:2494,#012  step = STP_PIPE,#012  handling = pipe,#012
 err_code = 400, err_reason = (null),#012  ws = 0x7f71331f7078 { #012    id
 = "sess",#012    {s,f,r,e} = {0x7f71331f7808,,+682,(nil),+16384},#012
 },#012    worker = 0x7f711fd17be0 {#012    },#012    vcl = {#012
 srcname = {#012        "input",#012        "Default",#012      },#012
 },#012},#012
 }}}

 when I redefine vcl like this:
 {{{
  sub vcl_recv
      if (req.request != "GET" &&
        req.request != "HEAD" &&
        req.request != "PUT" &&
        req.request != "POST" &&
        req.request != "TRACE" &&
        req.request != "OPTIONS" &&
        req.request != "DELETE") {
          /* Non-RFC2616 or CONNECT which is weird. */
          return (pass);
      }
 }}}

 I get this assert:

 {{{
  Child (27265) Panic message: Assert error in Tcheck(), cache.h line
 648:#012  Condition((t.e) != 0) not true.  thread = (cache-worker)sp =
 0x7f3c2277f008 {#012  fd = 850, id = 850, xid = 351167563,#012  client =
 83.21.131.63:1277,#012  step = STP_PASS,#012  handling = pass,#012
 err_code = 400, err_reason = (null),#012  ws = 0x7f3c2277f078 { #012    id
 = "sess",#012    {s,f,r,e} = {0x7f3c2277f808,,+601,(nil),+16384},#012
 },#012    worker = 0x7f3c33becbe0 {#012    },#012    vcl = {#012
 srcname = {#012        "input",#012        "Default",#012      },#012
 },#012},#012
 }}}

 and this way:
  {{{
 sub vcl_recv
      if (req.request != "GET" &&
        req.request != "HEAD" &&
        req.request != "PUT" &&
        req.request != "POST" &&
        req.request != "TRACE" &&
        req.request != "OPTIONS" &&
        req.request != "DELETE") {
          /* Non-RFC2616 or CONNECT which is weird. */
          return (error);
      }
 }}}

 I get:

 {{{
  Child (21508) Panic message: Assert error in http_StatusMessage(),
 cache_http.c line 111:#012  Condition(status >= 100 && status <= 999) not
 true.  thread = (cache-worker)sp = 0x7f713476b008 {#012  fd = 127, id =
 127, xid = 77180678,#012  client = 94.246.126.177:34647,#012  step =
 STP_ERROR,#012  handling = error,#012  ws = 0x7f713476b078 { #012    id =
 "sess",#012    {s,f,r,e} = {0x7f713476b808,,+903,(nil),+16384},#012
 },#012    worker = 0x7f7123846be0 {#012    },#012    vcl = {#012
 srcname = {#012        "input",#012        "Default",#012      },#012
 },#012  obj = 0x7f780f7b7000 {#012    refcnt = 1, xid = 77180678,#012
 ws = 0x7f780f7b7028 { #012      id = "obj",#012      {s,f,r,e} =
 {0x7f780f7b7358,,+78,(nil),+7336},#012    },#012    http = {#012      ws =
 0x7f780f7b7028 { #012        id = "obj",#012        {s,f,r,e} =
 {0x7f780f7b7358,,+78,(nil),+7336},#012      },#012      hd = {#012
 "Date: Tue, 22 Sep 2009 14:07:04 GMT",#012        "Server: Varnish",#012
 "Retry-After: 0",#012      },#012    },#012    len = 0,#012    store =
 {#012    },#012  },#012},#012
 }}}


 runing 2.0.4
 64bit debian lenny; vanila 2.6.31; 31GB RAM (only few hundreds used)

 happens unpredictable seldom but on high load it makes  trouble; on
 default vcl we are geting only tens of pipe request per tens of million
 other req.

 When we were using PIPE like solution for IE6 keepalive bug

 ( http://projects.linpro.no/pipermail/varnish-
 misc/2009-September/003075.html)

 asserts were frequent.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/558>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Sep 24 14:26:17 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 24 Sep 2009 14:26:17 -0000
Subject: [Varnish] #558: PIPE assert
In-Reply-To: <050.5ea9bbc338695e84e8a95a38812260d9@projects.linpro.no>
References: <050.5ea9bbc338695e84e8a95a38812260d9@projects.linpro.no>
Message-ID: <059.180c70528976bc0da7c73046bed02e4c@projects.linpro.no>

#558: PIPE assert
-------------------------+--------------------------------------------------
 Reporter:  kolo         |        Owner:  phk   
     Type:  defect       |       Status:  closed
 Priority:  high         |    Milestone:        
Component:  varnishd     |      Version:  2.0   
 Severity:  critical     |   Resolution:  fixed 
 Keywords:  pipe assert  |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 This should be fixed with r4241+r4242

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/558#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Thu Sep 24 20:54:57 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 24 Sep 2009 20:54:57 -0000
Subject: [Varnish] #559: Missing varnishd options in documentation
Message-ID: <054.d95de5af4b2fe8fb6aa84ac6634632f1@projects.linpro.no>

#559: Missing varnishd options in documentation
----------------------+-----------------------------------------------------
 Reporter:  walraven  |        Type:  defect       
   Status:  new       |    Priority:  normal       
Milestone:            |   Component:  documentation
  Version:  trunk     |    Severity:  normal       
 Keywords:            |  
----------------------+-----------------------------------------------------
 Options -i and -C are not documented in both man 1 varnishd and usage().

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/559>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Sep 25 11:31:08 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 25 Sep 2009 11:31:08 -0000
Subject: [Varnish] #560: Missing errorhandling code in HSH_Prepare()
Message-ID: <051.da73ea1149ed62e1c257e2a76e6a11d8@projects.linpro.no>

#560: Missing errorhandling code in HSH_Prepare()
----------------------+-----------------------------------------------------
 Reporter:  orjan     |       Owner:  phk             
     Type:  defect    |      Status:  new             
 Priority:  normal    |   Milestone:                  
Component:  varnishd  |     Version:  2.0             
 Severity:  major     |    Keywords:  hash vary cookie
----------------------+-----------------------------------------------------
 I'm running varnish-2.0.4-1.el5 on RHEL 5.4 x86_64

 I got quite a lot of these in my logs this morning, and the service was
 down for a minute or so:


 {{{
 Panic message: Missing errorhandling code in HSH_Prepare(), cache_hash.c
 line 188:#012  Condition((p) != 0) not true.
 thread = (cache-worker)sp = 0x2aad2e189008 {#012  fd = 13, id = 13, xid =
 751392630,#012  client = 172.23.22.190:44006,#012
 step = STP_LOOKUP,#012  handling = lookup,#012  ws = 0x2aad2e189078 {
 overflow#012    id = "sess",#012
 {s,f,r,e} = {0x2aad2e189808,,+16368,(nil),+16384},#012  },#012    worker =
 0x43df2bd0 {#012    },#012    vcl = {#012
 srcname = {#012        "input",#012        "Default",#012      },#012
 },#012},#012

 }}}

 Full vcl-config can be found here: https://paste.redpill-linpro.com/160
 (requires login)

 Most interesting is perhaps that i set the "Vary: Cookie" header in an
 attempt to emulate the squids that i'm currently replacing. This seems to
 annoy HSH_Prepare()

 This other one came at roughly the same time, but might not be related:


 {{{
 Panic message: Assert error in VRT_r_req_xid(), cache_vrt.c line 544:#012
 Condition((p = WS_Alloc(sp->http->ws, size)) != 0) not true.
   thread = (cache-worker)sp = 0x2aad2d54c008 {#012  fd = 10, id = 10, xid
 = 1926762735,#012  client = 172.23.22.190:44998,#012
 step = STP_ERROR,#012  handling = error,#012  err_code = 503, err_reason =
 (null),#012  ws = 0x2aad2d54c078 { overflow#012
 id = "sess",#012    {s,f,r,e} = {0x2aad2d54c808,,+16378,(nil),+16384},#012
 },#012    worker = 0x4a074bd0 {#012    },#012
 vcl = {#012      srcname = {#012        "input",#012        "Default",#012
 },#012    },#012  obj = 0x2aaaab000000 {#012
 refcnt = 1, xid = 1926762735,#012    ws = 0x2aaaab000028 { #012      id =
 "obj",#012      {s,f,r,e} = {0x2aaaab000358,,+140,(nil),+7336},#012
 },#012
 http = {#012      ws = 0x2aaaab000028 { #012        id = "obj",#012
 {s,f,r,e} = {0x2aaaab000358,,+140,(nil),+7336},#012      },#012
 hd = {#012        "Date: Fri, 25 Sep 2009 08:01:59 GMT",#012
 "Server: Varnish",#012        "Retry-After: 0",#012
 "Content-Type: text/html; charset=utf-8",#012      },#012    },#012    len
 = 0,#012    store = {#012    },#012  },#012},#012
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/560>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Fri Sep 25 13:49:16 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 25 Sep 2009 13:49:16 -0000
Subject: [Varnish] #560: Missing errorhandling code in HSH_Prepare()
In-Reply-To: <051.da73ea1149ed62e1c257e2a76e6a11d8@projects.linpro.no>
References: <051.da73ea1149ed62e1c257e2a76e6a11d8@projects.linpro.no>
Message-ID: <060.6c821249bd89d2306aa3af2ca2fd2725@projects.linpro.no>

#560: Missing errorhandling code in HSH_Prepare()
------------------------------+---------------------------------------------
 Reporter:  orjan             |        Owner:  phk    
     Type:  defect            |       Status:  closed 
 Priority:  normal            |    Milestone:         
Component:  varnishd          |      Version:  2.0    
 Severity:  major             |   Resolution:  invalid
 Keywords:  hash vary cookie  |  
------------------------------+---------------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 You're running out of session workspace. See #551 #472 . (Also discussed
 face-to-face, for the record).

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/560#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep 28 08:43:39 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 28 Sep 2009 08:43:39 -0000
Subject: [Varnish] #455: Make HTTP_HDR_MAX a ./configure option
In-Reply-To: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no>
References: <054.a08f2c6f3146cb9876379a2ab230675e@projects.linpro.no>
Message-ID: <063.c4f5327c3f2a9fbb39b8fab60d9a045f@projects.linpro.no>

#455: Make HTTP_HDR_MAX a ./configure option
-------------------------+--------------------------------------------------
 Reporter:  whocares     |        Owner:  tfheen
     Type:  enhancement  |       Status:  closed
 Priority:  normal       |    Milestone:        
Component:  build        |      Version:  trunk 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:  max headers  |  
-------------------------+--------------------------------------------------
Comment (by tfheen):

 (In [4243]) Merge r4030: Make HTTP_HDR_MAX_VAL a configure option

 Thanks to "whocares" in the bts.

 Fixes #455

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/455#comment:7>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep 28 09:05:06 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 28 Sep 2009 09:05:06 -0000
Subject: [Varnish] #494: When backend server continues a header line
	with \n\t rather than \r\n\t remove only removes first line of header
In-Reply-To: <051.48a8a89418f72e8a97c17f3846c2825e@projects.linpro.no>
References: <051.48a8a89418f72e8a97c17f3846c2825e@projects.linpro.no>
Message-ID: <060.a389c7c82326d568536e2a5623fcdec7@projects.linpro.no>

#494: When backend server continues a header line with \n\t rather than \r\n\t
remove only removes first line of header
----------------------+-----------------------------------------------------
 Reporter:  lrowe     |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  2.0   
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by tfheen):

 (In [4245]) Merge r4036: Implement HTTP continuation lines.

 Fixes #494

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/494#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep 28 09:47:00 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 28 Sep 2009 09:47:00 -0000
Subject: [Varnish] #505: changeset 4046 Breaks AJAX posts.
In-Reply-To: <053.6e7935485be6da8bceee67f2e189b4a8@projects.linpro.no>
References: <053.6e7935485be6da8bceee67f2e189b4a8@projects.linpro.no>
Message-ID: <062.0e4f19c3fdc81ef56699800a1df4df4c@projects.linpro.no>

#505: changeset 4046 Breaks AJAX posts.
---------------------+------------------------------------------------------
 Reporter:  victori  |        Owner:        
     Type:  defect   |       Status:  closed
 Priority:  high     |    Milestone:        
Component:  build    |      Version:  trunk 
 Severity:  normal   |   Resolution:  fixed 
 Keywords:           |  
---------------------+------------------------------------------------------
Comment (by tfheen):

 (In [4248]) Merge: r4046, r4047, r4183: Change the way we close client
 sessions.

 r4046:
 Change the way we close client sessions.

 Previously we always used SO_LINGER to make sure that all queued data
 got transmitted, no matter under which circumstances we closed the
 client connection.

 Change this so that SO_LINGER is only activated for orderly connection
 closure (ie: "Connection: close" from client or error handling), in
 all other cases (usually the client connecting on us, abandon any data
 queued for transmission.

 This _may_ reduce the tendency of worker threads to get hung up on
 network failures a little bit.

 r4047:
 r4046 forgot to reset SO_LINGER for pipe handling which basically
 broke pipehandling.

 Fixes #505

 r4183:
 Disable SO_LINGER when we time out a connection due to sess_timeout,
 so that we do not RST connections that have still not transmitted
 their
 data.

 Since we were able to get the writev(2) to detach the socket, we
 should
 not end up sleeping in the close(2) either.

 We still RST the socket for all error conditions.

 Ideally I would still like to RST connections that have no outstanding
 data after their sess_timeout, in order to avoid the 2*RTT+misc
 timeouts delays associated with loosing a TCP socket for a client
 that have gone to meet some other IP#.

 In particular with load-balancers, this allows the load balancer to
 declare the session dead right away, and reuse it for something more
 productive.

 Unfortunately, this lacks OS support in all presently released
 OS'es: you cannot ask if a socket is done transmitting what you
 asked it to.

 FreeBSD-8.0 will have experimental support for this (FIONWRITE)
 and I will revisit it in that context.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/505#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep 28 09:56:03 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 28 Sep 2009 09:56:03 -0000
Subject: [Varnish] #502: purge() doesn't understand && in a string
In-Reply-To: <051.8147540568e24ebf21d1cf666c268c1e@projects.linpro.no>
References: <051.8147540568e24ebf21d1cf666c268c1e@projects.linpro.no>
Message-ID: <060.e032e785e71fc7b9848f0377a1c9b3c4@projects.linpro.no>

#502: purge() doesn't understand && in a string
----------------------+-----------------------------------------------------
 Reporter:  Sesse     |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  2.0   
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by tfheen):

 (In [4249]) Merge r4048: Fix a parse error in VCL:purge() string version.

 Fixes #502

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/502#comment:3>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep 28 10:05:01 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 28 Sep 2009 10:05:01 -0000
Subject: [Varnish] #557: varnishd manpage error: http_workspace should
	be sess_workspace
In-Reply-To: <053.ef88de8a6e6ff2875794b9980639c361@projects.linpro.no>
References: <053.ef88de8a6e6ff2875794b9980639c361@projects.linpro.no>
Message-ID: <062.b725b7df4b0717f405d3d9cb52210bc3@projects.linpro.no>

#557: varnishd manpage error: http_workspace should be sess_workspace
----------------------------------------------+-----------------------------
 Reporter:  vudumen                           |        Owner:     
     Type:  documentation                     |       Status:  new
 Priority:  normal                            |    Milestone:     
Component:  documentation                     |      Version:  2.0
 Severity:  major                             |   Resolution:     
 Keywords:  varnishd man http sess workspace  |  
----------------------------------------------+-----------------------------
Comment (by kane):

 Patch below:

 {{{

 Index: varnish-cache/bin/varnishd/varnishd.1
 ===================================================================
 --- varnish-cache/bin/varnishd/varnishd.1       (revision 4242)
 +++ varnish-cache/bin/varnishd/varnishd.1       (working copy)
 @@ -520,7 +520,7 @@
  are specified, the latter should be specified last.
  .Pp
  The default is "nogroup".
 -.It Va http_workspace
 +.It Va sess_workspace
  The size of the per-session workspace for HTTP protocol data.
  For performance reasons, this space is preallocated, so any change to
  this parameter will only apply to new client sessions.

 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/557#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Mon Sep 28 10:13:49 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 28 Sep 2009 10:13:49 -0000
Subject: [Varnish] #506: kernel: pid 2100 (varnishd),
	uid 80: exited on signal 6
In-Reply-To: <052.3fe911a39a8b9fc3a8a9e60835e1bd22@projects.linpro.no>
References: <052.3fe911a39a8b9fc3a8a9e60835e1bd22@projects.linpro.no>
Message-ID: <061.2faca4e6de543d5e1994873a38a4b9f1@projects.linpro.no>

#506: kernel: pid 2100 (varnishd), uid 80: exited on signal 6
----------------------+-----------------------------------------------------
 Reporter:  danger    |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  2.0   
 Severity:  critical  |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by tfheen):

 (In [4250]) Merge r4052, r4053: Be more paranoid about backend responses

 r4052:
 Be more paranoid about backend responses, a response of:
         HTTP/1.1 1000\n\r\n\r
 would panic us trying to find a suitable message for 1000.

 Now we 503 the response instead.

 Fixes #506

 r4053:
 Regression test for #506

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/506#comment:4>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 29 09:20:25 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 29 Sep 2009 09:20:25 -0000
Subject: [Varnish] #561: Restarting 400 Bad request causes an assert error
Message-ID: <051.f0a00596f7b3d885074ac5ec64dc74e6@projects.linpro.no>

#561: Restarting 400 Bad request causes an assert error
----------------------+-----------------------------------------------------
 Reporter:  mikko     |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:     
Component:  varnishd  |     Version:  2.0
 Severity:  normal    |    Keywords:     
----------------------+-----------------------------------------------------
 The issue can be reproduced with following VCL:


 sub vcl_error {
         if (req.restarts < 5) {
                 restart;
         } else {
                 set obj.http.Content-Type = "text/html; charset=utf-8";
                 synthetic {"<h1>"} obj.status " " obj.response {"</h1>"};
                 return (deliver);
         }
 }

 When this VCL is active and Varnish receives an invalid request it results
 to the following assertion error:

 Sep 26 23:19:58 dev varnishd[9411]: Child (9412) Panic message: Assert
 error in Tcheck(), cache.h line 648:#012  Condition((t.e) != 0) not true.
 thread = (cache-worker)sp = 0x7ffcc3e03008 {#012  fd = 7, id = 7, xid =
 870505299,#012  client = ::1:40256,#012  step = STP_PIPE,#012  handling =
 pipe,#012  err_code = 400, err_reason = (null),#012  ws = 0x7ffcc3e03078 {
 #012    id = "sess",#012    {s,f,r,e} =
 {0x7ffcc3e03808,,+23,(nil),+16384},#012  },#012    worker = 0x7ffcbfdf6be0
 {#012    },#012    vcl = {#012      srcname = {#012        "input",#012
 "Default",#012      },#012    },#012},#012


 Tested with Varnish 2.0.4.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/561>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 29 10:37:24 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 29 Sep 2009 10:37:24 -0000
Subject: [Varnish] #562: configure check for xsltproc missing
Message-ID: <049.267c79551805c07298a5454a91ab951f@projects.linpro.no>

#562: configure check for xsltproc missing
--------------------+-------------------------------------------------------
 Reporter:  phk     |       Owner:       
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  trunk
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 {{{
 <phk> Mithrandir, if you run configure on a system without xsltproc you
 get a very cryptic error message at make time.
 <phk> is there a dependency check missing ?
 <phk>  cd .. && /bin/sh ./config.status doc/Makefile
 <phk> config.status: creating doc/Makefile
 <phk> --xinclude -o changes-2.0.1.html changes-2.0.1.xml
 <phk> --xinclude:No such file or directory
 <phk> *** Error code 1
 <Mithrandir> phk: yeah, it fails to check for xsltproc.  It should just
 skipping building the docs.
 <Mithrandir> I'm in the middle of misc, if you'd like me to fix it, file a
 bug and assign it to me
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/562>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 29 13:47:22 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 29 Sep 2009 13:47:22 -0000
Subject: [Varnish] #563: Unable to mangle one of multiple Set-Cookie headers.
Message-ID: <049.c51db836066750a18661c2034ddcef9f@projects.linpro.no>

#563: Unable to mangle one of multiple Set-Cookie headers.
----------------------+-----------------------------------------------------
 Reporter:  are       |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:     
Component:  varnishd  |     Version:  2.0
 Severity:  normal    |    Keywords:     
----------------------+-----------------------------------------------------
 REF: rfc2109, part 4.2.1  General:
 "An origin server may include multiple Set-Cookie headers in a response."

 We got a backend server that sent two Set-Cookie headers and want to strip
 out the ones we don't need based on certain factors. The problem is that
 only the first header is available for processing - which in this case is
 always "JSESSIONID". It's the second headers that contains all the good
 stuff... but are not available for regexp matching.
 But, if we /do/ mangle the available SetCookie header, the second one
 disappears.

 Without considering the details, I would think the easy way is just to
 merge them so they can be managed as one in vcl.

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/563>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 29 15:19:28 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 29 Sep 2009 15:19:28 -0000
Subject: [Varnish] #561: Restarting 400 Bad request causes an assert error
In-Reply-To: <051.f0a00596f7b3d885074ac5ec64dc74e6@projects.linpro.no>
References: <051.f0a00596f7b3d885074ac5ec64dc74e6@projects.linpro.no>
Message-ID: <060.c2c39d5395d59723c41137a1aa840e63@projects.linpro.no>

#561: Restarting 400 Bad request causes an assert error
----------------------+-----------------------------------------------------
 Reporter:  mikko     |        Owner:  phk
     Type:  defect    |       Status:  new
 Priority:  normal    |    Milestone:     
Component:  varnishd  |      Version:  2.0
 Severity:  normal    |   Resolution:     
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by mikko):

 {{{

 (gdb) bt
 #0  0x00007fe82ddddd25 in raise () from /lib/libc.so.6
 #1  0x00007fe82dde0de1 in abort () from /lib/libc.so.6
 #2  0x0000000000420a96 in pan_ic (func=0x44e7be "Tcheck", file=0x44e7d0
 "cache.h", line=648, cond=0x44e7d8 "(t.e) != 0", err=0, xxx=0) at
 cache_panic.c:317
 #3  0x000000000041b5ea in Tcheck (t={b = 0x7fe7e520381c
 "sdfsdfsdfsdf\r\n\r\n", e = 0x0}) at cache.h:648
 #4  0x000000000041ca88 in http_copyh (to=0x7fe7dfe06050,
 fm=0x7fe7e5203250, n=0) at cache_http.c:532
 #5  0x000000000041cbfa in http_copyreq (to=0x7fe7dfe06050,
 fm=0x7fe7e5203250, how=4) at cache_http.c:545
 #6  0x000000000041d685 in http_FilterHeader (sp=0x7fe7e5203008, how=4) at
 cache_http.c:643
 #7  0x00000000004135ad in cnt_pipe (sp=0x7fe7e5203008) at
 cache_center.c:779
 #8  0x0000000000414387 in CNT_Session (sp=0x7fe7e5203008) at steps.h:36
 #9  0x00000000004221f9 in wrk_do_cnt_sess (w=0x7fe7e07f6c50,
 priv=0x7fe7e5203008) at cache_pool.c:398
 #10 0x0000000000421c96 in wrk_thread (priv=0x7fe82dc0d1a0) at
 cache_pool.c:310
 #11 0x00007fe82e59ef9a in start_thread () from /lib/libpthread.so.0
 #12 0x00007fe82de7856d in clone () from /lib/libc.so.6
 #13 0x0000000000000000 in ?? ()
 (gdb) frame 6
 #6  0x000000000041d685 in http_FilterHeader (sp=0x7fe7e5203008, how=4) at
 cache_http.c:643
 643             http_copyreq(hp, sp->http, how);
 (gdb) print *sp
 $4 = {magic = 741317722, fd = 7, id = 7, xid = 1062897157, restarts = 1,
 esis = 0, wrk = 0x7fe7e07f6c50, sockaddrlen = 16, mysockaddrlen = 128,
 sockaddr = 0x7fe7e5203708, mysockaddr = 0x7fe7e5203788,
   mylsock = 0x7fe82dc08190, addr = 0x7fe7e5203808 "192.168.192.1", port =
 0x7fe7e5203816 "58323", srcaddr = 0x7fe7dfe020c0, doclose = 0x0, http =
 0x7fe7e5203250, http0 = 0x7fe7e52034a0, ws = {{
       magic = 905626964, id = 0x44fce0 "sess", s = 0x7fe7e5203808
 "192.168.192.1", f = 0x7fe7e520382c "", r = 0x0, e = 0x7fe7e5207808 "",
 overflow = 0}},
   ws_ses = 0x7fe7e520381c "sdfsdfsdfsdf\r\n\r\n", ws_req = 0x7fe7e520382c
 "", htc = {{magic = 1041886673, fd = 7, ws = 0x7fe7e5203078, rxbuf = {b =
 0x7fe7e520381c "sdfsdfsdfsdf\r\n\r\n",
         e = 0x7fe7e520382c ""}, pipeline = {b = 0x0, e = 0x0}}}, t_open =
 1254025374.3741782, t_req = 1254025375.4689867, t_resp =
 nan(0x8000000000000), t_end = nan(0x8000000000000),
   connect_timeout = 0.40000000000000002, first_byte_timeout = 60,
 between_bytes_timeout = 60, grace = nan(0x8000000000000), step = STP_PIPE,
 cur_method = 0, handling = 3, sendbody = 0 '\0',
   wantbody = 1 '\001', err_code = 400, err_reason = 0x0, list = {vtqe_next
 = 0x0, vtqe_prev = 0x0}, director = 0x7fe82dc0d248, vbe = 0x0, bereq =
 0x0, obj = 0x0, objhead = 0x0, vcl = 0x7fe82dc2f428,
   mem = 0x7fe7e5203000, workreq = {list = {vtqe_next = 0x0, vtqe_prev =
 0x0}, func = 0x4220be <wrk_do_cnt_sess>, priv = 0x7fe7e5203008}, acct =
 {first = 1254025374.3741782, sess = 0, req = 0,
     pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_req
 = {first = 0, sess = 1, req = 1, pipe = 1, pass = 0, fetch = 0, hdrbytes =
 0, bodybytes = 0}, nhashptr = 0, ihashptr = 0,
   lhashptr = 0, hashptr = 0x0}
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/561#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator

From varnish-bugs at projects.linpro.no  Tue Sep 29 17:07:36 2009
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 29 Sep 2009 17:07:36 -0000
Subject: [Varnish] #561: Restarting 400 Bad request causes an assert error
In-Reply-To: <051.f0a00596f7b3d885074ac5ec64dc74e6@projects.linpro.no>
References: <051.f0a00596f7b3d885074ac5ec64dc74e6@projects.linpro.no>
Message-ID: <060.35f0922a16dc941983d71179d4b5bf7c@projects.linpro.no>

#561: Restarting 400 Bad request causes an assert error
----------------------+-----------------------------------------------------
 Reporter:  mikko     |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  2.0   
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 (In [4263]) If we cannot even make sense of the request, don't bother with
 attempting a reply.

 Fixes #561

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/561#comment:2>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator