From varnish-bugs at projects.linpro.no  Fri Feb  1 22:17:13 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 01 Feb 2008 22:17:13 -0000
Subject: [Varnish] #162: Varnish trunk dies with assert error in
	SES_Delete()
In-Reply-To: <052.06515aaec000ba8f6489d0b0e4ad254c@projects.linpro.no>
References: <052.06515aaec000ba8f6489d0b0e4ad254c@projects.linpro.no>
Message-ID: <061.0417b524ceae2284d64622160ba5bc11@projects.linpro.no>

#162: Varnish trunk dies with assert error in SES_Delete()
---------------------------------------------------------+------------------
 Reporter:  anders                                       |        Owner:  des          
     Type:  defect                                       |       Status:  reopened     
 Priority:  high                                         |    Milestone:  Varnish 1.1.2
Component:  varnishd                                     |      Version:  1.1          
 Severity:  normal                                       |   Resolution:               
 Keywords:  varnishd core dump SES_Delete cache_session  |  
---------------------------------------------------------+------------------
Changes (by anders):

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

Comment:

 I am running trunk/2415 with:

 - madvise patch (http://anders.fupp.hnet/test/varnishd_madvise.diff)

 - mmap patch (http://anders.fupp.net/test/varnish-patch-storage-mmap-sync)

 - polling, instead of kqueue (as kqueue gives me other crashes as
 mentioned in ticket 173)

 - obj.grace (vcl_fetch) and req.grace (vcl_recv) set to 5 minutes.

 And then I got a crash:

 {{{
 Child said (2, 934): <<Assert error in SES_Delete(), cache_session.c line
 339:
   Condition((sp->vcl) == 0) not true.
 >>
 Child said (2, 934): <<  errno = 54 (Connection reset by peer)
 >>
 Cache child died pid=934 status=0x86
 }}}

 This was after collecting around 600000 objects and around 20 GB data in
 the cache, running for a little less than 2 hours. This is on a server
 with 48 GB RAM, and 8 CPU cores. I did one change before doing the test
 here: added four more disks, making Varnish use 5 50 GB storage files on 5
 different RAID volumes - having a total disk cache of 250 GB.

 The backtrace:

 {{{
 (gdb) bt
 #0  0x0000000800d17fec in thr_kill () from /lib/libc.so.7
 #1  0x0000000800da1c5b in abort () from /lib/libc.so.7
 #2  0x0000000800674cf2 in lbv_assert (func=Could not find the frame base
 for "lbv_assert".
 ) at assert.c:63
 #3  0x000000000041dcf4 in SES_Delete (sp=0x4690879008) at
 cache_session.c:339
 #4  0x000000000041b62a in WRK_QueueSession (sp=0x4690879008)
     at cache_pool.c:318
 #5  0x000000000041568e in hsh_rush (oh=0x46b10a12e0) at cache_hash.c:289
 #6  0x0000000000415818 in HSH_Unbusy (o=0x8ea490000) at cache_hash.c:311
 #7  0x000000000040fc33 in cnt_fetch (sp=0x4695392008) at
 cache_center.c:370
 #8  0x00000000004117aa in CNT_Session (sp=0x4695392008) at steps.h:41
 #9  0x000000000041acad in wrk_do_one (w=0x7ffefe1f5ae0) at
 cache_pool.c:193
 #10 0x000000000041b1b0 in wrk_thread (priv=0x800f11200) at
 cache_pool.c:247
 #11 0x0000000800a9fa88 in pthread_getprio () from /lib/libthr.so.3
 #12 0x00007ffefdff6000 in ?? ()
 Cannot access memory at address 0x7ffefe1f6000
 (gdb) frame 3
 #3  0x000000000041dcf4 in SES_Delete (sp=0x4690879008) at
 cache_session.c:339
 339             AZ(sp->vcl);
 (gdb) print *sp
 $1 = {magic = 741317722, fd = -1, id = 11357, xid = 498268411, restarts =
 0,
   esis = 0, wrk = 0x7ffe8321fae0, sockaddrlen = 16, mysockaddrlen = 128,
   sockaddr = 0x4690879680, mysockaddr = 0x4690879700,
   addr = 0x4690879780 "84.209.33.147", port = 0x469087978e "12398",
   srcaddr = 0x4699a24770, doclose = 0x0, http = 0x46908791d8,
   http0 = 0x4690879420, ws = {{magic = 905626964, id = 0x4391f8 "sess",
       s = 0x4690879780 "84.209.33.147",
       f = 0x46908799c1
 "929a1199303665640:lv=1201891478937:ss=1201891469875; RMFD=011JL0rM", r =
 0x0, e = 0x469087d780 ""}}, ws_ses = 0x4690879794 "GET",
   ws_req = 0x4690879989 "", htc = {{magic = 1041886673, fd = 11357,
       ws = 0x4690879070, rxbuf = {b = 0x4690879794 "GET",
         e = 0x4690879989 ""}, pipeline = {b = 0x0, e = 0x0}}},
   t_open = 1201891640.1903741, t_req = 1201891640.226583,
   t_resp = nan(0x8000000000000), t_end = 1201891651.267303, grace = 300,
   step = STP_LOOKUP, cur_method = 0, handling = 4, sendbody = 0 '\0',
   wantbody = 1 '\001', err_code = 0, err_reason = 0x0, list = {
     vtqe_next = 0x0, vtqe_prev = 0x46b10a1318}, backend = 0x800f14140,
   bereq = 0x0, obj = 0x0, objhead = 0x46b10a12e0, vcl = 0x4689c03e20,
   mem = 0x4690879000, workreq = {list = {vtqe_next = 0x0, vtqe_prev =
 0x0},
     sess = 0x4690879008}, acct = {first = 1201891640.1903741, sess = 1,
     req = 1, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0},
   nhashptr = 6, ihashptr = 4, lhashptr = 54, hashptr = 0x4690879990}
 }}}

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

From varnish-bugs at projects.linpro.no  Fri Feb  8 22:56:31 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 08 Feb 2008 22:56:31 -0000
Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a patch
	provided
Message-ID: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>

#202: Compile Fails on OpenBSD -current / Half a patch provided
-----------------------+----------------------------------------------------
 Reporter:  bonetruck  |       Owner:  des
     Type:  defect     |      Status:  new
 Priority:  normal     |   Milestone:     
Component:  build      |     Version:  1.2
 Severity:  normal     |    Keywords:     
-----------------------+----------------------------------------------------
 The following patch solves the first compile issue.  However, it then gaks
 on NAN not being defined.  It's only used twice from what I see.  Can we
 swap it with something more portable or beat me with a clue stick?  See
 compile error following diff.  If I can get this to run well, I'll submit
 it for the ports tree.

 diff -uNr varnish-1.1.2.orig/lib/libvarnishapi/shmlog.c
 varnish-1.1.2/lib/libvarnishapi/shmlog.c
 --- varnish-1.1.2.orig/lib/libvarnishapi/shmlog.c       Wed Feb  6
 13:10:20 2008
 +++ varnish-1.1.2/lib/libvarnishapi/shmlog.c    Wed Feb  6 13:15:40 2008
 @@ -29,6 +29,7 @@
   * $Id: shmlog.c 1588 2007-06-28 10:25:47Z des $
   */

 +#include <sys/types.h>
  #include <sys/mman.h>

  #include <assert.h>

 >>>Compile error:
 Making all in varnishd
 gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include   -include config.h
 -DVARNISH_STATE_DIR='"/tmp/varnishd/var/varnish"' -g -O2 -MT varnishd-
 cache_center.o -MD -MP -MF .deps/varnishd-cache_center.Tpo -c -o varnishd-
 cache_center.o `test -f 'cache_center.c' || echo './'`cache_center.c
 cache_center.c: In function `cnt_done':
 cache_center.c:212: error: `NAN' undeclared (first use in this function)
 cache_center.c:212: error: (Each undeclared identifier is reported only
 once
 cache_center.c:212: error: for each function it appears in.)
 *** Error code 1

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

From varnish-bugs at projects.linpro.no  Fri Feb  8 23:20:44 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 08 Feb 2008 23:20:44 -0000
Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a
	patch provided
In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
Message-ID: <064.2633180afc8145fa815344c3fcd50b56@projects.linpro.no>

#202: Compile Fails on OpenBSD -current / Half a patch provided
-----------------------+----------------------------------------------------
 Reporter:  bonetruck  |        Owner:  des
     Type:  defect     |       Status:  new
 Priority:  normal     |    Milestone:     
Component:  build      |      Version:  1.2
 Severity:  normal     |   Resolution:     
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by phk):

 You don't tell what "the first compile issue" is for which you provide a
 fix, I'm not terribly keen in importing fixes if I don't even know what
 they're supposed to fix.

 NAN comes from <math.h> according to C99 (page 197 in the draft PDF I
 have) and cache_center.c #includes that.

 Can you please check that your <math.h> in fact does define NAN as it
 should ?

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

From varnish-bugs at projects.linpro.no  Sat Feb  9 14:05:53 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 09 Feb 2008 14:05:53 -0000
Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a
	patch provided
In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
Message-ID: <064.e49b9bfee503e283ce886309b7d132d1@projects.linpro.no>

#202: Compile Fails on OpenBSD -current / Half a patch provided
-----------------------+----------------------------------------------------
 Reporter:  bonetruck  |        Owner:  des
     Type:  defect     |       Status:  new
 Priority:  normal     |    Milestone:     
Component:  build      |      Version:  1.2
 Severity:  normal     |   Resolution:     
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by bonetruck):

 Sorry, the first compile issue is solved by the additional include to get
 the mmap family of system calls.  Here's a link to the man page:
 http://www.openbsd.org/cgi-bin/man.cgi?query=mmap  Both includes are
 required.

 As for defining NAN, I recursively grepped my /usr/include directory on
 down and didn't find NAN anywhere including in math.h.  A bit stumped on
 this one...

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

From varnish-bugs at projects.linpro.no  Sat Feb  9 16:01:32 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 09 Feb 2008 16:01:32 -0000
Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a
	patch provided
In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
Message-ID: <064.1ed73d4de8b2716f0e1d72d9dbe833e6@projects.linpro.no>

#202: Compile Fails on OpenBSD -current / Half a patch provided
-----------------------+----------------------------------------------------
 Reporter:  bonetruck  |        Owner:  des
     Type:  defect     |       Status:  new
 Priority:  normal     |    Milestone:     
Component:  build      |      Version:  1.2
 Severity:  normal     |   Resolution:     
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by phk):

 Ok, <sys/types.h> added.

 I would be surprised of OpenBSD doesn't have NAN at all.

 Does it have the nan(3) function then ?

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

From varnish-bugs at projects.linpro.no  Sun Feb 10 16:38:23 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sun, 10 Feb 2008 16:38:23 -0000
Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a
	patch provided
In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
Message-ID: <064.443f279dd21cdbcaf87345a558f4fd8f@projects.linpro.no>

#202: Compile Fails on OpenBSD -current / Half a patch provided
-----------------------+----------------------------------------------------
 Reporter:  bonetruck  |        Owner:  des
     Type:  defect     |       Status:  new
 Priority:  normal     |    Milestone:     
Component:  build      |      Version:  1.2
 Severity:  normal     |   Resolution:     
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by bonetruck):

 I've grepped the entire source tree for NAN with no real success.  In
 answer to your question, man 3 nan returns nothing.  However, the isnan
 family is described here: http://www.openbsd.org/cgi-
 bin/man.cgi?query=isinf

 I have a query out to the OpenBSD mailing list asking for some pointers.
 I'll update you once I have something.

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

From varnish-bugs at projects.linpro.no  Sun Feb 10 17:33:15 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sun, 10 Feb 2008 17:33:15 -0000
Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a
	patch provided
In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
Message-ID: <064.a8d3081418c4c6d5a95b2f94261c98be@projects.linpro.no>

#202: Compile Fails on OpenBSD -current / Half a patch provided
-----------------------+----------------------------------------------------
 Reporter:  bonetruck  |        Owner:  des       
     Type:  defect     |       Status:  closed    
 Priority:  normal     |    Milestone:            
Component:  build      |      Version:  1.2       
 Severity:  normal     |   Resolution:  worksforme
 Keywords:             |  
-----------------------+----------------------------------------------------
Changes (by phk):

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

Comment:

 I'll close this ticket for now, and you can reopen it when we have more
 information.

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

From varnish-bugs at projects.linpro.no  Mon Feb 11 00:48:08 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 11 Feb 2008 00:48:08 -0000
Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a
	patch provided
In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
Message-ID: <064.b6a672a936e2efd9ac0123c9d109c05d@projects.linpro.no>

#202: Compile Fails on OpenBSD -current / Half a patch provided
-----------------------+----------------------------------------------------
 Reporter:  bonetruck  |        Owner:  des     
     Type:  defect     |       Status:  reopened
 Priority:  normal     |    Milestone:          
Component:  build      |      Version:  1.2     
 Severity:  normal     |   Resolution:          
 Keywords:             |  
-----------------------+----------------------------------------------------
Changes (by bonetruck):

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

Comment:

 Here's a link to the archived thread of a discussion I initiated on the
 misc mailing list.  Note Marc Espie's response, which I take as the most
 authoritative of the bunch, indicates I should look for something other
 than NAN to use...

 http://www.nabble.com/Where-is-NAN-Defined--tt15398150.html

 Not sure where to proceed from here.  Ideas?

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

From varnish-bugs at projects.linpro.no  Tue Feb 12 11:05:24 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 12 Feb 2008 11:05:24 -0000
Subject: [Varnish] #110: varnishd leaking virtual memory
In-Reply-To: <056.670fe3911761765f5d209fdf09ceb74b@projects.linpro.no>
References: <056.670fe3911761765f5d209fdf09ceb74b@projects.linpro.no>
Message-ID: <065.f86a36d190aa1369fc7d4ce5be6f94ec@projects.linpro.no>

#110: varnishd leaking virtual memory
---------------------------------+------------------------------------------
 Reporter:  chrisrixon           |        Owner:  phk        
     Type:  defect               |       Status:  new        
 Priority:  normal               |    Milestone:  Varnish 1.2
Component:  varnishd             |      Version:  1.0.4      
 Severity:  major                |   Resolution:             
 Keywords:  leak virtual memory  |  
---------------------------------+------------------------------------------
Comment (by chrisrixon):

 I just installed 1.1.2 as I noticed a couple of leaks have been plugged.
 Sadly its still leaking VM in the same way. (3G in about 5 mins)

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

From varnish-bugs at projects.linpro.no  Tue Feb 12 22:23:32 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 12 Feb 2008 22:23:32 -0000
Subject: [Varnish] #162: Varnish trunk dies with assert error in
	SES_Delete()
In-Reply-To: <052.06515aaec000ba8f6489d0b0e4ad254c@projects.linpro.no>
References: <052.06515aaec000ba8f6489d0b0e4ad254c@projects.linpro.no>
Message-ID: <061.5056c34336c5a5909646d04313ed88ce@projects.linpro.no>

#162: Varnish trunk dies with assert error in SES_Delete()
---------------------------------------------------------+------------------
 Reporter:  anders                                       |        Owner:  des          
     Type:  defect                                       |       Status:  closed       
 Priority:  high                                         |    Milestone:  Varnish 1.1.2
Component:  varnishd                                     |      Version:  1.1          
 Severity:  normal                                       |   Resolution:  fixed        
 Keywords:  varnishd core dump SES_Delete cache_session  |  
---------------------------------------------------------+------------------
Changes (by des):

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

Comment:

 Not the same bug; please open a new ticket.

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

From varnish-bugs at projects.linpro.no  Wed Feb 13 11:42:15 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 13 Feb 2008 11:42:15 -0000
Subject: [Varnish] #188: thread pileup
In-Reply-To: <054.501398c9432dffc43debd3778be2327e@projects.linpro.no>
References: <054.501398c9432dffc43debd3778be2327e@projects.linpro.no>
Message-ID: <063.f8d81f195a033a1378667915ea6c48e5@projects.linpro.no>

#188: thread pileup
----------------------+-----------------------------------------------------
 Reporter:  steinove  |        Owner:  phk     
     Type:  defect    |       Status:  assigned
 Priority:  high      |    Milestone:          
Component:  varnishd  |      Version:  1.1.1   
 Severity:  normal    |   Resolution:          
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by nanor):

 Hi, [[BR]]

 I think we encounter the same problem.[[BR]]

 After reaching hi Client connections rate (about 5000-6000/second),
 we have a very low "Client requests received (abour 50/70/s)"; hight
 "overflowed work requests" rate and hight "worker threads not created" and
 "worker threads limited".
 The load average grow very very fast to 800/900 of load average and
 service became unavailable. (less with a kern.maxusers=1024).
 [[BR]]

 And yes, we have some requests that need some time on the backends to be
 retrieve.

 System : FreeBSD 7.0-RC1 GENERIC  amd64[[BR]]
 Varnish : varnish-1.1.2[[BR]]


 Hard : 4 GM RAM/Intel(R) Xeon(R) CPU           L5310  @ 1.60GHz x 4[[BR]]



 Does varnish will be able to handle this ?


 regards,
 /nanor

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

From varnish-bugs at projects.linpro.no  Wed Feb 13 15:56:17 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 13 Feb 2008 15:56:17 -0000
Subject: [Varnish] #203: X-Forwarded-For handling
Message-ID: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>

#203: X-Forwarded-For handling
----------------------+-----------------------------------------------------
 Reporter:  des       |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 Varnish always adds an {{{X-Forwarded-For}}} header when talking to the
 backend.  There are at least two problems with this:

  * {{{X-Forwarded-For}}} should probably be omitted for a normal non-pass,
 non-pipe request.
  * in pass mode, if {{{X-Forwarded-For}}} is already present, the client's
 IP address should be appended to it, separated from the pre-existing value
 by a comma.
  * post mode is trickier.  Assuming the request ''is'' an HTTP request, it
 is of course possible to add / modify {{{X-Forwarded-For}}} before
 entering post mode, but it won't be possible to modify subsequent requests
 on the same connection.  This can be mitigated by also adding
 {{{Connection: close}}} to the request.

 All of this can (and probably should) be implemented entirely in VCL.

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

From varnish-bugs at projects.linpro.no  Wed Feb 13 16:04:15 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 13 Feb 2008 16:04:15 -0000
Subject: [Varnish] #204: Handling of HTTP headers
Message-ID: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no>

#204: Handling of HTTP headers
-------------------------+--------------------------------------------------
 Reporter:  des          |       Owner:  phk  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishd     |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------
 Strictly speaking, when issuing a normal (non-pass, non-pipe) request to
 the backend, all headers that somehow identify the client should be
 removed, to avoid the chance of the backend basing its response on one of
 them.  This includes headers like {{{User-Agent}}}, {{{X-Forwarded-For}}}
 (see #203), {{{Via}}}, etc.

 This can of course all be done in VCL.

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

From varnish-bugs at projects.linpro.no  Wed Feb 13 16:04:25 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 13 Feb 2008 16:04:25 -0000
Subject: [Varnish] #203: X-Forwarded-For handling
In-Reply-To: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
References: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
Message-ID: <058.7f3f3919cb1582d68757537818cb6c24@projects.linpro.no>

#203: X-Forwarded-For handling
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by des):

  * type:  defect => enhancement

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

From varnish-bugs at projects.linpro.no  Wed Feb 13 16:12:07 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 13 Feb 2008 16:12:07 -0000
Subject: [Varnish] #205: Better Vary handling
Message-ID: <049.846686e4844c7a66c8a13a09abdee20a@projects.linpro.no>

#205: Better Vary handling
-------------------------+--------------------------------------------------
 Reporter:  des          |       Owner:  phk  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishd     |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------
 From conversations on IRC, I am under the impression that there are
 backends that support content negotiation but do not emit a {{{Vary}}}
 header unless the request contains {{{Accept}}} headers.

 It may be appropriate to send no-op {{{Accept}}} headers to trick the
 backend into sending us the {{{Vary}}} header.  The following should be
 sufficient for most cases:

 {{{
 Accept: */*
 Accept-Language: *
 Accept-Charset: *
 Accept-Encoding: identity
 }}}

 Note that {{{Accept-Encoding}}} can ''not'' be set to {{{*}}}, as the
 backend might then send back a compressed response which the client would
 be unable to process.

 This can of course be implemented in VCL.

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

From varnish-bugs at projects.linpro.no  Wed Feb 13 18:45:31 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 13 Feb 2008 18:45:31 -0000
Subject: [Varnish] #152: Varnish 1.1.1 compile fails on Solaris 10
In-Reply-To: <053.a7b950c8b9db8b2dd5be8558033bb4aa@projects.linpro.no>
References: <053.a7b950c8b9db8b2dd5be8558033bb4aa@projects.linpro.no>
Message-ID: <062.eac9e353c3429860e5fa8105beb20030@projects.linpro.no>

#152: Varnish 1.1.1 compile fails on Solaris 10
---------------------+------------------------------------------------------
 Reporter:  jimlane  |        Owner:  des                
     Type:  defect   |       Status:  assigned           
 Priority:  normal   |    Milestone:  Varnish 2.0 release
Component:  build    |      Version:  trunk              
 Severity:  normal   |   Resolution:                     
 Keywords:           |  
---------------------+------------------------------------------------------
Changes (by des):

  * version:  1.1.1 => trunk

Comment:

 All of these issues have been addressed.  A few others remain:

  * correct compiler invocation for VCL, depending on the toolchain used to
 build Varnish
  * timeouts (Varnish uses {{{SO_RCVTIMEO}}} and {{{SO_SNDTIMEO}}}, which
 Solaris doesn't support)
  * probably some other stuff I've forgotten...

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:10:15 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:10:15 -0000
Subject: [Varnish] #205: Better Vary handling
In-Reply-To: <049.846686e4844c7a66c8a13a09abdee20a@projects.linpro.no>
References: <049.846686e4844c7a66c8a13a09abdee20a@projects.linpro.no>
Message-ID: <058.a37773345a8161ae5e919c4de1db5435@projects.linpro.no>

#205: Better Vary handling
---------------------------+------------------------------------------------
 Reporter:  des            |        Owner:  des  
     Type:  enhancement    |       Status:  new  
 Priority:  normal         |    Milestone:       
Component:  documentation  |      Version:  trunk
 Severity:  normal         |   Resolution:       
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by phk):

  * owner:  phk => des
  * component:  varnishd => documentation

Comment:

 I would read such backend behaviour to be in non-compliance with RFC2616.

 You are right that this can be done in VCL, so I don't think there is any
 benefit from doing anything about it in the varnish source code.

 This is probably something that belongs in documentation/FAQ more than
 anything else.

 Notice that an easier way to do this might be to construct the missing
 Vary: header in vcl_fetch, provided that you know what your backend does
 Vary on.

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:19:48 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:19:48 -0000
Subject: [Varnish] #203: X-Forwarded-For handling
In-Reply-To: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
References: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
Message-ID: <058.10decd9e959ffebaa302f8873fd960db@projects.linpro.no>

#203: X-Forwarded-For handling
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by phk):

 I don't think I have ever found any definitive documentation of how X
 -Forwaded-For is supposed to work, as indicated by the X- it may not
 exist.

 The X-Forwarded-For is added in the filtering step, so it can be removed
 in either of vcl_miss, vcl_pass or vcl_pipe if you do not want to send it
 to the backend (and this should be documented)

 With respect to editing kontra appending, I am not sure if we append an
 extra or overwrite the existing X-Forwarded-For header, the last would be
 a bug I think.  (We have issues in this
 area in general.)

 I'm not particular religious about appending with a comma or adding a new
 line, lacking a standard we should do what is most robust with web-
 servers.

 Where you write "post mode" above, you mean "pipe" mode.

 We know that the first transaction on a piped connection is a HTTP,
 because otherwise we would never get that far in the first place.
 Inserting, as we do, X-Forwarded-For is perfectly sensible, and I would
 say, required, since we otherwise would deprive the backend of a chance to
 log things correctly.  What happens on the connection after we send the
 HTTP request to the backend is out of our hands.

 Ideally pass should be able to handle all HTTP transactions, also Expect
 etc, but there may be no cost-benefit from doing all that work.

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:28:32 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:28:32 -0000
Subject: [Varnish] #204: Handling of HTTP headers
In-Reply-To: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no>
References: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no>
Message-ID: <058.4964234b39f3dde53e911f35f9923a65@projects.linpro.no>

#204: Handling of HTTP headers
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by phk):

 If for "should be removed" I read "should be possible to remove" I agree.
 If we removed them in general and by default, we could have saved
 ourselves the trouble of the Vary handling code.

 One particular thing we should document here, is that if User-Agent is
 Vary'ed on, it is very beneficial to normalize that header in Varnish.  By
 sending no more than the necessary number of variants are sent to the
 backend one avoids getting a myriad of objects with vary identification
 strings that vary in subtle but unimportant ways.

 The only thing here that I see as a non documentation issue, is that VCL
 could use a facility for saying "remove all headers but these", because at
 present there is no way to get a list of which headers are in fact
 present, apart from direct guesses as to their names.

 We talked about a general "HTTP washing" feature at some point, this
 sounds like that.

 Apart from that, I think this is all documentation issues.

 Poul-Henning

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:37:27 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:37:27 -0000
Subject: [Varnish] #203: X-Forwarded-For handling
In-Reply-To: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
References: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
Message-ID: <058.2c60b256cb7897304764058b63e4eca7@projects.linpro.no>

#203: X-Forwarded-For handling
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by des):

 You are right - there is no formal definition, it is a de-facto standard
 introduced by Squid and later adopted by Apache's {{{mod_proxy}}}.  Many
 web applications have come to depend on it (e.g. ignore a session cookie
 sent by a different client IP than it was originally issued to)

 We currently add an extra header - I'm not sure the backend will interpret
 that correctly.  It may vary from backend to backend.

 re post mode vs pipe mode, yes; but it is possible that the backend will
 be confused (or produce the wrong results) if subsequent requests don't
 include {{{X-Forwarded-For}}}.  That is not our problem, though; it's for
 the admin to decide, and if necessary add {{{Connection: close}}}.

 Anyway, I am not advocating adding any of this logic to the C code.  On
 the contrary, I think {{{X-Forwarded-For}}} handling should be moved from
 C to VCL, so the admin has full control over it, and we can wash our hands
 of it.

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:45:00 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:45:00 -0000
Subject: [Varnish] #204: Handling of HTTP headers
In-Reply-To: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no>
References: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no>
Message-ID: <058.2aca7ba348f3177e1051fcb5a5ce599d@projects.linpro.no>

#204: Handling of HTTP headers
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by des):

 No, we still need {{{Vary}}}, because that is something the server sends,
 so we don't know in advance that we need to add a particular header to the
 hash string.  Doing so systematically would be very inefficient.

 Re {{{Vary: User-Agent}}} for compression (which is the most common use of
 it), I personally think it's a backend bug.  The last time I checked, the
 market share of Netscape 4 (which is the only browser that actually needs
 this) was less than 0.001%.

 The "remove all headers but these" issue can be solved by allowing VCL to
 loop over a list of headers, instead of adding a special-case construct.
 Loops in VCL should be safe as long as we can make sure that the number of
 iterations will always be finite and small.

 Similarly, it would be ''very'' useful to be able to examine, modify and
 remove individual fields of certain headers (primarily {{{Cookie}}} and
 {{{Set-Cookie}}}) instead of having to do regexp substitutions on the full
 header; and it would be equally useful to be able to iterate over them,
 for instance in order to "remove all cookies except the session cookie".

 (speaking of which, what is the value of {{{obj.http.cookie}}} if multiple
 {{{Cookie}}} headers are specified?)

 I completely agree with you that this is mostly a documentation issue.

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:50:00 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:50:00 -0000
Subject: [Varnish] #205: Better Vary handling
In-Reply-To: <049.846686e4844c7a66c8a13a09abdee20a@projects.linpro.no>
References: <049.846686e4844c7a66c8a13a09abdee20a@projects.linpro.no>
Message-ID: <058.c427845d2beea9c3349997c6ffc9877c@projects.linpro.no>

#205: Better Vary handling
---------------------------+------------------------------------------------
 Reporter:  des            |        Owner:  des  
     Type:  enhancement    |       Status:  new  
 Priority:  normal         |    Milestone:       
Component:  documentation  |      Version:  trunk
 Severity:  normal         |   Resolution:       
 Keywords:                 |  
---------------------------+------------------------------------------------
Comment (by des):

 I don't see why this would violate RFC2616; it's just a matter of
 extracting information that we need from the backend.

 We definitely don't want to do this in C, though, and probably not even in
 the default VCL, but it can be useful to have in a VCL "toolbox".

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:50:26 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:50:26 -0000
Subject: [Varnish] #203: X-Forwarded-For handling
In-Reply-To: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
References: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
Message-ID: <058.4d3a405147aaa4f9d7f002d35557782c@projects.linpro.no>

#203: X-Forwarded-For handling
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  des     
     Type:  enhancement  |       Status:  assigned
 Priority:  normal       |    Milestone:          
Component:  varnishd     |      Version:  trunk   
 Severity:  normal       |   Resolution:          
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by des):

  * owner:  phk => des
  * status:  new => assigned

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:50:31 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:50:31 -0000
Subject: [Varnish] #204: Handling of HTTP headers
In-Reply-To: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no>
References: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no>
Message-ID: <058.a5740d10c2e85da82075f15e1a44543f@projects.linpro.no>

#204: Handling of HTTP headers
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  des     
     Type:  enhancement  |       Status:  assigned
 Priority:  normal       |    Milestone:          
Component:  varnishd     |      Version:  trunk   
 Severity:  normal       |   Resolution:          
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by des):

  * owner:  phk => des
  * status:  new => assigned

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:50:37 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:50:37 -0000
Subject: [Varnish] #205: Better Vary handling
In-Reply-To: <049.846686e4844c7a66c8a13a09abdee20a@projects.linpro.no>
References: <049.846686e4844c7a66c8a13a09abdee20a@projects.linpro.no>
Message-ID: <058.9a3df8dde115511cadb9108ef058eb7c@projects.linpro.no>

#205: Better Vary handling
---------------------------+------------------------------------------------
 Reporter:  des            |        Owner:  des     
     Type:  enhancement    |       Status:  assigned
 Priority:  normal         |    Milestone:          
Component:  documentation  |      Version:  trunk   
 Severity:  normal         |   Resolution:          
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by des):

  * status:  new => assigned

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:51:00 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:51:00 -0000
Subject: [Varnish] #204: Handling of HTTP headers
In-Reply-To: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no>
References: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no>
Message-ID: <058.3b62b431bb7dd3ca1b9e29f3e5f03b89@projects.linpro.no>

#204: Handling of HTTP headers
---------------------------+------------------------------------------------
 Reporter:  des            |        Owner:  des     
     Type:  enhancement    |       Status:  assigned
 Priority:  normal         |    Milestone:          
Component:  documentation  |      Version:  trunk   
 Severity:  normal         |   Resolution:          
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by des):

  * component:  varnishd => documentation

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:51:04 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:51:04 -0000
Subject: [Varnish] #203: X-Forwarded-For handling
In-Reply-To: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
References: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
Message-ID: <058.1ad41e96041173deee3c0e8019ae9662@projects.linpro.no>

#203: X-Forwarded-For handling
---------------------------+------------------------------------------------
 Reporter:  des            |        Owner:  des     
     Type:  enhancement    |       Status:  assigned
 Priority:  normal         |    Milestone:          
Component:  documentation  |      Version:  trunk   
 Severity:  normal         |   Resolution:          
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by des):

  * component:  varnishd => documentation

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 09:55:22 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 09:55:22 -0000
Subject: [Varnish] #203: X-Forwarded-For handling
In-Reply-To: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
References: <049.a9dfbcae697beab84bb891028f059653@projects.linpro.no>
Message-ID: <058.a07cae9296366e5cda06aaca2072d219@projects.linpro.no>

#203: X-Forwarded-For handling
---------------------------+------------------------------------------------
 Reporter:  des            |        Owner:  des     
     Type:  enhancement    |       Status:  assigned
 Priority:  normal         |    Milestone:          
Component:  documentation  |      Version:  trunk   
 Severity:  normal         |   Resolution:          
 Keywords:                 |  
---------------------------+------------------------------------------------
Comment (by phk):

 The reason I did it in the C-code originally was because we did not have
 the necessary VCL header-editing facilities.

 Today you can actually say:

 {{{
         if (bereq.http.x-forwarded-for) {
                 set bereq.http.X-forwarded-for =
                     bereq.http.X-forwarded-for ", "
                     regsub(client.ip, ":.*", "");
         } else {
                 set bereq.http.X-forwarded-for =
                     regsub(client.ip, ":.*", "");
         }
 }}}

 I'm not sure I see the benefit of pushing this to the default VCL given
 that the quite sensible default (moduls append bug) can be overridden
 already.

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 13:26:06 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 13:26:06 -0000
Subject: [Varnish] #206: Improved VCL primitives for header manipulation
Message-ID: <049.a382d66fd206944c4a15b1cc891e9d9a@projects.linpro.no>

#206: Improved VCL primitives for header manipulation
----------------------+-----------------------------------------------------
 Reporter:  des       |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 At some point, we should add support in VCL for:

  * Directly examining, modifying or removing individual fields of multi-
 value headers, particularly {{{Cookie}}} and {{{Set-Cookie}}}; for
 instance:

 {{{
     if (req.http.Cookie[session_id]) {
         pass;
     }
 }}}

  * Iterating over a finite list, particularly:
   * all HTTP headers in a request, object or response
   * all fields in a multi-value header

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 13:26:24 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 13:26:24 -0000
Subject: [Varnish] #206: Improved VCL primitives for header manipulation
In-Reply-To: <049.a382d66fd206944c4a15b1cc891e9d9a@projects.linpro.no>
References: <049.a382d66fd206944c4a15b1cc891e9d9a@projects.linpro.no>
Message-ID: <058.535623519eb10314155c2baa30885698@projects.linpro.no>

#206: Improved VCL primitives for header manipulation
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by des):

  * type:  defect => enhancement

Comment:

 misfiled

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

From varnish-bugs at projects.linpro.no  Thu Feb 14 13:35:50 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 14 Feb 2008 13:35:50 -0000
Subject: [Varnish] #207: Varnishlog core dumps
Message-ID: <052.2f47ce29b7dc8e87328922aa05bf1f91@projects.linpro.no>

#207: Varnishlog core dumps
------------------------+---------------------------------------------------
 Reporter:  anders      |       Owner:  phk                  
     Type:  defect      |      Status:  new                  
 Priority:  normal      |   Milestone:                       
Component:  varnishlog  |     Version:  trunk                
 Severity:  normal      |    Keywords:  varnish log core dump
------------------------+---------------------------------------------------
 After running varnishlog for a while, it core-dumps:

 {{{
 root at cache13:~# varnishlog -i Debug -I 'got event'
   383 Debug        c "vca_kev(): got event 0x0000 on closed fd"
 Segmentation fault: 11 (core dumped)
 }}}

 Varnish is still running when this happens. I am using Varnish trunk, up
 to date to commit 2344.

 The backtrace:

 {{{
 root at cache13:~# gdb -c varnishlog.core /usr/local/bin/varnishlog
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you
 are
 welcome to change it and/or distribute copies of it under certain
 conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for
 details.
 This GDB was configured as "amd64-marcel-freebsd"...
 Core was generated by `varnishlog'.
 Program terminated with signal 11, Segmentation fault.
 Reading symbols from /usr/local/lib/libvarnish.so.0...done.
 Loaded symbols for /usr/local/lib/libvarnish.so.0
 Reading symbols from /usr/lib/librt.so.1...done.
 Loaded symbols for /usr/lib/librt.so.1
 Reading symbols from /usr/local/lib/libvarnishcompat.so.0...done.
 Loaded symbols for /usr/local/lib/libvarnishcompat.so.0
 Reading symbols from /usr/local/lib/libvarnishapi.so.0...done.
 Loaded symbols for /usr/local/lib/libvarnishapi.so.0
 Reading symbols from /lib/libc.so.7...done.
 Loaded symbols for /lib/libc.so.7
 Reading symbols from /libexec/ld-elf.so.1...done.
 Loaded symbols for /libexec/ld-elf.so.1
 #0  0x00000008009450f4 in vsl_nextlog (vd=0x800d01000, pp=0x7fffffffe748)
     at shmlog.c:243
 243                     if (*p == SLT_WRAPMARKER) {
 (gdb) bt
 #0  0x00000008009450f4 in vsl_nextlog (vd=0x800d01000, pp=0x7fffffffe748)
     at shmlog.c:243
 #1  0x000000080094522f in VSL_NextLog (vd=0x800d01000, pp=0x7fffffffe798)
     at shmlog.c:273
 #2  0x0000000800945543 in VSL_Dispatch (vd=0x800d01000,
     func=0x4011b4 <VSL_H_Print>, priv=0x800c38cb8) at shmlog.c:334
 #3  0x0000000000401e5c in main (argc=5, argv=0x7fffffffe860)
     at varnishlog.c:362
 (gdb) frame 0
 #0  0x00000008009450f4 in vsl_nextlog (vd=0x800d01000, pp=0x7fffffffe748)
     at shmlog.c:243
 243                     if (*p == SLT_WRAPMARKER) {
 (gdb) p/x p
 $1 = 0x805e02167
 (gdb) p/x *vd
 $2 = {magic = 0x6e3bd69b, head = 0x800e00000, logstart = 0x800e00260,
   logend = 0x805e00260, ptr = 0x805e02167, fi = 0x0, rbuf = {
     0x0 <repeats 262 times>}, b_opt = 0x0, c_opt = 0x0, d_opt = 0x0,
   flags = 0x1, map = {0x4, 0x0, 0x4 <repeats 15 times>, 0x5, 0x5, 0x6,
 0x5,
     0x5, 0x4, 0x4, 0x5, 0x5, 0x4, 0x4, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x4,
 0x4,
     0x5, 0x5, 0x4, 0x4, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x4, 0x4, 0x5,
 0x5,
     0x4, 0x4, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x6, 0x5, 0x5, 0x4, 0x4, 0x5,
 0x5,
     0x6, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x4, 0x4, 0x6, 0x5, 0x4, 0x4,
 0x5,
     0x4, 0x4, 0x5, 0x5, 0x5, 0x4, 0x4, 0x5, 0x5, 0x5, 0x4, 0x4, 0x5, 0x5,
 0x5,
     0x4, 0x4, 0x5, 0x6, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x6, 0x6,
     0x5 <repeats 16 times>, 0x6, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5, 0x5,
 0x5,
     0x4, 0x4, 0x5, 0x4, 0x4, 0x5, 0x6, 0x5, 0x5, 0x4, 0x4, 0x5, 0x5, 0x5,
 0x5,
     0x5, 0x4, 0x4, 0x5, 0x4, 0x4, 0x4, 0x4, 0x5 <repeats 15 times>, 0x4,
 0x4,
     0x5, 0x5, 0x5, 0x5, 0x5, 0x4, 0x4, 0x5, 0x5, 0x5, 0x6, 0x4, 0x4, 0x5,
 0x5,
     0x5, 0x4, 0x4, 0x5, 0x4, 0x4, 0x5, 0x4, 0x4, 0x4, 0x4, 0x5, 0x4, 0x4,
 0x5,
     0x5, 0x4, 0x4, 0x4, 0x4, 0x5, 0x5, 0x5, 0x5, 0x5...}, regflags = 0x5,
   regincl = 0x800d12060, regexcl = 0x0}
 }}}

 I had similar problems with varnishtop. Backtrace from varnishtop core-
 dump:

 {{{
 root at cache13:~# gdb -c varnishtop.core /usr/local/bin/varnishtop
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you
 are
 welcome to change it and/or distribute copies of it under certain
 conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for
 details.
 This GDB was configured as "amd64-marcel-freebsd"...

 warning: exec file is newer than core file.
 Core was generated by `varnishtop'.
 Program terminated with signal 10, Bus error.
 Reading symbols from /usr/local/lib/libvarnish.so.0...done.
 Loaded symbols for /usr/local/lib/libvarnish.so.0
 Reading symbols from /usr/lib/librt.so.1...done.
 Loaded symbols for /usr/lib/librt.so.1
 Reading symbols from /usr/local/lib/libvarnishcompat.so.0...done.
 Loaded symbols for /usr/local/lib/libvarnishcompat.so.0
 Reading symbols from /usr/local/lib/libvarnishapi.so.0...done.
 Loaded symbols for /usr/local/lib/libvarnishapi.so.0
 Reading symbols from /lib/libncurses.so.7...done.
 Loaded symbols for /lib/libncurses.so.7
 Reading symbols from /lib/libthr.so.3...done.
 Loaded symbols for /lib/libthr.so.3
 Reading symbols from /lib/libc.so.7...done.
 Loaded symbols for /lib/libc.so.7
 Reading symbols from /libexec/ld-elf.so.1...done.
 Loaded symbols for /libexec/ld-elf.so.1
 #0  0x00000000004016e1 in accumulate (
     p=0x8015cd29c "he_session.c,352,&ses_mem_mtx)") at varnishtop.c:115
 115                     tp2 = VTAILQ_PREV(tp, tophead, list);
 [New Thread 0x800f01290 (LWP 102318)]
 [New Thread 0x800f01120 (LWP 100206)]
 (gdb) bt
 #0  0x00000000004016e1 in accumulate (
     p=0x8015cd29c "he_session.c,352,&ses_mem_mtx)") at varnishtop.c:115
 #1  0x0000000000401c1f in accumulate_thread (arg=0x800f07000)
     at varnishtop.c:186
 #2  0x0000000800baca88 in pthread_getprio () from /lib/libthr.so.3
 #3  0x0000000000000000 in ?? ()
 Cannot access memory at address 0x7fffffbff000
 }}}

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

From varnish-bugs at projects.linpro.no  Fri Feb 15 08:03:32 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 15 Feb 2008 08:03:32 -0000
Subject: [Varnish] #173: Varnish dies with assert error in vca_kev
In-Reply-To: <052.8574406c7e5bafedecb6ebc1dc83f0bb@projects.linpro.no>
References: <052.8574406c7e5bafedecb6ebc1dc83f0bb@projects.linpro.no>
Message-ID: <061.bbc37b43cb1972efb2eca7d237ab55c8@projects.linpro.no>

#173: Varnish dies with assert error in vca_kev
----------------------------------------+-----------------------------------
 Reporter:  anders                      |        Owner:  phk   
     Type:  defect                      |       Status:  closed
 Priority:  high                        |    Milestone:        
Component:  varnishd                    |      Version:  trunk 
 Severity:  major                       |   Resolution:  fixed 
 Keywords:  varnishd core dump vca_kev  |  
----------------------------------------+-----------------------------------
Changes (by des):

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

Comment:

 Believed to be fixed by #2462.

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

From varnish-bugs at projects.linpro.no  Fri Feb 15 13:29:25 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 15 Feb 2008 13:29:25 -0000
Subject: [Varnish] #208: Show a subset of the full statistics
Message-ID: <049.b103958705022a94134a155b008f3cfd@projects.linpro.no>

#208: Show a subset of the full statistics
-------------------------+--------------------------------------------------
 Reporter:  des          |       Owner:  des  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishstat  |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------
 It should be possible to have {{{varnishstat}}} display only a restricted
 number of parameters, by specifying each of them on the command line.

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

From varnish-bugs at projects.linpro.no  Fri Feb 15 13:29:32 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 15 Feb 2008 13:29:32 -0000
Subject: [Varnish] #208: Show a subset of the full statistics
In-Reply-To: <049.b103958705022a94134a155b008f3cfd@projects.linpro.no>
References: <049.b103958705022a94134a155b008f3cfd@projects.linpro.no>
Message-ID: <058.11738087c47481053816c940053655ee@projects.linpro.no>

#208: Show a subset of the full statistics
-------------------------+--------------------------------------------------
 Reporter:  des          |        Owner:  des     
     Type:  enhancement  |       Status:  assigned
 Priority:  normal       |    Milestone:          
Component:  varnishstat  |      Version:  trunk   
 Severity:  normal       |   Resolution:          
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by des):

  * status:  new => assigned

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

From varnish-bugs at projects.linpro.no  Sat Feb 16 22:40:30 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 16 Feb 2008 22:40:30 -0000
Subject: [Varnish] #209: Blocking IP addresses
Message-ID: <053.4cec20efb78e5b2451ea44b227d84262@projects.linpro.no>

#209: Blocking IP addresses
----------------------+-----------------------------------------------------
 Reporter:  PK07030   |       Owner:  phk             
     Type:  task      |      Status:  new             
 Priority:  normal    |   Milestone:  Varnish 1.2     
Component:  varnishd  |     Version:  trunk           
 Severity:  normal    |    Keywords:  Block IP address
----------------------+-----------------------------------------------------
 Hello everyone,

 I've been using Varnish on my server for about the past 6 months. It's
 been working fine, but I'm in desperate need to block certain IP addresses
 from accessing my site. According to my host, I cannot use Apache to
 block, since Varnish is handling the requests.

 My friend who recommended Varnish suggested this code, but I was
 unsuccessful at getting it to work.

 ''Here is what I would do to solve this issue ASAP:''

 ''At the beginning of the varnish configuration file:''


 {{{
 acl block {
 "69.115.134.27";
 "67.85.5.65";
 "68.193.234.118";
 "128.6.30.205";
 "67.80.151.193";
 "68.196.243.246";
 "68.193.236.128";
 "67.83.204.43";
 "65.173.213.";
 "167.230.38.118";
 "63.139.32.226";
 "208.241.137.80";
 "67.84.137.36";
 "216.110.94.227";
 }
 }}}


 ''And somewhere in the vcl_recv subroutine (preferably first):''


 {{{
 if ( client.ip ~ block ) {
        error 403 "Go away, please";
 }
 }}}

 ''Then just restart Varnish."''


 '''Any suggestions?'''''''

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

From phk at phk.freebsd.dk  Sat Feb 16 22:42:30 2008
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 16 Feb 2008 22:42:30 +0000
Subject: [Varnish] #209: Blocking IP addresses 
In-Reply-To: Your message of "Sat, 16 Feb 2008 22:40:30 GMT."
	<053.4cec20efb78e5b2451ea44b227d84262@projects.linpro.no> 
Message-ID: <13466.1203201750@critter.freebsd.dk>

In message <053.4cec20efb78e5b2451ea44b227d84262 at projects.linpro.no>, "Varnish"
 writes:

> My friend who recommended Varnish suggested this code, but I was
> unsuccessful at getting it to work.

It would help a lot if you told us how it doesn't work...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From varnish-bugs at projects.linpro.no  Sun Feb 17 22:27:34 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sun, 17 Feb 2008 22:27:34 -0000
Subject: [Varnish] #176: Varnishreplay segfault upon start
In-Reply-To: <056.fc7795fe9d84336fa1eebd0935ef0294@projects.linpro.no>
References: <056.fc7795fe9d84336fa1eebd0935ef0294@projects.linpro.no>
Message-ID: <065.0936d6a56c658911635fd9fb08dc812e@projects.linpro.no>

#176: Varnishreplay segfault upon start
---------------------------+------------------------------------------------
 Reporter:  ebe at dmi.dk     |        Owner:  des        
     Type:  defect         |       Status:  closed     
 Priority:  normal         |    Milestone:  Varnish 1.2
Component:  varnishreplay  |      Version:  1.1.1      
 Severity:  normal         |   Resolution:  worksforme 
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by des):

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

Comment:

 Unable to reproduce

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

From varnish-bugs at projects.linpro.no  Mon Feb 18 10:37:51 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 18 Feb 2008 10:37:51 -0000
Subject: [Varnish] #210: The binary heap implementation does not scale
Message-ID: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no>

#210: The binary heap implementation does not scale
-------------------------+--------------------------------------------------
 Reporter:  phk          |       Owner:  phk  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishd     |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------
 The binary heap implementation does not scale well to multiple millions of
 objects.

 There are two different approaches that can be persued:

 Either keep one (gigantic) binary heap, but fragment the array for holding
 it, so that we don't have to realloc(3) it as one huge slap of memory.

 Or keep only the next couple of hours worth of data in the binary heap,
 and relegate objects further in the future to a (number of) somewhat
 unsorted lists, which are examined at regular intervals for objects that
 need to move into the binary heap.

 Think real hard...

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

From varnish-bugs at projects.linpro.no  Mon Feb 18 12:26:29 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 18 Feb 2008 12:26:29 -0000
Subject: [Varnish] #210: The binary heap implementation does not scale
In-Reply-To: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no>
References: <049.ce5f6a853698bc91425e2b2571bba8d7@projects.linpro.no>
Message-ID: <058.0b2efad871f6506fb56e3f53112e290e@projects.linpro.no>

#210: The binary heap implementation does not scale
-------------------------+--------------------------------------------------
 Reporter:  phk          |        Owner:  phk  
     Type:  enhancement  |       Status:  new  
 Priority:  normal       |    Milestone:       
Component:  varnishd     |      Version:  trunk
 Severity:  normal       |   Resolution:       
 Keywords:               |  
-------------------------+--------------------------------------------------
Old description:

> The binary heap implementation does not scale well to multiple millions
> of objects.
>
> There are two different approaches that can be persued:
>
> Either keep one (gigantic) binary heap, but fragment the array for
> holding it, so that we don't have to realloc(3) it as one huge slap of
> memory.
>
> Or keep only the next couple of hours worth of data in the binary heap,
> and relegate objects further in the future to a (number of) somewhat
> unsorted lists, which are examined at regular intervals for objects that
> need to move into the binary heap.
>
> Think real hard...

New description:

 The binary heap implementation does not scale well to multiple millions of
 objects.

 There are two different approaches that can be persued:

 Either keep one (gigantic) binary heap, but fragment the array for holding
 it, so that we don't have to realloc(3) it as one huge slab of memory.

 Or keep only the next couple of hours worth of data in the binary heap,
 and relegate objects further in the future to a (number of) somewhat
 unsorted lists, which are examined at regular intervals for objects that
 need to move into the binary heap.

 Think real hard...

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

From varnish-bugs at projects.linpro.no  Tue Feb 19 10:49:31 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 19 Feb 2008 10:49:31 -0000
Subject: [Varnish] #211: Cache child died status=0x9 after ping timeout
Message-ID: <056.72e0a770b957db259bb8010e11a4ad09@projects.linpro.no>

#211: Cache child died status=0x9 after ping timeout
------------------------+---------------------------------------------------
 Reporter:  davecheney  |       Owner:  des  
     Type:  defect      |      Status:  new  
 Priority:  normal      |   Milestone:       
Component:  build       |     Version:  trunk
 Severity:  normal      |    Keywords:       
------------------------+---------------------------------------------------
 trunk, r2513.

 Child is killed by SIGTERM by the master process after failing ping
 timeout, happens every 8 to 24 hours.

 [root at rado varnish-cache]# /opt/varnish-svn/sbin/varnishd -F -a :80 -f
 default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,120 -u varnish -g varnish
 -p client_http11=on -p backend_http11=on -p sess_timeout=30 -s
 file,/var/lib/varnish/varnish_storage.bin,2G -P /var/run/varnish.pid
 storage_file: filename: /var/lib/varnish/varnish_storage.bin size 2048 MB.
 Using old SHMFILE
 rolling(1)...
 rolling(2)...
 start child pid 1740
 Child said (2, 1740): <<Child starts>>
 Child said (2, 1740): <<managed to mmap 2147483648 bytes of 2147483648>>
 Child said (2, 1740): <<Ready>>
 Child not responding to ping
 Child not responding to ping
 Cache child died pid=1740 status=0x9
 Clean child
 Child cleaned
 start child pid 8242
 Child said (2, 8242): <<Child starts>>
 Child said (2, 8242): <<managed to mmap 2147483648 bytes of 2147483648>>
 Child said (2, 8242): <<Ready>>

 backend b1 { .host = "172.16.0.72"; }
 backend b2 { .host = "172.16.0.73"; }

 director default random {
         {
                 .backend = b1;
                 .weight = 1;
         }
         {
                 .backend = b2;
                 .weight = 1;
         }
 }

 sub vcl_recv {
         set req.backend = b1;
         set req.backend = b2;
         set req.backend = default;
         if (req.request != "GET" && req.request != "HEAD") {
                 pipe;
         }
         if (req.http.Expect) {
                 pipe;
         }
         if (req.http.Authenticate || req.http.Cookie) {
                 lookup;
         }
         lookup;
 }

 sub vcl_fetch {
         if (!obj.valid) {
                 error;
         }
         if (!obj.cacheable) {
                 pass;
         }
         if (obj.http.Set-Cookie) {
                 insert;
         }
         insert;
 }

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

From varnish-bugs at projects.linpro.no  Wed Feb 20 08:44:12 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 20 Feb 2008 08:44:12 -0000
Subject: [Varnish] #212: varnishd child not responding to ping and parent
	can't restart the child
Message-ID: <056.46cf6d90a9bd269550a4c9e066a3f12c@projects.linpro.no>

#212: varnishd child not responding to ping and parent can't restart the child
------------------------+---------------------------------------------------
 Reporter:  lixiaohong  |       Owner:  phk
     Type:  defect      |      Status:  new
 Priority:  normal      |   Milestone:     
Component:  varnishd    |     Version:  1.2
 Severity:  major       |    Keywords:     
------------------------+---------------------------------------------------
 Hi,

 After runing varnishd about 9 hours, varnishd report the following error:

 {{{
 Child not responding to ping
 Child not responding to ping
 Child not responding to ping
 Child not responding to ping
 Cache child died pid=87075 status=0x9
 Clean child
 Child cleaned
 start child pid 94594
 Pushing vcls failed:
 CLI communication error
 Child said (1, 94594): <<Child starts
 >>
 unlink ./bin.xtVqEETk
 k 1 rev 17
 }}}

 The new child don't start successfully, and the service is stoped.

 the stats before the error are about the following:
 {{{
 stats
 200 1706
      4192391  Client connections accepted
     11783481  Client requests received
     11524997  Cache hits
            0  Cache hits for pass
       258112  Cache misses
       258112  Backend connections success
            0  Backend connections failures
       257855  Backend connections reuses
       258037  Backend connections recycles
            4  Backend connections unused
         2691  N struct srcaddr
          558  N active struct srcaddr
         2114  N struct sess_mem
         1142  N struct sess
       201381  N struct object
       201374  N struct objecthead
       201168  N struct smf
            4  N small free smf
            1  N large free smf
           25  N struct vbe_conn
          225  N worker threads
          225  N worker threads created
            0  N worker threads not created
            0  N worker threads limited
            0  N queued work requests
          225  N overflowed work requests
            0  N dropped work requests
        56949  N expired objects
          104  N objects on deathrow
            0  HTTP header overflows
            0  Objects sent with sendfile
      7475721  Objects sent with write
      4192060  Total Sessions
     11783466  Total Requests
            0  Total pipe
            0  Total pass
       258109  Total fetch
   3301475803  Total header bytes
  39447641545  Total body bytes
       184168  Session Closed
         1406  Session Pipeline
            0  Session Read Ahead
     11673881  Session herd
    444725845  SHM records
     24582221  SHM writes
        31825  SHM MTX contention
       258492  allocator requests
       201163  outstanding allocations
   3493691392  bytes allocated
  65225785344  bytes free
       258112  Backend requests made
 }}}

 my start command is:
 {{{
 /usr/local/sbin/varnishd -d -a 0.0.0.0:80 -f /usr/local/etc/vcl.conf -u
 nobody -g nobody -T 10.71.5.25:8080 -s
 file,/data1/varnish/varnishd.swp,64G -w 252,-1,12 -p http_workspace=16384
 -p listen_depth=8192
 }}}

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

From varnish-bugs at projects.linpro.no  Wed Feb 20 12:00:28 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 20 Feb 2008 12:00:28 -0000
Subject: [Varnish] #209: Blocking IP addresses
In-Reply-To: <053.4cec20efb78e5b2451ea44b227d84262@projects.linpro.no>
References: <053.4cec20efb78e5b2451ea44b227d84262@projects.linpro.no>
Message-ID: <062.c425320f169b9a94388b4c38f5d6e0bc@projects.linpro.no>

#209: Blocking IP addresses
------------------------------+---------------------------------------------
 Reporter:  PK07030           |        Owner:  phk        
     Type:  task              |       Status:  closed     
 Priority:  normal            |    Milestone:  Varnish 1.2
Component:  varnishd          |      Version:  trunk      
 Severity:  normal            |   Resolution:  worksforme 
 Keywords:  Block IP address  |  
------------------------------+---------------------------------------------
Changes (by phk):

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

Comment:

 I can't seem to reproduce a problem in the above (using -trunk, I don't
 think there is any significant changes relative to 1.x).

 I do note that one of your addresses are invalid: "65.173.213." lacks a
 byte after the last period.

 Please provide more information about what actually happens when you try,
 run varnishd with -d -d and see if there are complaints etc.

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

From varnish-bugs at projects.linpro.no  Wed Feb 20 12:04:32 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 20 Feb 2008 12:04:32 -0000
Subject: [Varnish] #202: Compile Fails on OpenBSD -current / Half a
	patch provided
In-Reply-To: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
References: <055.4ca517ace2c1c5ce5ff1d626655516e2@projects.linpro.no>
Message-ID: <064.9f526ffa2c9abefedbc89eddf20e3dc5@projects.linpro.no>

#202: Compile Fails on OpenBSD -current / Half a patch provided
-----------------------+----------------------------------------------------
 Reporter:  bonetruck  |        Owner:  des     
     Type:  defect     |       Status:  reopened
 Priority:  normal     |    Milestone:          
Component:  build      |      Version:  1.2     
 Severity:  normal     |   Resolution:          
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by phk):

 Have you tried to pull the NAN relevant stuff over from a FreeBSD <math.h>
 and see if that works ?

 If so, we could test for this in autoconf and have a stunt/compat header
 for that case.

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

From varnish-bugs at projects.linpro.no  Wed Feb 20 14:12:12 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 20 Feb 2008 14:12:12 -0000
Subject: [Varnish] #209: Blocking IP addresses
In-Reply-To: <053.4cec20efb78e5b2451ea44b227d84262@projects.linpro.no>
References: <053.4cec20efb78e5b2451ea44b227d84262@projects.linpro.no>
Message-ID: <062.b8c2c4aeb749fb22b7878525b397fe63@projects.linpro.no>

#209: Blocking IP addresses
------------------------------+---------------------------------------------
 Reporter:  PK07030           |        Owner:  phk        
     Type:  task              |       Status:  reopened   
 Priority:  normal            |    Milestone:  Varnish 1.2
Component:  varnishd          |      Version:  trunk      
 Severity:  normal            |   Resolution:             
 Keywords:  Block IP address  |  
------------------------------+---------------------------------------------
Changes (by PK07030):

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

Comment:

 Syntax error notwithstanding, this code does not successfully block IP
 addresses.

 I'd like to know the proper methodology to block visitor IP addresses
 using Varnish.

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

From varnish-bugs at projects.linpro.no  Wed Feb 20 14:33:41 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Wed, 20 Feb 2008 14:33:41 -0000
Subject: [Varnish] #209: Blocking IP addresses
In-Reply-To: <053.4cec20efb78e5b2451ea44b227d84262@projects.linpro.no>
References: <053.4cec20efb78e5b2451ea44b227d84262@projects.linpro.no>
Message-ID: <062.2bffcf172272d7c796bdcef52ade64b4@projects.linpro.no>

#209: Blocking IP addresses
------------------------------+---------------------------------------------
 Reporter:  PK07030           |        Owner:  phk        
     Type:  task              |       Status:  reopened   
 Priority:  normal            |    Milestone:  Varnish 1.2
Component:  varnishd          |      Version:  trunk      
 Severity:  normal            |   Resolution:             
 Keywords:  Block IP address  |  
------------------------------+---------------------------------------------
Comment (by phk):

 This is the correct way to do it.

 And we can't help you much more than that, because you give us not details
 to work with.

 If you want further help, please describe at least the following:

 Which OS, kernel and varnish version do you use.

 Please include complete VCL code.

 Please document what happens when one of the to-be-blocked IP# contacts
 your server, also, and this may be crucial: what you expect to happen.

 If you totally want to avoid contact with those IP#, it may be a better
 strategy to simply block them in your operating systems firewall facility.

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

From varnish-bugs at projects.linpro.no  Thu Feb 21 20:44:27 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Thu, 21 Feb 2008 20:44:27 -0000
Subject: [Varnish] #213: Varnish crashes on SES_Delete(),
	cache_session.c line 340
Message-ID: <052.7ce88d4f130a0405121a4fb62801b0b5@projects.linpro.no>

#213: Varnish crashes on SES_Delete(), cache_session.c line 340
----------------------+-----------------------------------------------------
 Reporter:  anders    |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 I am running Varnish trunk/2518, in FreeBSD/amd64 7.0-RC1. Now and then
 Varnish crashes:

 1)

 {{{
 Feb 21 19:01:19 kartcache1 varnishd: Child (609) said <<Assert error
 in SES_Delete(), cache_session.c line 340:>>
 Feb 21 19:01:19 kartcache1 varnishd: Child (609) said
 <<Condition((sp->vcl) == 0) not true.>>
 Feb 21 19:01:19 kartcache1 varnishd: Child (609) said <<  errno = 32
 (Broken pipe)>>
 }}}

 Backtrace:

 {{{
 (gdb) bt
 #0  0x0000000800d17fec in thr_kill () from /lib/libc.so.7
 #1  0x0000000800da1c5b in abort () from /lib/libc.so.7
 #2  0x0000000800674f92 in lbv_assert (func=Could not find the frame base
 for "lbv_assert".
 ) at assert.c:65
 #3  0x000000000041cd84 in SES_Delete (sp=0x2da2a9d008) at
 cache_session.c:340
 #4  0x0000000000419eb2 in WRK_QueueSession (sp=0x2da2a9d008)
     at cache_pool.c:319
 #5  0x000000000041382e in hsh_rush (oh=0x2db1185c90) at cache_hash.c:288
 #6  0x0000000000413a88 in HSH_Unbusy (o=0xc98057000) at cache_hash.c:310
 #7  0x000000000040cc23 in cnt_fetch (sp=0x2d9bbb0008) at
 cache_center.c:376
 #8  0x000000000040e611 in CNT_Session (sp=0x2d9bbb0008) at steps.h:41
 #9  0x0000000000418edd in wrk_do_one (w=0x7fff82012ae0) at
 cache_pool.c:194
 #10 0x00000000004196ea in wrk_thread (priv=0x800f130c0) at
 cache_pool.c:248
 #11 0x0000000800a9fa38 in pthread_getprio () from /lib/libthr.so.3
 #12 0x00007fff81e13000 in ?? ()
 Cannot access memory at address 0x7fff82013000
 (gdb) frame 3
 #3  0x000000000041cd84 in SES_Delete (sp=0x2da2a9d008) at
 cache_session.c:340
 340             AZ(sp->vcl);
 (gdb) print *sp
 $1 = {magic = 741317722, fd = -1, id = 2981, xid = 1254738649, restarts =
 0,
   esis = 0, wrk = 0x7ffff81c1ae0, sockaddrlen = 16, mysockaddrlen = 128,
   sockaddr = 0x2da2a9d688, mysockaddr = 0x2da2a9d708,
   addr = 0x2da2a9d788 "81.167.12.230", port = 0x2da2a9d796 "14398",
   srcaddr = 0x2d95c3b7f0, doclose = 0x0, http = 0x2da2a9d1e0,
   http0 = 0x2da2a9d428, ws = {{magic = 905626964, id = 0x438c00 "sess",
       s = 0x2da2a9d788 "81.167.12.230", f = 0x2da2a9dafb " GMT", r = 0x0,
       e = 0x2da2a9f788 ""}}, ws_ses = 0x2da2a9d79c "GET",
   ws_req = 0x2da2a9da93 "", htc = {{magic = 1041886673, fd = 2981,
       ws = 0x2da2a9d070, rxbuf = {b = 0x2da2a9d79c "GET",
         e = 0x2da2a9da93 ""}, pipeline = {b = 0x0, e = 0x0}}},
   t_open = 1203620390.6953387, t_req = 1203620428.5261879,
   t_resp = nan(0x8000000000000), t_end = 1203620477.8366699, grace = 300,
   step = STP_LOOKUP, cur_method = 0, handling = 4, sendbody = 0 '\0',
   wantbody = 1 '\001', err_code = 0, err_reason = 0x0, list = {
     vtqe_next = 0x0, vtqe_prev = 0x2db1185cc8}, director = 0x800f2b288,
   backend = 0x0, bereq = 0x0, obj = 0x0, objhead = 0x2db1185c90,
   vcl = 0x2d89c03fa0, mem = 0x2da2a9d000, workreq = {list = {
       vtqe_next = 0x2daa501170, vtqe_prev = 0x540df0}, sess =
 0x2da2a9d008},
   acct = {first = 1203620390.6953387, sess = 1, req = 1, pipe = 0, pass =
 0,
     fetch = 0, hdrbytes = 0, bodybytes = 0}, nhashptr = 12, ihashptr = 4,
   lhashptr = 71, hashptr = 0x2da2a9da98}
 }}}

 2)

 {{{
 Feb 21 19:32:09 kartcache1 varnishd: Child (81816) said <<Assert error in
 SES_De
 lete(), cache_session.c line 340:>>
 Feb 21 19:32:09 kartcache1 varnishd: Child (81816) said
 <<Condition((sp->vcl)== 0) not true.>>
 }}}

 Backtrace:

 {{{
 (gdb) bt
 #0  0x0000000800d17fec in thr_kill () from /lib/libc.so.7
 #1  0x0000000800da1c5b in abort () from /lib/libc.so.7
 #2  0x0000000800674f92 in lbv_assert (func=Could not find the frame base
 for "lbv_assert".
 ) at assert.c:65
 #3  0x000000000041df52 in VCL_Get (vcc=0x807301160) at cache_vcl.c:85
 #4  0x00000000004100b7 in exp_prefetch (arg=0x0) at cache_expire.c:207
 #5  0x0000000800a9fa38 in pthread_getprio () from /lib/libthr.so.3
 #6  0x0000000000000000 in ?? ()
 Cannot access memory at address 0x7fffff9fe000
 (gdb) frame 3
 #3  0x000000000041df52 in VCL_Get (vcc=0x807301160) at cache_vcl.c:85
 85              AN(vcl_active);
 }}}

 My VCL:

 {{{
 backend default {
              set backend.host = "192.168.110.1";
              set backend.port = "80";
         }
 acl purge {
         "192.168.100.1"/32;
 }

 sub vcl_recv {
         set req.grace = 5m;
         if (req.http.host ~ "^(bars.*.foo.no|bazcache.foo.no)$") {
                 if (req.request == "GET" || req.request == "HEAD") {
                         lookup;
                 } elsif (req.request ~ "^(PURGE|REPURGE)$") {
                         if (client.ip ~ purge) {
                                 if (req.request == "REPURGE") {
                                         purge_url(req.url);
                                         error 200 "Repurged.";
                                 } else {
                                         lookup;
                                 }
                         } else {
                                 error 405 "Not allowed.";
                         }
                 } else {
                         pipe;
                 }
         } else {
                 error 403 "Access denied. Contact cacheadmin at foo.no if you
 have problems.";
         }
 }


 sub vcl_miss {
         if (req.request ~ "^(PURGE|REPURGE)$") {
                 error 404 "Not in cache.";
         } else {
                 fetch;
         }
 }
 sub vcl_hit {
         if (req.request == "PURGE") {
                 set obj.ttl = 0s;
                 error 200 "Purged.";
         } else {
                 deliver;
         }
 }
 sub vcl_fetch {
         set obj.grace = 5m;
         if (obj.status == 404 || obj.status == 503 || obj.status == 500) {
                 pass;
         }

         if (!obj.valid) {
                 error;
         }
         if (!obj.cacheable) {
                 pass;
         }

         if (obj.http.Cookie) {
                 remove obj.http.Cookie;
         }
         if (obj.http.Set-Cookie) {
                 remove obj.http.Set-Cookie;
         }
         insert;
 }
 sub vcl_hash {
         set req.hash += req.url;
         if (req.http.host ~ "^bars.*.foo.no$") {
                 set req.hash += "bars.foo.no";
         } else {
                 set req.hash += req.http.host;
         }
         hash;
 }
 }}}

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

From varnish-bugs at projects.linpro.no  Sat Feb 23 19:16:44 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Sat, 23 Feb 2008 19:16:44 -0000
Subject: [Varnish] #213: Varnish crashes on SES_Delete(),
	cache_session.c line 340
In-Reply-To: <052.7ce88d4f130a0405121a4fb62801b0b5@projects.linpro.no>
References: <052.7ce88d4f130a0405121a4fb62801b0b5@projects.linpro.no>
Message-ID: <061.6ca24710a544a914b15cd5f99ad9989c@projects.linpro.no>

#213: Varnish crashes on SES_Delete(), cache_session.c line 340
----------------------+-----------------------------------------------------
 Reporter:  anders    |        Owner:  des  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  varnishd  |      Version:  trunk
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * owner:  phk => des

Comment:

 fixed in 2529

 Should be merged to branches.

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

From varnish-bugs at projects.linpro.no  Mon Feb 25 09:34:23 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 25 Feb 2008 09:34:23 -0000
Subject: [Varnish] #214: Varnish crashes on assert error in EXP_Touch,
	cache_expire.c line 189
Message-ID: <052.ab0610f3d1078e0a2abdea328a97bb97@projects.linpro.no>

#214: Varnish crashes on assert error in EXP_Touch, cache_expire.c line 189
----------------------+-----------------------------------------------------
 Reporter:  anders    |       Owner:  phk                                    
     Type:  defect    |      Status:  new                                    
 Priority:  high      |   Milestone:                                         
Component:  varnishd  |     Version:  trunk                                  
 Severity:  blocker   |    Keywords:  varnishd crash EXP_Touch cache_expire.c
----------------------+-----------------------------------------------------
 I am running Varnish trunk/2537 on FreeBSD/amd64 7.0-RC1 (with SCHED_ULE),
 on Intel hardware. After running for around one hour, I got a crash:

 {{{
 Child said (2, 50412): <<Assert error in EXP_Touch(), cache_expire.c line
 189:>>
 Child said (2, 50412): <<  Condition((i) == 0 || errno == EBUSY) not
 true.>>
 Child said (2, 50412): <<  errno = 32 (Broken pipe)>>
 Cache child died pid=50412 status=0x86
 }}}

 Backtrace:

 {{{
 (gdb) bt
 #0  0x0000000800d17fec in thr_kill () from /lib/libc.so.7
 #1  0x0000000800da1c5b in abort () from /lib/libc.so.7
 #2  0x0000000800674f92 in lbv_assert (func=Could not find the frame base
 for "lbv_assert".
 ) at assert.c:65
 #3  0x000000000040fbbd in EXP_Touch (o=0x1489d24000,
 now=1203931145.6359677)
     at cache_expire.c:189
 #4  0x000000000040c058 in cnt_deliver (sp=0x468c03d008) at
 cache_center.c:156
 #5  0x000000000040e664 in CNT_Session (sp=0x468c03d008) at steps.h:42
 #6  0x000000000041949d in wrk_do_one (w=0x7ffffd7ecae0) at
 cache_pool.c:194
 #7  0x0000000000419caa in wrk_thread (priv=0x800f11220) at
 cache_pool.c:248
 #8  0x0000000800a9fa88 in pthread_getprio () from /lib/libthr.so.3
 #9  0x00007ffffd5ed000 in ?? ()
 Cannot access memory at address 0x7ffffd7ed000
 (gdb) frame 3
 #3  0x000000000040fbbd in EXP_Touch (o=0x1489d24000,
 now=1203931145.6359677)
     at cache_expire.c:189
 189             TRYLOCK(&exp_mtx, i);
 (gdb) print i
 $1 = 16
 (gdb) print exp_mtx
 $2 = 0x806276c90
 (gdb) print *exp_mtx
 $3 = <incomplete type>
 (gdb) print errno
 $4 = 0
 }}}

 My VCL:

 {{{
 backend default {
              set .host = "192.168.0.3";
              set .port = "80";
 }
 acl purge {
         "192.168.0.4"/32;
 }
 sub vcl_recv {
         set req.grace = 5m;
         if ((req.http.host ~ "^(cache.finn.no|finn.no|www.finn.no)$") ||
 (req.http.host == "banner.finn.no" && req.url ~
 "^/(jsp2|finn/gojsp|daily|board|auximg/papirfly|finn/cacheable|crossdomain.xml)"))
 {
                 if (req.request == "GET" || req.request == "HEAD") {
                         lookup;
                 } elsif (req.request == "PURGE") {
                         if (!client.ip ~ purge) {
                                 error 405 "Not allowed.";
                         }
                         lookup;
                 } else {
                         pipe;
                 }
         } else {
                 error 403 "Access denied. Contact cacheadmin at finn.no if
 you have problems.";
         }
 }
 sub vcl_miss {
         if (req.request == "PURGE") {
                 error 404 "Not in cache.";
         } else {
                 fetch;
         }
 }
 sub vcl_hit {
         if (req.request == "PURGE") {
                 set obj.ttl = 0s;
                 error 200 "Purged.";
         } else {
                 if (!obj.cacheable) {
                         pass;
                 } else {
                         deliver;
                 }
 }
 sub vcl_fetch {
         set obj.grace = 5m;
         if (!obj.valid) {
                 error obj.status;
         }
         if (obj.ttl < 86400s) {
                 set obj.ttl = 604800s;
         }
         if (obj.http.Cookie) {
                 remove obj.http.Cookie;
         }
         if (obj.http.Set-Cookie) {
                 remove obj.http.Set-Cookie;
         }
         insert;
 }
 }}}

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

From varnish-bugs at projects.linpro.no  Mon Feb 25 18:19:08 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Mon, 25 Feb 2008 18:19:08 -0000
Subject: [Varnish] #214: Varnish crashes on assert error in EXP_Touch,
	cache_expire.c line 189
In-Reply-To: <052.ab0610f3d1078e0a2abdea328a97bb97@projects.linpro.no>
References: <052.ab0610f3d1078e0a2abdea328a97bb97@projects.linpro.no>
Message-ID: <061.a5e4adf5a5c1986a0200d5936d431ccc@projects.linpro.no>

#214: Varnish crashes on assert error in EXP_Touch, cache_expire.c line 189
-----------------------------------------------------+----------------------
 Reporter:  anders                                   |        Owner:  phk  
     Type:  defect                                   |       Status:  new  
 Priority:  high                                     |    Milestone:       
Component:  varnishd                                 |      Version:  trunk
 Severity:  blocker                                  |   Resolution:       
 Keywords:  varnishd crash EXP_Touch cache_expire.c  |  
-----------------------------------------------------+----------------------
Comment (by anders):

 Commenting out line 189 in cache_expire.c, I get another crash:

 {{{
 Child said (2, 93540): <<Assert error in EXP_Touch(), cache_expire.c line
 199:>>
 Child said (2, 93540): <<  Condition((pthread_mutex_unlock(&exp_mtx)) ==
 0) not true.>>
 Child said (2, 93540): <<  errno = 32 (Broken pipe)>>
 }}}

 Backtrace:

 {{{
 (gdb) bt
 #0  0x0000000800d17fec in thr_kill () from /lib/libc.so.7
 #1  0x0000000800da1c5b in abort () from /lib/libc.so.7
 #2  0x0000000800674f92 in lbv_assert (func=Could not find the frame base
 for "lbv_assert".
 ) at assert.c:65
 #3  0x000000000040fc9b in EXP_Touch (o=0x1489b00000,
 now=1203963271.9050417)
     at cache_expire.c:199
 #4  0x000000000040c058 in cnt_deliver (sp=0x468d860008) at
 cache_center.c:156
 #5  0x000000000040e664 in CNT_Session (sp=0x468d860008) at steps.h:42
 #6  0x000000000041940d in wrk_do_one (w=0x7ffe41612ae0) at
 cache_pool.c:194
 #7  0x0000000000419c1a in wrk_thread (priv=0x800f11200) at
 cache_pool.c:248
 #8  0x0000000800a9fa88 in pthread_getprio () from /lib/libthr.so.3
 #9  0x0000000000000000 in ?? ()
 Cannot access memory at address 0x7ffe41613000
 (gdb) frame 3
 #3  0x000000000040fc9b in EXP_Touch (o=0x1489b00000,
 now=1203963271.9050417)
     at cache_expire.c:199
 199             UNLOCK(&exp_mtx);
 (gdb) print *exp_mtx
 $1 = <incomplete type>
 (gdb) print exp_mtx
 $2 = 0x806276c90
 }}}

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

From varnish-bugs at projects.linpro.no  Tue Feb 26 21:15:28 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Tue, 26 Feb 2008 21:15:28 -0000
Subject: [Varnish] #214: Varnish crashes on assert error in EXP_Touch,
	cache_expire.c line 189
In-Reply-To: <052.ab0610f3d1078e0a2abdea328a97bb97@projects.linpro.no>
References: <052.ab0610f3d1078e0a2abdea328a97bb97@projects.linpro.no>
Message-ID: <061.17becb2f15025373f71632a653d8741b@projects.linpro.no>

#214: Varnish crashes on assert error in EXP_Touch, cache_expire.c line 189
-----------------------------------------------------+----------------------
 Reporter:  anders                                   |        Owner:  phk   
     Type:  defect                                   |       Status:  closed
 Priority:  high                                     |    Milestone:        
Component:  varnishd                                 |      Version:  trunk 
 Severity:  blocker                                  |   Resolution:  fixed 
 Keywords:  varnishd crash EXP_Touch cache_expire.c  |  
-----------------------------------------------------+----------------------
Changes (by phk):

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

Comment:

 Solved, this was my misreading of pthread_mutex_trylock() man page.

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

From varnish-bugs at projects.linpro.no  Fri Feb 29 19:26:52 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 29 Feb 2008 19:26:52 -0000
Subject: [Varnish] #215: regex matches sporadically on identical request
Message-ID: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no>

#215: regex matches sporadically on identical request
----------------------+-----------------------------------------------------
 Reporter:  onitunes  |       Owner:  des  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  build     |     Version:  1.0.4
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 Here's my VCL file:

 backend production {
   set backend.host = "192.168.4.81";
   set backend.port = "http";
 }

 backend old_production {
   set backend.host = "192.168.4.111";
   set backend.port = "8000";
 }

 sub vcl_recv {
   if (req.url ~ "/old.*") {
     set req.backend = old_production;
   }
   else {
     set req.backend = production;
   }

   if (req.request == "GET" && req.url ~
 "\.(gif|jpg|png|swf|css|js)(\?.*)?$") {
     lookup;
   }
 }

 On this URL (and URLs like it):

      http://gtd.1kstudios.lan/old/task_assignments/actualize/7482

 , the backend chosen occasionally is production, not old_production. This
 gets worse over time (i.e. over the course of weeks). Repeatedly reloading
 the same page will eventually result in it loading in the correct backend,
 only to fail again later on subsequent reloads.

 This is on Fedora Core 4 64-bit x86.

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

From varnish-bugs at projects.linpro.no  Fri Feb 29 19:28:31 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 29 Feb 2008 19:28:31 -0000
Subject: [Varnish] #215: regex matches sporadically on identical request
In-Reply-To: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no>
References: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no>
Message-ID: <063.e5aafd3142c66547ba96b3f020a9934e@projects.linpro.no>

#215: regex matches sporadically on identical request
----------------------+-----------------------------------------------------
 Reporter:  onitunes  |        Owner:  des  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  build     |      Version:  1.0.4
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by onitunes):

 Of course, the regex could be matching correctly at all times and the `set
 req.backend = old_production` could be failing to register.

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

From varnish-bugs at projects.linpro.no  Fri Feb 29 23:36:13 2008
From: varnish-bugs at projects.linpro.no (Varnish)
Date: Fri, 29 Feb 2008 23:36:13 -0000
Subject: [Varnish] #215: regex matches sporadically on identical request
In-Reply-To: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no>
References: <054.0d8633e66b3bacc2f86276f0b0d3f45c@projects.linpro.no>
Message-ID: <063.4dc74458af9e091ea72785d1b5b1452a@projects.linpro.no>

#215: regex matches sporadically on identical request
----------------------+-----------------------------------------------------
 Reporter:  onitunes  |        Owner:  des  
     Type:  defect    |       Status:  new  
 Priority:  normal    |    Milestone:       
Component:  build     |      Version:  1.0.4
 Severity:  normal    |   Resolution:       
 Keywords:            |  
----------------------+-----------------------------------------------------
Comment (by onitunes):

 The same problem occurs on 1.1.2.

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