From lee.doolan at gmail.com  Tue Jun  8 21:40:35 2010
From: lee.doolan at gmail.com (Lee Doolan)
Date: Tue, 8 Jun 2010 14:40:35 -0700
Subject: [Varnish] #563: RE: Unable to mangle one of multiple Set-Cookie 
	headers.
Message-ID: <AANLkTikjgR4OBliPY6sgU6UTUl-9fMtw3xGPoHMizlRc@mail.gmail.com>

At LiveJournal, we were grappling with that problem.  There is a patch stored at
    git at github.com:leed25d/ljVarnishPatch.git

There is a very strong caveat regarding the github repository, though.
 It is likely
to change in some surprising ways (rebases, etc).

I have included the README below.

========================================================================


This is a copy of varnish-2.1.2el5 that has been patched for use at
LiveJournal.  The relevant code is in
    bin/varnishd/cache_center.c

other changes are for version identification.



CREDITS
=======

This patch is the result of a collaborative effort of the LiveJournal
engineering team: Lee Doolan, David Newhall II, Brian Tam and Matt
West along with independent contractors Lamont Lucas and John Cook.
This work was conceived and executed at LiveJournal and LiveJournal
paid for its development.



DISCLAIMER
==========

This source code is provided "as is" and without warranties as to
performance or merchantability. The author and/or distributors of this
source code may have made statements about this source code. Any such
statements do not constitute warranties and shall not be relied on by
the user in deciding whether to use this source code.

This source code is provided without any express or implied warranties
whatsoever. Because of the diversity of conditions and hardware under
which this source code may be used, no warranty of fitness for a
particular purpose is offered. The user is advised to test the source
code thoroughly before relying on it. The user must assume the entire
risk of using the source code.



DESCRIPTION
===========

Just before the vcl_fetch() routine is called, all of the headers are
examined and the value fields of all of the Set-Cookie headers are
concatenated together.  The value fields are separated by a known
separator string, and copied into an header named 'X-Set-Cookies'.
The X header can be referenced in the vcl_fetch() routine like this
(for instance):

    vcl_fetch() {


       if (beresp.http.X-Set-Cookies != "error") {
           ## Remove ljuniq and ljfsads Set-Cookies
           set beresp.http.X-Set-Cookies-Sent = beresp.http.X-Set-Cookies;
       }

    }

If an error arises during the execution of the patch, the
X-Set-Cookies header will have the value 'error'.  If there are no
Set-Cookie headers in the back-end response then the X-Set-Cookies
header will not exist.  After the vcl_fetch() routine runs, the
X-Set-Cookies header will be removed if it exists.


these commands can be useful:

    $ cd varnish-cache
    $ git archive --format=tar --prefix=varnish-cache/
varnish-2.1.2lja | gzip > ../varnish-2.1.2lja.tar.gz


========================================================================
========================================================================

Sometimes a back-end response can contain multiple Set-Cookie headers.
Since VCL provides no iteration facility, it is not possible to examine
these headers individually, so in the vcl_fetch() routine, when a
response is cached it must be cached with all of the Set-Cookie
headers or with none of them.

This patch forms a string of
   "s1Value<sep>s1Value<sep>...SnValue"

and assigns it as a value to a header named X-Set-Cookies.  This
procedure is performed immediately before the call to
vcl_fetch(). After the call to vcl_fetch(), the X-Set-Cookies header
is removed from the back-end response.

So, during the execution of vcl_fetch() the programmer has access to
   beresp.http.X-Set-Cookies

which can be examined, probably with regexeps not to put too fine a
point on it
    o  for the presence or absence of a particular cookie

    o  to extract the value of a particular cookie and assign it to
       another header, probably, but not necessarily, a Set-Cookie
       header.

In this way, the programmer choose to cache a response that has a
proper subset of the cookies that were originally returned from the
back-end.

Here is an example.  Suppose, for the sake of discussion, that the
back-end returns five Set-Cookie headers like this:

    Set-Cookie: c1=Cookie 1 value;path... yadda yadda
    Set-Cookie: c2=Cookie 2 value;path... yadda yadda
    Set-Cookie: c3=Cookie 3 value;path... yadda yadda
    Set-Cookie: c4=Cookie 4 value;path... yadda yadda
    Set-Cookie: c5=Cookie 5 value;path... yadda yadda



Let's further suppose that

    o  when cookie 5 is present, the response should be passed and not
       cached  otherwise the response can be cached.



If the response is to be cached:

    o  cookie4 is always removed

    o  cookie3 is never removed.

    o  if both of cookie1 and cookie2 are present then cookie2 should
       be removed.

    o  cookie 1 alone should be preserved

    o  cookie 2 alone should be preserved



So now lets see how we would do that:

   /**********
   /*  first, notice that if something goes sideways during the
   /*  construction of the X-Set-Cookies header, then it is set to the
   /*  string 'error'
   */
    if (beresp.http.X-Set-Cookies != "error") {
        if (beresp.http.X-Set-Cookies-Sent ~ "c5=") {
            return(pass);
        }
        /**  remove all cookies and put cookie 3 back  if it exists **/
        remove beresp.http.Set-Cookie;
        if (beresp.http.X-Set-Cookies ~ "c3=") {
            set beresp.http.Set-Cookie =
regsub(beresp.http.X-Set-Cookies, ".*(c3=.*)(<<SePaRaT0R>>)?.*",
"\1");
        }
        /**  if both of c1 and c2 are present, put c1 back and cache  **/
        if (beresp.http.X-Set-Cookies ~ "c1=" &&
beresp.http.X-Set-Cookies ~ "c2=") {
            set beresp.http.Set-Cookie =
regsub(beresp.http.X-Set-Cookies, ".*(c1=.*)(<<SePaRaT0R>>)?.*",
"\1");
            return(deliver);
        }
        /** cookie 1 alone should be preserved   **/
        if (beresp.http.X-Set-Cookies ~ "c1=") {
            set beresp.http.Set-Cookie =
regsub(beresp.http.X-Set-Cookies, ".*(c1=.*)(<<SePaRaT0R>>)?.*",
"\1");
        }
        /** cookie 2 alone should be preserved   **/
        if (beresp.http.X-Set-Cookies ~ "c2=") {
            set beresp.http.Set-Cookie =
regsub(beresp.http.X-Set-Cookies, ".*(c2=.*)(<<SePaRaT0R>>)?.*",
"\1");
        }
        return(deliver);
    }
    return(pass);

========================================================================
========================================================================

Here is a question and response on the varnish-dev mailing list:



Well, the 'Set-Cookie' header is unique amongst the headers of an HTTP
response in the respect that it can occur multiple times.  VCL has no
facility for looping over these headers and deciding which ones to
remove and which ones to keep.  With this patch, you have the option
of
    First, remove all the Set-Cookie headers like this:
        remove beresp.http.Set-Cookie;

    then, replace the ones that you want to keep by extracting them
    from the X-Set-Cookies header with regsuball(). ie:
        set beresp.http.Set-Cookie =
regsuball(beresp.http.X-Set-Cookies, "keep1 regexp");
        set beresp.http.Set-Cookie =
regsuball(beresp.http.X-Set-Cookies, "keep2 regexp");
        set beresp.http.Set-Cookie =
regsuball(beresp.http.X-Set-Cookies, "and so forth");





--- sky at crucially.net wrote:

From: sky at crucially.net
To: lee.doolan at volcanomail.com,varnish-dev at varnish-cache.org
Subject: Re: [PATCH] Concatenate Set-Cookie headers before a call to vcl_fetch()
Date: Sun, 6 Jun 2010 20:48:34 +0000

Just curious, what is the use case?

Thanks
Artur
Sent via BlackBerry by AT&T

-----Original Message-----
From: "lee doolan" <lee.doolan at volcanomail.com>
Date: Sat, 5 Jun 2010 23:54:22
To: <varnish-dev at varnish-cache.org>
Subject: [PATCH] Concatenate Set-Cookie headers before a call to vcl_fetch()


I have modified a 2.1.2el5 distribution slightly.

All of the set-cookie headers from a backend response are
concatenated, with separators between them, and then the resulting
string is written into a header named x-set-cookies.  This is done
just before a call to vcl_fetch().  After the call to vcl_fetch(), the
x-set-cookies header is removed.  The code is here, in github:

     http://github.com/leed25d/ljVarnishPatch

The code may be slightly rough around the edges as I have not done any
C coding for around 10 years, but the modification works well enough
to make our system admins pretty happy.

--lee

_______________________________________________
varnish-dev mailing list
varnish-dev at varnish-cache.org
http://lists.varnish-cache.org/mailman/listinfo/varnish-dev

 LocalWords:  LiveJournal vcl yadda regsub SePaRaT dev HTTP regsuball ie com
 LocalWords:  volcanomail org Artur BlackBerry doolan backend github admins



From phk at phk.freebsd.dk  Wed Jun  9 10:18:50 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 09 Jun 2010 10:18:50 +0000
Subject: [Varnish] #563: RE: Unable to mangle one of multiple Set-Cookie
	headers. 
In-Reply-To: Your message of "Tue, 08 Jun 2010 14:40:35 MST."
	<AANLkTikjgR4OBliPY6sgU6UTUl-9fMtw3xGPoHMizlRc@mail.gmail.com> 
Message-ID: <11152.1276078730@critter.freebsd.dk>

In message <AANLkTikjgR4OBliPY6sgU6UTUl-9fMtw3xGPoHMizlRc at mail.gmail.com>, Lee Doolan writes:

>Just before the vcl_fetch() routine is called, all of the headers are
>examined and the value fields of all of the Set-Cookie headers are
>concatenated together.  The value fields are separated by a known
>separator string, and copied into an header named 'X-Set-Cookies'.
>The X header can be referenced in the vcl_fetch() routine like this
>(for instance):

Without any malice intended, this is a somewhat hackish way to work
around the problem.

I have long had a plan to make cookies first-rate objects in VCL, using
a syntax something like:

	sub vcl_recv {
		if (req.cookie.CLIENT_STATE ~ "logged in") {
			do_something();
		}
	}

And the necessary changes are slowly bubbling up towards the top of my 
todo list, so hopefully it will make it into 3.0

-- 
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 tom at neovatar.org  Mon Jun 14 16:49:47 2010
From: tom at neovatar.org (tom at neovatar.org)
Date: Mon, 14 Jun 2010 18:49:47 +0200
Subject: No subject
Message-ID: <1276534187.14939.1380030607@webmail.messagingengine.com>

Hello,

I hope this is the right list to ask about varnish behaviour which might
be a bug.

We are getting the following (at the bottom of the mail) error on an ESI
include, but I have no idea if this can be triggered by wrong
configuration. The initial request goes to a local tomcat, the response
html has the following ESI include:

<esi:include
src="/external/newsticker/snippet/template/snippet_neue_rechte_leiste/limit/6">

The error does not happen everytime, but from time to time. I have not
found a way to reproduce it for sure.

I would be thankfull, if somebody could point me into a direction how to
solve this.

Cheers,
Tom

Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child cleanup complete
Jun 14 16:05:31 pol-web-15 varnishd[15974]: child (17887) Started
Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) said 
Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) said Child
starts
Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) died signal=6
Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) Panic message:
Missing errorhandling code in parse_esi_tag(), cache_esi.c line 634:  
Condition(q < ew->tag.e) not true.thread = (cache-worker) ident =
Linux,2.6.24-25-xen,x86_64,-smalloc,-hcritbit,epoll Backtrace:  
0x4235e7: /usr/sbin/varnishd [0x4235e7]   0x418955: /usr/sbin/varnishd
[0x418955]   0x41948d: /usr/sbin/varnishd(ESI_Parse+0x65d) [0x41948d]  
0x413d49: /usr/sbin/varnishd [0x413d49]   0x414ebb:
/usr/sbin/varnishd(CNT_Session+0x39b) [0x414ebb]   0x425a38:
/usr/sbin/varnishd [0x425a38]   0x424d3e: /usr/sbin/varnishd [0x424d3e] 
 0x7f31af5c83f7: /lib/libpthread.so.0 [0x7f31af5c83f7]   0x7f31aee9dbbd:
/lib/libc.so.6(clone+0x6d) [0x7f31aee9dbbd] sp = 0x7f31a8a80008 {   fd =
15, id = 15, xid = 959769645,   client = 129.67.114.26:50797,   step =
STP_FETCH,   handling = deliver,   err_code = 200, err_reason = (null), 
 restarts = 0, esis = 0   ws = 0x7f31a8a80078 {      id = "sess",    
{s,f,r,e} = {0x7f31a8a80c90,+1864,(nil),+512000},   },   http[req] = {  
  ws = 0x7f31a8a80078[sess]       "GET",       "/",       "HTTP/1.1",   
   "User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; de;
rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3",       "Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",      
"Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3",      
"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",       "Keep-Alive:
115",       "Connection: keep-alive",       "Cache-Control: max-age=0", 
     "host: www.sueddeutsche.de",   },   worker = 0x7bf6fe80 {     ws =
0x7bf6ffe8 {        id = "wrk",       {s,f,r,e} =
{0x7bef0e00,+9752,(nil),+512000},     },     http[bereq] = {       ws =
0x7bf6ffe8[wrk]         "GET",         "/",         "HTTP/1.1",        
"User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; de;
rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3",         "Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",       
 "Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3",        
"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",         "host:
www.sueddeutsche.de",         "X-Varnish: 959769645",     },    
http[beresp] = {       ws = 0x7bf6ffe8[wrk]         "HTTP/1.1",        
"200",         "OK",         "Server: Apache-Coyote/1.1",        
"Expires: Mon, 14 Jun 2010 16:06:31 GMT",         "Content-Type:
text/html;charset=utf-8",         "Transfer-Encoding: chunked",        
"Date: Mon, 14 Jun 2010 16:05:30 GMT",         "Cache-Control:
max-age=120",     },     },     vcl = {       srcname = {        
"input",         "Default",       },     },   obj = 0x7f31a8807300 {    
xid = 959769645,     ws = 0x7f31a8807320 {        id = "obj",      
{s,f,r,e} = {0x7f31a8807508,+240,+248,+248},     },     http[obj] = {   
   ws = 0x7f31a8807320[obj]         "HTTP/1.1",         "200",        
"OK",         "Server: Apache-Coyote/1.1",         "Expires: Mon, 14 Jun
2010 16:06:31 GMT",         "Content-Type: text/html;charset=utf-8",    
    "Date: Mon, 14 Jun 2010 16:05:30 GMT",         "Cache-Control:
max-age=120",         "Content-Length: 139787",     },     len = 139787,
    store = {       131072 {         3c 21 44 4f 43 54 59 50 45 20 68 74
6d 6c 3e 0a |<!DOCTYPE html>.|         3c 68 74 6d 6c 20 6c 61 6e 67 3d
22 64 65 22 3e |<html lang="de">|         0a 3c 21 2d 2d 20 5b 53 54 41
52 54 20 48 45 41 |.<!-- [START HEA|         44 45 52 5d 20 2d 2d 3e 0a
20 20 3c 68 65 61 64 |DER] -->.  <head|         [131008 more]       },  
    8715 {         69 70 70 65 74 2f 74 65 6d 70 6c 61 74 65 2f 73
|ippet/template/s|         6e 69 70 70 65 74 5f 6e 65 75 65 5f 72 65 63
68 |nippet_neue_rech|         74 65 5f 6c 65 69 73 74 65 2f 6c 69 6d 69
74 2f |te_leiste/limit/|         36 22 3e 0d 0a 0a 20 20 20 20 20 20 20
20 20 20 |6">...          |         [8651 more]       },     },   }, },



From tom at neovatar.org  Mon Jun 14 17:03:33 2010
From: tom at neovatar.org (tom at neovatar.org)
Date: Mon, 14 Jun 2010 19:03:33 +0200
Subject: Panic message: Missing errorhandling code in parse_esi_tag(),
	cache_esi.c line 634
In-Reply-To: <1276534187.14939.1380030607@webmail.messagingengine.com>
References: <1276534187.14939.1380030607@webmail.messagingengine.com>
Message-ID: <1276535013.18476.1380036391@webmail.messagingengine.com>

Hello,

sorry, I did send the first mail without a subject, because I have to
use the stupid webmail gui from work.

I hope this is the right list to ask about varnish behaviour which might
be a bug.

We are getting the following (at the bottom of the mail) error on an ESI
include, but I have no idea if this can be triggered by wrong
configuration. The initial request goes to a local tomcat, the response
html has the following ESI include:

<esi:include
src="/external/newsticker/snippet/template/snippet_neue_rechte_leiste/limit/6">

The error does not happen everytime, but from time to time. I have not
found a way to reproduce it for sure.

I would be thankfull, if somebody could point me into a direction how to
solve this.

Cheers,
Tom

Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child cleanup complete
Jun 14 16:05:31 pol-web-15 varnishd[15974]: child (17887) Started
Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) said 
Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) said Child
starts
Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) died signal=6
Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) Panic message:
Missing errorhandling code in parse_esi_tag(), cache_esi.c line 634:  
Condition(q < ew->tag.e) not true.thread = (cache-worker) ident =
Linux,2.6.24-25-xen,x86_64,-smalloc,-hcritbit,epoll Backtrace:  
0x4235e7: /usr/sbin/varnishd [0x4235e7]   0x418955: /usr/sbin/varnishd
[0x418955]   0x41948d: /usr/sbin/varnishd(ESI_Parse+0x65d) [0x41948d]  
0x413d49: /usr/sbin/varnishd [0x413d49]   0x414ebb:
/usr/sbin/varnishd(CNT_Session+0x39b) [0x414ebb]   0x425a38:
/usr/sbin/varnishd [0x425a38]   0x424d3e: /usr/sbin/varnishd [0x424d3e] 
 0x7f31af5c83f7: /lib/libpthread.so.0 [0x7f31af5c83f7]   0x7f31aee9dbbd:
/lib/libc.so.6(clone+0x6d) [0x7f31aee9dbbd] sp = 0x7f31a8a80008 {   fd =
15, id = 15, xid = 959769645,   client = 129.67.114.26:50797,   step =
STP_FETCH,   handling = deliver,   err_code = 200, err_reason = (null), 
 restarts = 0, esis = 0   ws = 0x7f31a8a80078 {      id = "sess",    
{s,f,r,e} = {0x7f31a8a80c90,+1864,(nil),+512000},   },   http[req] = {  
  ws = 0x7f31a8a80078[sess]       "GET",       "/",       "HTTP/1.1",   
   "User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; de;
rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3",       "Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",      
"Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3",      
"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",       "Keep-Alive:
115",       "Connection: keep-alive",       "Cache-Control: max-age=0", 
     "host: www.sueddeutsche.de",   },   worker = 0x7bf6fe80 {     ws =
0x7bf6ffe8 {        id = "wrk",       {s,f,r,e} =
{0x7bef0e00,+9752,(nil),+512000},     },     http[bereq] = {       ws =
0x7bf6ffe8[wrk]         "GET",         "/",         "HTTP/1.1",        
"User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; de;
rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3",         "Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",       
 "Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3",        
"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",         "host:
www.sueddeutsche.de",         "X-Varnish: 959769645",     },    
http[beresp] = {       ws = 0x7bf6ffe8[wrk]         "HTTP/1.1",        
"200",         "OK",         "Server: Apache-Coyote/1.1",        
"Expires: Mon, 14 Jun 2010 16:06:31 GMT",         "Content-Type:
text/html;charset=utf-8",         "Transfer-Encoding: chunked",        
"Date: Mon, 14 Jun 2010 16:05:30 GMT",         "Cache-Control:
max-age=120",     },     },     vcl = {       srcname = {        
"input",         "Default",       },     },   obj = 0x7f31a8807300 {    
xid = 959769645,     ws = 0x7f31a8807320 {        id = "obj",      
{s,f,r,e} = {0x7f31a8807508,+240,+248,+248},     },     http[obj] = {   
   ws = 0x7f31a8807320[obj]         "HTTP/1.1",         "200",        
"OK",         "Server: Apache-Coyote/1.1",         "Expires: Mon, 14 Jun
2010 16:06:31 GMT",         "Content-Type: text/html;charset=utf-8",    
    "Date: Mon, 14 Jun 2010 16:05:30 GMT",         "Cache-Control:
max-age=120",         "Content-Length: 139787",     },     len = 139787,
    store = {       131072 {         3c 21 44 4f 43 54 59 50 45 20 68 74
6d 6c 3e 0a |<!DOCTYPE html>.|         3c 68 74 6d 6c 20 6c 61 6e 67 3d
22 64 65 22 3e |<html lang="de">|         0a 3c 21 2d 2d 20 5b 53 54 41
52 54 20 48 45 41 |.<!-- [START HEA|         44 45 52 5d 20 2d 2d 3e 0a
20 20 3c 68 65 61 64 |DER] -->.  <head|         [131008 more]       },  
    8715 {         69 70 70 65 74 2f 74 65 6d 70 6c 61 74 65 2f 73
|ippet/template/s|         6e 69 70 70 65 74 5f 6e 65 75 65 5f 72 65 63
68 |nippet_neue_rech|         74 65 5f 6c 65 69 73 74 65 2f 6c 69 6d 69
74 2f |te_leiste/limit/|         36 22 3e 0d 0a 0a 20 20 20 20 20 20 20
20 20 20 |6">...          |         [8651 more]       },     },   }, },



From phk at phk.freebsd.dk  Mon Jun 14 19:36:46 2010
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 14 Jun 2010 19:36:46 +0000
Subject: No subject
In-Reply-To: Your message of "Mon, 14 Jun 2010 18:49:47 +0200."
	<1276534187.14939.1380030607@webmail.messagingengine.com> 
Message-ID: <17341.1276544206@critter.freebsd.dk>


Please open a ticket in the trac database at varnish-cache.org,
I will need a ticket number for the regression test.

Poul-Henning

In message <1276534187.14939.1380030607 at webmail.messagingengine.com>, tom at neova
tar.org writes:
>Hello,
>
>I hope this is the right list to ask about varnish behaviour which might
>be a bug.
>
>We are getting the following (at the bottom of the mail) error on an ESI
>include, but I have no idea if this can be triggered by wrong
>configuration. The initial request goes to a local tomcat, the response
>html has the following ESI include:
>
><esi:include
>src="/external/newsticker/snippet/template/snippet_neue_rechte_leiste/limit/6">
>
>The error does not happen everytime, but from time to time. I have not
>found a way to reproduce it for sure.
>
>I would be thankfull, if somebody could point me into a direction how to
>solve this.
>
>Cheers,
>Tom
>
>Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child cleanup complete
>Jun 14 16:05:31 pol-web-15 varnishd[15974]: child (17887) Started
>Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) said 
>Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) said Child
>starts
>Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) died signal=6
>Jun 14 16:05:31 pol-web-15 varnishd[15974]: Child (17887) Panic message:
>Missing errorhandling code in parse_esi_tag(), cache_esi.c line 634:  
>Condition(q < ew->tag.e) not true.thread = (cache-worker) ident =
>Linux,2.6.24-25-xen,x86_64,-smalloc,-hcritbit,epoll Backtrace:  
>0x4235e7: /usr/sbin/varnishd [0x4235e7]   0x418955: /usr/sbin/varnishd
>[0x418955]   0x41948d: /usr/sbin/varnishd(ESI_Parse+0x65d) [0x41948d]  
>0x413d49: /usr/sbin/varnishd [0x413d49]   0x414ebb:
>/usr/sbin/varnishd(CNT_Session+0x39b) [0x414ebb]   0x425a38:
>/usr/sbin/varnishd [0x425a38]   0x424d3e: /usr/sbin/varnishd [0x424d3e] 
> 0x7f31af5c83f7: /lib/libpthread.so.0 [0x7f31af5c83f7]   0x7f31aee9dbbd:
>/lib/libc.so.6(clone+0x6d) [0x7f31aee9dbbd] sp = 0x7f31a8a80008 {   fd =
>15, id = 15, xid = 959769645,   client = 129.67.114.26:50797,   step =
>STP_FETCH,   handling = deliver,   err_code = 200, err_reason = (null), 
> restarts = 0, esis = 0   ws = 0x7f31a8a80078 {      id = "sess",    
>{s,f,r,e} = {0x7f31a8a80c90,+1864,(nil),+512000},   },   http[req] = {  
>  ws = 0x7f31a8a80078[sess]       "GET",       "/",       "HTTP/1.1",   
>   "User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; de;
>rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3",       "Accept:
>text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",      
>"Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3",      
>"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",       "Keep-Alive:
>115",       "Connection: keep-alive",       "Cache-Control: max-age=0", 
>     "host: www.sueddeutsche.de",   },   worker = 0x7bf6fe80 {     ws =
>0x7bf6ffe8 {        id = "wrk",       {s,f,r,e} =
>{0x7bef0e00,+9752,(nil),+512000},     },     http[bereq] = {       ws =
>0x7bf6ffe8[wrk]         "GET",         "/",         "HTTP/1.1",        
>"User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; de;
>rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3",         "Accept:
>text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",       
> "Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3",        
>"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",         "host:
>www.sueddeutsche.de",         "X-Varnish: 959769645",     },    
>http[beresp] = {       ws = 0x7bf6ffe8[wrk]         "HTTP/1.1",        
>"200",         "OK",         "Server: Apache-Coyote/1.1",        
>"Expires: Mon, 14 Jun 2010 16:06:31 GMT",         "Content-Type:
>text/html;charset=utf-8",         "Transfer-Encoding: chunked",        
>"Date: Mon, 14 Jun 2010 16:05:30 GMT",         "Cache-Control:
>max-age=120",     },     },     vcl = {       srcname = {        
>"input",         "Default",       },     },   obj = 0x7f31a8807300 {    
>xid = 959769645,     ws = 0x7f31a8807320 {        id = "obj",      
>{s,f,r,e} = {0x7f31a8807508,+240,+248,+248},     },     http[obj] = {   
>   ws = 0x7f31a8807320[obj]         "HTTP/1.1",         "200",        
>"OK",         "Server: Apache-Coyote/1.1",         "Expires: Mon, 14 Jun
>2010 16:06:31 GMT",         "Content-Type: text/html;charset=utf-8",    
>    "Date: Mon, 14 Jun 2010 16:05:30 GMT",         "Cache-Control:
>max-age=120",         "Content-Length: 139787",     },     len = 139787,
>    store = {       131072 {         3c 21 44 4f 43 54 59 50 45 20 68 74
>6d 6c 3e 0a |<!DOCTYPE html>.|         3c 68 74 6d 6c 20 6c 61 6e 67 3d
>22 64 65 22 3e |<html lang="de">|         0a 3c 21 2d 2d 20 5b 53 54 41
>52 54 20 48 45 41 |.<!-- [START HEA|         44 45 52 5d 20 2d 2d 3e 0a
>20 20 3c 68 65 61 64 |DER] -->.  <head|         [131008 more]       },  
>    8715 {         69 70 70 65 74 2f 74 65 6d 70 6c 61 74 65 2f 73
>|ippet/template/s|         6e 69 70 70 65 74 5f 6e 65 75 65 5f 72 65 63
>68 |nippet_neue_rech|         74 65 5f 6c 65 69 73 74 65 2f 6c 69 6d 69
>74 2f |te_leiste/limit/|         36 22 3e 0d 0a 0a 20 20 20 20 20 20 20
>20 20 20 |6">...          |         [8651 more]       },     },   }, },
>
>_______________________________________________
>varnish-bugs mailing list
>varnish-bugs at varnish-cache.org
>http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs
>

-- 
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 bnowacky at competitorgroup.com  Thu Jun 24 15:06:43 2010
From: bnowacky at competitorgroup.com (Ben Nowacky)
Date: Thu, 24 Jun 2010 08:06:43 -0700
Subject: No subject
Message-ID: <093811CA-052E-411C-AB04-FE9D13A38822@competitorgroup.com>

Hoping someone can help... We're just trying to roll out varnish to a somewhat large production site (30million monthly pageviews). Things seem to be working, hitting about a 90% hitrate so far. Using Wordpress for a CMS and standard LAMP stack on the back-end.

- Deployed varnish on 1 of our servers yesterday for final testing on the live site. Runs along well, seems to be doing great. Run varnishstat to keep an eye on it, and randomly all the stats reset back to 0, and there's a full cache purge, which means i'm guessing varnish has restarted? 

I can't, for the life of me, figure out why it's been restarting. I've tweeked settings that I've seen recommendations for, upped cache/thread/etc an still seems to be happening.  Not sure if anyone else has seen this behavior or not, but if anyone has any suggestions for troubleshooting, or figuring out what's going on, would appreciate any help ! I've got varnish running with persistence now, so it's helping a bit when there's a restart since it's not completely unprimed, but need to figure out the cause of the instability.

Any help would be awesome... Thanks ! 


From kristian at varnish-software.com  Thu Jun 24 17:25:53 2010
From: kristian at varnish-software.com (=?UTF-8?Q?Kristian_Lyngst=C3=B8l?=)
Date: Thu, 24 Jun 2010 19:25:53 +0200
Subject: No subject
In-Reply-To: <093811CA-052E-411C-AB04-FE9D13A38822@competitorgroup.com>
References: <093811CA-052E-411C-AB04-FE9D13A38822@competitorgroup.com>
Message-ID: <AANLkTimPAl0Lx07vjL-EAN2EzyqI-6k6VHbmDdo0tyI7@mail.gmail.com>

You should post this to -misc. You probably want to check your syslog too.

- Kristian

2010/6/24, Ben Nowacky <bnowacky at competitorgroup.com>:
> Hoping someone can help... We're just trying to roll out varnish to a
> somewhat large production site (30million monthly pageviews). Things seem to
> be working, hitting about a 90% hitrate so far. Using Wordpress for a CMS
> and standard LAMP stack on the back-end.
>
> - Deployed varnish on 1 of our servers yesterday for final testing on the
> live site. Runs along well, seems to be doing great. Run varnishstat to keep
> an eye on it, and randomly all the stats reset back to 0, and there's a full
> cache purge, which means i'm guessing varnish has restarted?
>
> I can't, for the life of me, figure out why it's been restarting. I've
> tweeked settings that I've seen recommendations for, upped cache/thread/etc
> an still seems to be happening.  Not sure if anyone else has seen this
> behavior or not, but if anyone has any suggestions for troubleshooting, or
> figuring out what's going on, would appreciate any help ! I've got varnish
> running with persistence now, so it's helping a bit when there's a restart
> since it's not completely unprimed, but need to figure out the cause of the
> instability.
>
> Any help would be awesome... Thanks !
> _______________________________________________
> varnish-bugs mailing list
> varnish-bugs at varnish-cache.org
> http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs
>



From bnowacky at competitorgroup.com  Thu Jun 24 17:24:54 2010
From: bnowacky at competitorgroup.com (Ben Nowacky)
Date: Thu, 24 Jun 2010 10:24:54 -0700
Subject: No subject
In-Reply-To: <AANLkTimPAl0Lx07vjL-EAN2EzyqI-6k6VHbmDdo0tyI7@mail.gmail.com>
References: <093811CA-052E-411C-AB04-FE9D13A38822@competitorgroup.com>
	<AANLkTimPAl0Lx07vjL-EAN2EzyqI-6k6VHbmDdo0tyI7@mail.gmail.com>
Message-ID: <02683F29-F9CE-4055-A8E9-BCC64DBE0A76@competitorgroup.com>

Nothing in syslog... doesn't even get created..

sorry about the mispost.. I'll move this over to -misc

On Jun 24, 2010, at 10:25 AM, Kristian Lyngst?l wrote:

> You should post this to -misc. You probably want to check your syslog too.
> 
> - Kristian
> 
> 2010/6/24, Ben Nowacky <bnowacky at competitorgroup.com>:
>> Hoping someone can help... We're just trying to roll out varnish to a
>> somewhat large production site (30million monthly pageviews). Things seem to
>> be working, hitting about a 90% hitrate so far. Using Wordpress for a CMS
>> and standard LAMP stack on the back-end.
>> 
>> - Deployed varnish on 1 of our servers yesterday for final testing on the
>> live site. Runs along well, seems to be doing great. Run varnishstat to keep
>> an eye on it, and randomly all the stats reset back to 0, and there's a full
>> cache purge, which means i'm guessing varnish has restarted?
>> 
>> I can't, for the life of me, figure out why it's been restarting. I've
>> tweeked settings that I've seen recommendations for, upped cache/thread/etc
>> an still seems to be happening.  Not sure if anyone else has seen this
>> behavior or not, but if anyone has any suggestions for troubleshooting, or
>> figuring out what's going on, would appreciate any help ! I've got varnish
>> running with persistence now, so it's helping a bit when there's a restart
>> since it's not completely unprimed, but need to figure out the cause of the
>> instability.
>> 
>> Any help would be awesome... Thanks !
>> _______________________________________________
>> varnish-bugs mailing list
>> varnish-bugs at varnish-cache.org
>> http://lists.varnish-cache.org/mailman/listinfo/varnish-bugs
>> 




From varnish-bugs at varnish-cache.org  Tue Jun  1 08:50:15 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 01 Jun 2010 08:50:15 -0000
Subject: [Varnish] #710: check_varnish.c fails to compile against varnish 2.1.x
Message-ID: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org>

#710: check_varnish.c fails to compile against varnish 2.1.x
--------------------+-------------------------------------------------------
 Reporter:  netmax  |        Type:  defect
   Status:  new     |    Priority:  normal
Milestone:          |   Component:  nagios
  Version:  2.1.2   |    Severity:  normal
 Keywords:          |  
--------------------+-------------------------------------------------------
 i'm trying to build the check_varnish plugin against the 2.1.x branch, it
 fails with:

 make[1]: Entering directory `/usr/src/packages/BUILD/nagios-varnish-
 plugin-1.0'
 gcc -DHAVE_CONFIG_H -I.    -include config.h -I/usr/include/varnish   -g
 -O2 -MT check_varnish-check_varnish.o -MD -MP -MF .deps/check_varnish-
 check_varnish.Tpo -c -o check_varnish-check_varnish.o `test -f
 'check_varnish.c' || echo './'`check_varnish.c
 In file included from check_varnish.c:112:
 /usr/include/varnish/stat_field.h:35:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:36:75: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 In file included from check_varnish.c:112:
 /usr/include/varnish/stat_field.h: In function 'check_stats':
 /usr/include/varnish/stat_field.h:35: error: 'MAC_STAT' undeclared (first
 use in this function)
 /usr/include/varnish/stat_field.h:35: error: (Each undeclared identifier
 is reported only once
 /usr/include/varnish/stat_field.h:35: error: for each function it appears
 in.)
 /usr/include/varnish/stat_field.h:36: error: expected ';' before
 'MAC_STAT'
 /usr/include/varnish/stat_field.h:37:67: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:39:52: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:40:65: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:41:55: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:43:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:44:76: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:45:67: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:46:67: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:47:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:48:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:49:69: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:50:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:52:53: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:53:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:54:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:55:51: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:56:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:57:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:58:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:59:57: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:60:57: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:63:60: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:64:52: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:65:56: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:66:70: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:67:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:68:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:69:51: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:70:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:71:60: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:72:60: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:73:55: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:74:69: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:76:36: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:77:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:78:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:79:72: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:80:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:81:52: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:83:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:84:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:85:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:86:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:87:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:89:61: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:91:72: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:92:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:94:37: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:96:53: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:97:53: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:98:49: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:99:49: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:100:51: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:101:61: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:102:60: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:104:58: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:105:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:106:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:107:58: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:108:54: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:110:55: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:111:53: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:112:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:113:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:114:68: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:116:58: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:117:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:118:57: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:119:51: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:121:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:122:68: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:123:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:124:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:125:56: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:127:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:128:68: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:129:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:130:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:131:57: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:133:65: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:135:50: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:136:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:137:61: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:139:61: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:140:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:141:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:142:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:143:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:144:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:146:67: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:147:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:148:54: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:150:69: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:151:68: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:152:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:153:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:154:52: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 make[1]: *** [check_varnish-check_varnish.o] Error 1
 make[1]: Leaving directory `/usr/src/packages/BUILD/nagios-varnish-
 plugin-1.0'
 make: *** [all] Error 2

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



From varnish-bugs at varnish-cache.org  Tue Jun  1 08:50:53 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 01 Jun 2010 08:50:53 -0000
Subject: [Varnish] #710: check_varnish.c fails to compile against
	varnish 2.1.x
In-Reply-To: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org>
References: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org>
Message-ID: <052.61157e0a0ae5bbb2471a873185b6cdd6@varnish-cache.org>

#710: check_varnish.c fails to compile against varnish 2.1.x
--------------------+-------------------------------------------------------
 Reporter:  netmax  |        Type:  defect
   Status:  new     |    Priority:  normal
Milestone:          |   Component:  nagios
  Version:  2.1.2   |    Severity:  normal
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by netmax):

 {{{
 make[1]: Entering directory `/usr/src/packages/BUILD/nagios-varnish-
 plugin-1.0'
 gcc -DHAVE_CONFIG_H -I.    -include config.h -I/usr/include/varnish   -g
 -O2 -MT check_varnish-check_varnish.o -MD -MP -MF .deps/check_varnish-
 check_varnish.Tpo -c -o check_varnish-check_varnish.o `test -f
 'check_varnish.c' || echo './'`check_varnish.c
 In file included from check_varnish.c:112:
 /usr/include/varnish/stat_field.h:35:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:36:75: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 In file included from check_varnish.c:112:
 /usr/include/varnish/stat_field.h: In function 'check_stats':
 /usr/include/varnish/stat_field.h:35: error: 'MAC_STAT' undeclared (first
 use in this function)
 /usr/include/varnish/stat_field.h:35: error: (Each undeclared identifier
 is reported only once
 /usr/include/varnish/stat_field.h:35: error: for each function it appears
 in.)
 /usr/include/varnish/stat_field.h:36: error: expected ';' before
 'MAC_STAT'
 /usr/include/varnish/stat_field.h:37:67: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:39:52: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:40:65: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:41:55: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:43:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:44:76: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:45:67: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:46:67: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:47:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:48:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:49:69: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:50:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:52:53: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:53:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:54:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:55:51: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:56:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:57:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:58:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:59:57: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:60:57: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:63:60: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:64:52: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:65:56: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:66:70: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:67:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:68:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:69:51: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:70:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:71:60: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:72:60: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:73:55: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:74:69: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:76:36: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:77:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:78:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:79:72: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:80:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:81:52: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:83:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:84:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:85:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:86:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:87:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:89:61: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:91:72: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:92:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:94:37: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:96:53: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:97:53: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:98:49: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:99:49: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:100:51: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:101:61: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:102:60: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:104:58: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:105:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:106:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:107:58: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:108:54: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:110:55: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:111:53: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:112:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:113:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:114:68: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:116:58: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:117:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:118:57: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:119:51: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:121:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:122:68: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:123:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:124:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:125:56: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:127:63: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:128:68: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:129:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:130:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:131:57: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:133:65: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:135:50: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:136:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:137:61: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:139:61: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:140:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:141:66: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:142:64: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:143:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:144:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:146:67: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:147:62: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:148:54: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:150:69: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:151:68: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:152:59: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:153:71: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 /usr/include/varnish/stat_field.h:154:52: error: macro "MAC_STAT" passed 5
 arguments, but takes just 4
 make[1]: *** [check_varnish-check_varnish.o] Error 1
 make[1]: Leaving directory `/usr/src/packages/BUILD/nagios-varnish-
 plugin-1.0'
 make: *** [all] Error 2

 }}}

-- 
Ticket URL: <http://varnish-cache.org/ticket/710#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun  1 18:14:10 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 01 Jun 2010 18:14:10 -0000
Subject: [Varnish] #633: varnishncsa segfaults
In-Reply-To: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org>
References: <044.6c983ae1f43ec0d72b3394393846b593@varnish-cache.org>
Message-ID: <053.be052967ab9b7eeecc694c40486afc13@varnish-cache.org>

#633: varnishncsa segfaults
---------------------+------------------------------------------------------
 Reporter:  victori  |       Owner:  kristian
     Type:  defect   |      Status:  assigned
 Priority:  normal   |   Milestone:          
Component:  build    |     Version:  trunk   
 Severity:  normal   |    Keywords:          
---------------------+------------------------------------------------------

Comment(by jdzst):

 I have attached a fix for varnishncsa.c bugs caused by duplicated ReqEnd.

-- 
Ticket URL: <http://varnish-cache.org/ticket/633#comment:5>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun  1 18:14:14 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 01 Jun 2010 18:14:14 -0000
Subject: [Varnish] #685: Logging non-HTTP connections as null
In-Reply-To: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org>
References: <047.625490b71f1b8047ef7bf83343e6eff2@varnish-cache.org>
Message-ID: <056.afe7de76f3bc566b2281cb91c06e103c@varnish-cache.org>

#685: Logging non-HTTP connections as null
-------------------------+--------------------------------------------------
 Reporter:  joshdevins   |       Owner:  kristian
     Type:  defect       |      Status:  assigned
 Priority:  normal       |   Milestone:          
Component:  varnishncsa  |     Version:  trunk   
 Severity:  major        |    Keywords:          
-------------------------+--------------------------------------------------

Comment(by jdzst):

 I have attached a fix for varnishncsa.c bugs caused by duplicated ReqEnd.

-- 
Ticket URL: <http://varnish-cache.org/ticket/685#comment:7>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Jun  3 09:30:39 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 03 Jun 2010 09:30:39 -0000
Subject: [Varnish] #711: 64bit Catch 22 on Solaris (gcc _builtin_xxx functions)
Message-ID: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>

#711: 64bit Catch 22 on Solaris (gcc _builtin_xxx functions)
------------------------------------------------------------------+---------
 Reporter:  tinl                                                  |        Type:  defect
   Status:  new                                                   |    Priority:  normal
Milestone:  After Varnish 2.1                                     |   Component:  build 
  Version:  trunk                                                 |    Severity:  major 
 Keywords:  __builtin_isfinite, link error, 64-bit, solaris, gcc  |  
------------------------------------------------------------------+---------
 Same issue as #577 for 2.1.2:

 Version 2.1.2 suffers in my case exactly from the same symptom:
 ---------------------------------------------------------------
 $ type gcc
 gcc is /usr/sfw/bin/gcc
 $ gcc -v
 Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
 Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
 --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-
 ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-
 shared
 Thread model: posix
 gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
 $ uname -a
 SunOS solo1 5.10 Generic_118855-33 i86pc i386 i86pc
 ---------------------------------------------------------------
 Configure cmd line:
 CFLAGS="-O3 -pthreads -m64 -fomit-frame-pointer -L/usr/sfw/lib/amd64"
 LDFLAGS="-R /usr/sfw/lib/amd64 -lumem -pthreads"
 PKG_CONFIG_PATH=/opt/local/pcre-8.02/lib/pkgconfig VCC_CC="gcc -fPIC -G -o
 %o %s" CC=/usr/sfw/bin/gcc ./configure --prefix=/opt/local/varnish-2.1.2

 and finally the link error:
 Undefined                       first referenced
  symbol                             in file
 !__builtin_isfinite
 ../../lib/libvarnish/.libs/libvarnish.so
 ld: fatal: Symbol referencing errors. No output written to
 .libs/varnishadm
 collect2: ld returned 1 exit status
 make: Fatal error: Command failed for target `varnishadm'

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



From varnish-bugs at varnish-cache.org  Thu Jun  3 13:16:46 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 03 Jun 2010 13:16:46 -0000
Subject: [Varnish] #712: Custom varnishncsa log format
Message-ID: <042.68735fbe2f2d3636ae319db40a720359@varnish-cache.org>

#712: Custom varnishncsa log format
-------------------+--------------------------------------------------------
 Reporter:  quipo  |        Type:  enhancement
   Status:  new    |    Priority:  normal     
Milestone:         |   Component:  varnishncsa
  Version:  trunk  |    Severity:  normal     
 Keywords:         |  
-------------------+--------------------------------------------------------
 Until varnishncsa gets full LogFormat support, it would be nice to be able
 to customise the output format at least with the available fields.

 Two patches have been posted to the mailing list already:

 http://www.mail-archive.com/varnish-dev at projects.linpro.no/msg00591.html
 http://www.mail-archive.com/varnish-dev at projects.linpro.no/msg00507.html

 I cleaned them up a bit and added support for %U and %q separately (as
 opposed to retrieving %U%q as an atomic unit).


 Patch created against http://varnish-cache.org/svn/tags/varnish-2.1.2

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



From varnish-bugs at varnish-cache.org  Thu Jun  3 17:17:38 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 03 Jun 2010 17:17:38 -0000
Subject: [Varnish] #713: IP Forwarding with Varnish
Message-ID: <049.b97e93e08826929e2a0702a653f465f2@varnish-cache.org>

#713: IP Forwarding with Varnish
--------------------------+-------------------------------------------------
 Reporter:  brentnesbitt  |        Type:  documentation
   Status:  new           |    Priority:  normal       
Milestone:                |   Component:  documentation
  Version:  trunk         |    Severity:  normal       
 Keywords:                |  
--------------------------+-------------------------------------------------
 Hi,
 I have 3 Apache2 backend servers that are load balanced by ldirectord.
 Each apache server has a real IP address, plus several "virtual" IP
 addresses.  These virtual addresses actually belong to the load-balancer,
 and are IP Forwarded to the apache servers.  Apache listens on the virtual
 IP addresses (as well as on the real IP address, but that's just a default
 page to let the load-balancer know its alive).  There are multiple
 NameVirtualHosts on each IP address.

 I am wanting to insert '''varnish''' into the mix, but run into a problem
 when varnish sends the request to the REAL IP address of the apache
 server, and apache can't listen on *:80, since it specifically listens on
 the defined IPs.

 Also, I can't use the "virtual" IP addresses of the various domains, since
 those addresses ACTUALLY belong to the load balancer, and would create a
 loop (the load balancer currently forwards to varnish, which should in
 turn forward to the apache server)

 I see no documentation on this configuration, yet imagine it must be a
 problem for many people.  How would you recommend I address this
 situation?

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



From varnish-bugs at varnish-cache.org  Fri Jun  4 08:42:59 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 04 Jun 2010 08:42:59 -0000
Subject: [Varnish] #713: IP Forwarding with Varnish
In-Reply-To: <049.b97e93e08826929e2a0702a653f465f2@varnish-cache.org>
References: <049.b97e93e08826929e2a0702a653f465f2@varnish-cache.org>
Message-ID: <058.c4b3589f16ddf70fd4d9e352a9329d54@varnish-cache.org>

#713: IP Forwarding with Varnish
---------------------------+------------------------------------------------
  Reporter:  brentnesbitt  |        Type:  documentation
    Status:  closed        |    Priority:  normal       
 Milestone:                |   Component:  documentation
   Version:  trunk         |    Severity:  normal       
Resolution:  worksforme    |    Keywords:               
---------------------------+------------------------------------------------
Changes (by phk):

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


Comment:

 The easiest way is probably to eliminate the loadbalancer and let varnish
 do that job also.

-- 
Ticket URL: <http://varnish-cache.org/ticket/713#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Jun  4 08:45:32 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 04 Jun 2010 08:45:32 -0000
Subject: [Varnish] #711: 64bit Catch 22 on Solaris (gcc _builtin_xxx
	functions)
In-Reply-To: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>
References: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>
Message-ID: <050.fc9986dae19ed6b5ed75065dba66e463@varnish-cache.org>

#711: 64bit Catch 22 on Solaris (gcc _builtin_xxx functions)
--------------------------------+-------------------------------------------
  Reporter:  tinl               |        Type:  defect                                              
    Status:  closed             |    Priority:  normal                                              
 Milestone:  After Varnish 2.1  |   Component:  build                                               
   Version:  trunk              |    Severity:  major                                               
Resolution:  worksforme         |    Keywords:  __builtin_isfinite, link error, 64-bit, solaris, gcc
--------------------------------+-------------------------------------------
Changes (by phk):

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


Comment:

 I think you are mixing #include files from one compiler to the other, that
 generally does not work.

 Either you use GCC all the way or you use the Sun compiler all the way.

-- 
Ticket URL: <http://varnish-cache.org/ticket/711#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Sun Jun  6 16:21:31 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Sun, 06 Jun 2010 16:21:31 -0000
Subject: [Varnish] #703: varnish segfaults on arm
In-Reply-To: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org>
References: <042.3788d6c155beff2240f1d02fb5dea844@varnish-cache.org>
Message-ID: <051.4760278929dbedb2968e7741e0bf7182@varnish-cache.org>

#703: varnish segfaults on arm
--------------------+-------------------------------------------------------
 Reporter:  perbu   |        Owner:                     
     Type:  defect  |       Status:  closed             
 Priority:  normal  |    Milestone:  Varnish 2.1 release
Component:  build   |      Version:  trunk              
 Severity:  normal  |   Resolution:  worksforme         
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by kristian):

 Figured I'd follow-up:

 This was not arm, but the fs. Simply storing the shmlog on a tmpfs allowed
 varnish to start.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/703#comment:5>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Sun Jun  6 22:31:12 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Sun, 06 Jun 2010 22:31:12 -0000
Subject: [Varnish] #714: VRT_l_* calls cause memory exhaustion under high load
Message-ID: <044.a9de153ab7995312e07d85a04d71434e@varnish-cache.org>

#714: VRT_l_* calls cause memory exhaustion under high load
---------------------+------------------------------------------------------
 Reporter:  ferivar  |        Type:  defect
   Status:  new      |    Priority:  normal
Milestone:           |   Component:  build 
  Version:  2.1.2    |    Severity:  normal
 Keywords:           |  
---------------------+------------------------------------------------------
 Writing to the req.url variable from inside a C block, e.g. using

 VRT_l_req_url(sp, "/new/url", vrt_magic_string_end);

 fills up the entire virtual memory.

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



From varnish-bugs at varnish-cache.org  Mon Jun  7 09:11:57 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 07 Jun 2010 09:11:57 -0000
Subject: [Varnish] #711: 64bit Catch 22 on Solaris (gcc _builtin_xxx
	functions)
In-Reply-To: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>
References: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>
Message-ID: <050.05bec3cce6eaaaba66c266775878524c@varnish-cache.org>

#711: 64bit Catch 22 on Solaris (gcc _builtin_xxx functions)
--------------------------------+-------------------------------------------
  Reporter:  tinl               |        Type:  defect                                              
    Status:  closed             |    Priority:  normal                                              
 Milestone:  After Varnish 2.1  |   Component:  build                                               
   Version:  trunk              |    Severity:  major                                               
Resolution:  worksforme         |    Keywords:  __builtin_isfinite, link error, 64-bit, solaris, gcc
--------------------------------+-------------------------------------------

Comment(by tinl):

 As visible from the configure command I'm trying to compile with gcc. No
 Sun compiler anywhere.

-- 
Ticket URL: <http://varnish-cache.org/ticket/711#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun  7 12:37:59 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 07 Jun 2010 12:37:59 -0000
Subject: [Varnish] #715: CLI communication error (hdr) on vcl.discard
Message-ID: <044.1375c3ee53ef8b1f435bb3ec5c0d8820@varnish-cache.org>

#715: CLI communication error (hdr) on vcl.discard
---------------------+------------------------------------------------------
 Reporter:  Estartu  |        Type:  defect
   Status:  new      |    Priority:  normal
Milestone:           |   Component:  build 
  Version:  2.1.2    |    Severity:  normal
 Keywords:           |  
---------------------+------------------------------------------------------
 When i try to delete old configs via vcl.discard I get an "CLI
 communication
 error (hdr)"

 here is an example cli session

  telnet localhost 6082
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is '^]'.
 200 154
 -----------------------------
 Varnish HTTP accelerator CLI.
 -----------------------------
 Type 'help' for command list.
 Type 'quit' to close CLI session.

 vcl.list
 200 228
 available       0 boot
 available       0 dynconf_20100607101631
 available       0 dynconf_20100607101856
 available       0 dynconf_20100607103126
 available       2 dynconf_20100607103142
 active          1 dynconf_20100607103209

 vcl.discard dynconf_20100607101631
 400 29
 CLI communication error (hdr)

 I'm using varnish 2.1.2 on FreeBSD

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



From varnish-bugs at varnish-cache.org  Tue Jun  8 11:48:43 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 08 Jun 2010 11:48:43 -0000
Subject: [Varnish] #710: check_varnish.c fails to compile against
	varnish 2.1.x
In-Reply-To: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org>
References: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org>
Message-ID: <052.4d01cafd3021442c8dcd8d0b03d9b822@varnish-cache.org>

#710: check_varnish.c fails to compile against varnish 2.1.x
--------------------+-------------------------------------------------------
 Reporter:  netmax  |        Type:  defect
   Status:  new     |    Priority:  normal
Milestone:          |   Component:  nagios
  Version:  2.1.2   |    Severity:  normal
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by sascha):

 I'm not certain, but I believe the errors above stem from trying to build
 the nagios plugin from trunk against installed libs from a 2.0.x version;
 at least the same just happened to me. However, the plugin still doesn't
 build against a fresh 2.1.2 install:


 {{{
 ~/varnish-svn-trunk/varnish-tools/nagios# make
 make  all-am
 make[1]: Entering directory `/root/varnish-svn-trunk/varnish-tools/nagios'
 gcc -DHAVE_CONFIG_H -I.    -include config.h -I/usr/include/varnish   -g
 -O2 -MT check_varnish-check_varnish.o -MD -MP -MF .deps/check_varnish-
 check_varnish.Tpo -c -o check_varnish-check_varnish.o `test -f
 'check_varnish.c' || echo './'`check_varnish.c
 check_varnish.c: In function 'check_stats':
 check_varnish.c:176: error: 'struct varnish_stats' has no member named
 'start_time'
 make[1]: *** [check_varnish-check_varnish.o] Error 1
 make[1]: Leaving directory `/root/varnish-svn-trunk/varnish-tools/nagios'
 make: *** [all] Error 2

 }}}


 if I change the line that raises the error to


 {{{
 -       up = tv.tv_sec - VSL_stats->start_time;
 +       up = VSL_stats->uptime;

 }}}

 the error is gone, but a new one pops up:


 {{{
 ~/varnish-svn-trunk/varnish-tools/nagios# make
 make  all-am
 make[1]: Entering directory `/root/varnish-svn-trunk/varnish-tools/nagios'
 gcc -DHAVE_CONFIG_H -I.    -include config.h -I/usr/include/varnish   -g
 -O2 -MT check_varnish-check_varnish.o -MD -MP -MF .deps/check_varnish-
 check_varnish.Tpo -c -o check_varnish-check_varnish.o `test -f
 'check_varnish.c' || echo './'`check_varnish.c
 mv -f .deps/check_varnish-check_varnish.Tpo .deps/check_varnish-
 check_varnish.Po
 /bin/sh ./libtool --tag=CC   --mode=link gcc -include config.h
 -I/usr/include/varnish   -g -O2   -o check_varnish check_varnish-
 check_varnish.o -lvarnishapi
 gcc -include config.h -I/usr/include/varnish -g -O2 -o check_varnish
 check_varnish-check_varnish.o  /usr/lib/libvarnishapi.so
 /usr/lib/libvarnishapi.so: undefined reference to `VRE_compile'
 /usr/lib/libvarnishapi.so: undefined reference to `VRE_exec'
 collect2: ld returned 1 exit status
 make[1]: *** [check_varnish] Error 1
 make[1]: Leaving directory `/root/varnish-svn-trunk/varnish-tools/nagios'
 make: *** [all] Error 2

 }}}

 Now I'm stuck. I'm using the debian packages from "squeeze", and rebuilded
 it for lenny. At the end of the build, the following warnings showed up:


 {{{
 dpkg-shlibdeps: warning: dependency on libnsl.so.1 could be avoided if
 "debian/varnish/usr/sbin/varnishd debian/varnish/usr/bin/varnishreplay
 debian/varnish/usr/bin/varnishadm" were not uselessly linked against it
 (they use none of its symbols).
 dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if
 "debian/varnish/usr/bin/varnishstat" were not uselessly linked against it
 (they use none of its symbols).
 dpkg-shlibdeps: warning: symbol VRE_free used by
 debian/libvarnish1/usr/lib/libvcl.so.1.0.0 found in none of the libraries.
 dpkg-shlibdeps: warning: symbol vsb_overflowed used by
 debian/libvarnish1/usr/lib/libvcl.so.1.0.0 found in none of the libraries.
 dpkg-shlibdeps: warning: symbol vsb_bcat used by
 debian/libvarnish1/usr/lib/libvcl.so.1.0.0 found in none of the libraries.
 dpkg-shlibdeps: warning: symbol vsb_printf used by
 debian/libvarnish1/usr/lib/libvcl.so.1.0.0 found in none of the libraries.
 dpkg-shlibdeps: warning: symbol vsb_delete used by
 debian/libvarnish1/usr/lib/libvcl.so.1.0.0 found in none of the libraries.
 dpkg-shlibdeps: warning: symbol VRE_compile used by
 debian/libvarnish1/usr/lib/libvcl.so.1.0.0 found in none of the libraries.
 dpkg-shlibdeps: warning: symbol vsb_vprintf used by
 debian/libvarnish1/usr/lib/libvcl.so.1.0.0 found in none of the libraries.
 dpkg-shlibdeps: warning: symbol vsb_new used by
 debian/libvarnish1/usr/lib/libvcl.so.1.0.0 found in none of the libraries.
 dpkg-shlibdeps: warning: symbol lbv_assert used by
 debian/libvarnish1/usr/lib/libvcl.so.1.0.0 found in none of the libraries.
 dpkg-shlibdeps: warning: symbol vsb_cat used by
 debian/libvarnish1/usr/lib/libvcl.so.1.0.0 found in none of the libraries.
 dpkg-shlibdeps: warning: 3 other similar warnings have been skipped (use
 -v to see them all).
 dpkg-shlibdeps: warning: symbol VRE_exec used by
 debian/libvarnish1/usr/lib/libvarnishapi.so.1.0.0 found in none of the
 libraries.
 dpkg-shlibdeps: warning: symbol VRE_compile used by
 debian/libvarnish1/usr/lib/libvarnishapi.so.1.0.0 found in none of the
 libraries.
 dpkg-shlibdeps: warning: symbol strlcpy used by
 debian/libvarnish1/usr/lib/libvarnish.so.1.0.0 found in none of the
 libraries.
 dpkg-shlibdeps: warning: dependency on libnsl.so.1 could be avoided if
 "debian/libvarnish1/usr/lib/libvarnish.so.1.0.0" were not uselessly linked
 against it (they use none of its symbols).

 }}}

 no idea if this is a flaw in the debian source package, or the varnish
 source tree itself; as far as it seems is the varnishd resulting from the
 build running just fine.

 BTW, please allow me to hijack the issue with a hint for a little
 enhancement to make the plugin output more human readable:


 {{{
 ~/varnish-svn-trunk/varnish-tools/nagios# svn diff
 Index: check_varnish.c
 ===================================================================
 --- check_varnish.c     (revision 4936)
 +++ check_varnish.c     (working copy)
 @@ -31,6 +31,7 @@
   */

  #include <inttypes.h>
 +#include <locale.h>
  #include <limits.h>
  #include <stdint.h>
  #include <stdio.h>
 @@ -200,7 +201,8 @@
                 printf("Unknown parameter '%s'\n", param);

         status = check_thresholds(value);
 -       printf("VARNISH %s: %s|%s=%jd\n", status_text[status], info,
 param, value);
 +       setlocale(LC_ALL, "");
 +       printf("VARNISH %s: %s (%'jd)|%s=%jd\n", status_text[status],
 info, value, param, value);
         exit(status);
  }

 }}}


 Would be lovely if someone has a hint about how to build the nagios plugin
 for the current varnish version.

 Cheers

 Sascha

-- 
Ticket URL: <http://varnish-cache.org/ticket/710#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Jun  9 15:40:41 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 09 Jun 2010 15:40:41 -0000
Subject: [Varnish] #716: varnishstat assert error in do_curses()
Message-ID: <043.8090dcf2a654a331314f64ddb40c163f@varnish-cache.org>

#716: varnishstat assert error in do_curses()
-------------------------+--------------------------------------------------
 Reporter:  mkania       |       Owner:  phk  
     Type:  defect       |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishstat  |     Version:  2.1.2
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------
 Whenever I try to run varnishstat and assert error is thrown saying:

 {{{
 Assert error in do_curses(), varnishstat_curses.c line 176:
 Condition((curs_set(0)) != ERR) not true.
 Aborted
 }}}

 If I run varnishstat -1 it outputs the statistics fine.


 {{{
 varnishstat -1
 client_conn             20411         0.28 Client connections accepted
 client_drop                 0         0.00 Connection dropped, no sess/wrk
 client_req              20411         0.28 Client requests received
 cache_hit                5048         0.07 Cache hits
 cache_hitpass               0         0.00 Cache hits for pass
 cache_miss              13468         0.18 Cache misses
 backend_conn             3715         0.05 Backend conn. success
 backend_unhealthy            0         0.00 Backend conn. not attempted
 backend_busy                0         0.00 Backend conn. too many
 backend_fail              133         0.00 Backend conn. failures
 backend_reuse           11515         0.16 Backend conn. reuses
 backend_toolate          1844         0.03 Backend conn. was closed
 backend_recycle         13360         0.18 Backend conn. recycles
 backend_unused              0         0.00 Backend conn. unused
 fetch_head                  0         0.00 Fetch head
 fetch_length            13361         0.18 Fetch with Length
 fetch_chunked               0         0.00 Fetch chunked
 fetch_eof                   0         0.00 Fetch EOF
 fetch_bad                   0         0.00 Fetch had bad headers
 fetch_close                 0         0.00 Fetch wanted close
 fetch_oldhttp               0         0.00 Fetch pre HTTP/1.1 closed
 fetch_zero                  0         0.00 Fetch zero len
 fetch_failed                0         0.00 Fetch failed
 n_sess_mem                 16          .   N struct sess_mem
 n_sess                      0          .   N struct sess
 n_object                  514          .   N struct object
 n_vampireobject             0          .   N unresurrected objects
 n_objectcore              516          .   N struct objectcore
 n_objecthead              189          .   N struct objecthead
 n_smf                    1029          .   N struct smf
 n_smf_frag                  0          .   N small free smf
 n_smf_large                 1          .   N large free smf
 n_vbe_conn                  1          .   N struct vbe_conn
 n_wrk                       2          .   N worker threads
 n_wrk_create               17         0.00 N worker threads created
 n_wrk_failed                0         0.00 N worker threads not created
 n_wrk_max                   0         0.00 N worker threads limited
 n_wrk_queue                 0         0.00 N queued work requests
 n_wrk_overflow            299         0.00 N overflowed work requests
 n_wrk_drop                  0         0.00 N dropped work requests
 n_backend                  20          .   N backends
 n_expired               12847          .   N expired objects
 n_lru_nuked                 0          .   N LRU nuked objects
 n_lru_saved                 0          .   N LRU saved objects
 n_lru_moved              2678          .   N LRU moved objects
 n_deathrow                  0          .   N objects on deathrow
 losthdr                     0         0.00 HTTP header overflows
 n_objsendfile               0         0.00 Objects sent with sendfile
 n_objwrite                505         0.01 Objects sent with write
 n_objoverflow               0         0.00 Objects overflowing workspace
 s_sess                  20411         0.28 Total Sessions
 s_req                   20411         0.28 Total Requests
 s_pipe                   1871         0.03 Total pipe
 s_pass                     24         0.00 Total pass
 s_fetch                 13361         0.18 Total fetch
 s_hdrbytes            7527067       103.22 Total header bytes
 s_bodybytes        1383973018     18979.33 Total body bytes
 sess_closed             20408         0.28 Session Closed
 sess_pipeline               0         0.00 Session Pipeline
 sess_readahead              2         0.00 Session Read Ahead
 sess_linger                12         0.00 Session Linger
 sess_herd                   3         0.00 Session herd
 shm_records           1121851        15.38 SHM records
 shm_writes             113574         1.56 SHM writes
 shm_flushes                 0         0.00 SHM flushes due to overflow
 shm_cont                    5         0.00 SHM MTX contention
 shm_cycles                  0         0.00 SHM cycles through buffer
 sm_nreq                 26722         0.37 allocator requests
 sm_nobj                  1028          .   outstanding allocations
 sm_balloc           703770624          .   bytes allocated
 sm_bfree         267731685376          .   bytes free
 sms_nreq                  131         0.00 SMS allocator requests
 sms_nobj                    0          .   SMS outstanding allocations
 sms_nbytes                  0          .   SMS outstanding bytes
 sms_balloc              63928          .   SMS bytes allocated
 sms_bfree               63928          .   SMS bytes freed
 backend_req             13362         0.18 Backend requests made
 n_vcl                      31         0.00 N vcl total
 n_vcl_avail                31         0.00 N vcl available
 n_vcl_discard               0         0.00 N vcl discarded
 n_purge                     1          .   N total active purges
 n_purge_add                 1         0.00 N new purges added
 n_purge_retire              0         0.00 N old purges deleted
 n_purge_obj_test            0         0.00 N objects tested
 n_purge_re_test             0         0.00 N regexps tested against
 n_purge_dups                0         0.00 N duplicate purges removed
 hcb_nolock              18516         0.25 HCB Lookups without lock
 hcb_lock                 3911         0.05 HCB Lookups with lock
 hcb_insert               3910         0.05 HCB Inserts
 esi_parse                   0         0.00 Objects ESI parsed (unlock)
 esi_errors                  0         0.00 ESI parse errors (unlock)
 accept_fail                 0         0.00 Accept failures
 client_drop_late            0         0.00 Connection dropped late
 uptime                  72920         1.00 Client uptime
 critbit_cooler              0          .   Objhdr's on cool list

 }}}

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



From varnish-bugs at varnish-cache.org  Thu Jun 10 10:51:51 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 10 Jun 2010 10:51:51 -0000
Subject: [Varnish] #717: obj.hash and beresp.hash do not work inside
	vcl_deliver
Message-ID: <045.35ab9c6f4e4ddedcbb91cc6911a9f3a5@varnish-cache.org>

#717: obj.hash and beresp.hash do not work inside vcl_deliver
----------------------+-----------------------------------------------------
 Reporter:  grosser2  |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.2
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 Message from VCC-compiler:
 Unknown variable 'beresp.hash'
 At: (input Line 49 Pos 26)
   set resp.http.X-Hash = beresp.hash;
 -------------------------###########-
 Running VCC-compiler failed, exit 1
 VCL compilation failed

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



From varnish-bugs at varnish-cache.org  Thu Jun 10 14:13:33 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 10 Jun 2010 14:13:33 -0000
Subject: [Varnish] #718: obj.hits or beresp.hits not available in vcl_deliver
Message-ID: <045.5748da70e8b1ff16bbfb8a7df7047260@varnish-cache.org>

#718: obj.hits or beresp.hits not available in vcl_deliver
----------------------+-----------------------------------------------------
 Reporter:  grosser2  |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.2
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 # add hit or miss in header
   if (beresp.hits > 0) {
     set resp.http.X-Cache = "HIT";
   } else {
     set resp.http.X-Cache = "MISS";
   }

 Message from VCC-compiler:
 Unknown variable 'beresp.hits'
 At: (input Line 52 Pos 7)
   if (beresp.hits > 0) {
 ------###########-------
 Running VCC-compiler failed, exit 1
 VCL compilation failed

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



From varnish-bugs at varnish-cache.org  Mon Jun 14 07:24:50 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 14 Jun 2010 07:24:50 -0000
Subject: [Varnish] #711: 64bit Catch 22 on Solaris (gcc _builtin_xxx
	functions)
In-Reply-To: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>
References: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>
Message-ID: <050.1a232d40eff3518a485f3ca1ce3d7b42@varnish-cache.org>

#711: 64bit Catch 22 on Solaris (gcc _builtin_xxx functions)
--------------------------------+-------------------------------------------
  Reporter:  tinl               |        Type:  defect                                              
    Status:  reopened           |    Priority:  normal                                              
 Milestone:  After Varnish 2.1  |   Component:  build                                               
   Version:  trunk              |    Severity:  major                                               
Resolution:                     |    Keywords:  __builtin_isfinite, link error, 64-bit, solaris, gcc
--------------------------------+-------------------------------------------
Changes (by phk):

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


-- 
Ticket URL: <http://varnish-cache.org/ticket/711#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 14 07:32:05 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 14 Jun 2010 07:32:05 -0000
Subject: [Varnish] #716: varnishstat assert error in do_curses()
In-Reply-To: <043.8090dcf2a654a331314f64ddb40c163f@varnish-cache.org>
References: <043.8090dcf2a654a331314f64ddb40c163f@varnish-cache.org>
Message-ID: <052.9fb3763793e9e1cd95d4388ea9450065@varnish-cache.org>

#716: varnishstat assert error in do_curses()
-------------------------+--------------------------------------------------
 Reporter:  mkania       |        Owner:  phk   
     Type:  defect       |       Status:  closed
 Priority:  normal       |    Milestone:        
Component:  varnishstat  |      Version:  2.1.2 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

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


Old description:

> Whenever I try to run varnishstat and assert error is thrown saying:
>
> {{{
> Assert error in do_curses(), varnishstat_curses.c line 176:
> Condition((curs_set(0)) != ERR) not true.
> Aborted
> }}}
>
> If I run varnishstat -1 it outputs the statistics fine.
>

> {{{
> varnishstat -1
> client_conn             20411         0.28 Client connections accepted
> client_drop                 0         0.00 Connection dropped, no
> sess/wrk
> client_req              20411         0.28 Client requests received
> cache_hit                5048         0.07 Cache hits
> cache_hitpass               0         0.00 Cache hits for pass
> cache_miss              13468         0.18 Cache misses
> backend_conn             3715         0.05 Backend conn. success
> backend_unhealthy            0         0.00 Backend conn. not attempted
> backend_busy                0         0.00 Backend conn. too many
> backend_fail              133         0.00 Backend conn. failures
> backend_reuse           11515         0.16 Backend conn. reuses
> backend_toolate          1844         0.03 Backend conn. was closed
> backend_recycle         13360         0.18 Backend conn. recycles
> backend_unused              0         0.00 Backend conn. unused
> fetch_head                  0         0.00 Fetch head
> fetch_length            13361         0.18 Fetch with Length
> fetch_chunked               0         0.00 Fetch chunked
> fetch_eof                   0         0.00 Fetch EOF
> fetch_bad                   0         0.00 Fetch had bad headers
> fetch_close                 0         0.00 Fetch wanted close
> fetch_oldhttp               0         0.00 Fetch pre HTTP/1.1 closed
> fetch_zero                  0         0.00 Fetch zero len
> fetch_failed                0         0.00 Fetch failed
> n_sess_mem                 16          .   N struct sess_mem
> n_sess                      0          .   N struct sess
> n_object                  514          .   N struct object
> n_vampireobject             0          .   N unresurrected objects
> n_objectcore              516          .   N struct objectcore
> n_objecthead              189          .   N struct objecthead
> n_smf                    1029          .   N struct smf
> n_smf_frag                  0          .   N small free smf
> n_smf_large                 1          .   N large free smf
> n_vbe_conn                  1          .   N struct vbe_conn
> n_wrk                       2          .   N worker threads
> n_wrk_create               17         0.00 N worker threads created
> n_wrk_failed                0         0.00 N worker threads not created
> n_wrk_max                   0         0.00 N worker threads limited
> n_wrk_queue                 0         0.00 N queued work requests
> n_wrk_overflow            299         0.00 N overflowed work requests
> n_wrk_drop                  0         0.00 N dropped work requests
> n_backend                  20          .   N backends
> n_expired               12847          .   N expired objects
> n_lru_nuked                 0          .   N LRU nuked objects
> n_lru_saved                 0          .   N LRU saved objects
> n_lru_moved              2678          .   N LRU moved objects
> n_deathrow                  0          .   N objects on deathrow
> losthdr                     0         0.00 HTTP header overflows
> n_objsendfile               0         0.00 Objects sent with sendfile
> n_objwrite                505         0.01 Objects sent with write
> n_objoverflow               0         0.00 Objects overflowing workspace
> s_sess                  20411         0.28 Total Sessions
> s_req                   20411         0.28 Total Requests
> s_pipe                   1871         0.03 Total pipe
> s_pass                     24         0.00 Total pass
> s_fetch                 13361         0.18 Total fetch
> s_hdrbytes            7527067       103.22 Total header bytes
> s_bodybytes        1383973018     18979.33 Total body bytes
> sess_closed             20408         0.28 Session Closed
> sess_pipeline               0         0.00 Session Pipeline
> sess_readahead              2         0.00 Session Read Ahead
> sess_linger                12         0.00 Session Linger
> sess_herd                   3         0.00 Session herd
> shm_records           1121851        15.38 SHM records
> shm_writes             113574         1.56 SHM writes
> shm_flushes                 0         0.00 SHM flushes due to overflow
> shm_cont                    5         0.00 SHM MTX contention
> shm_cycles                  0         0.00 SHM cycles through buffer
> sm_nreq                 26722         0.37 allocator requests
> sm_nobj                  1028          .   outstanding allocations
> sm_balloc           703770624          .   bytes allocated
> sm_bfree         267731685376          .   bytes free
> sms_nreq                  131         0.00 SMS allocator requests
> sms_nobj                    0          .   SMS outstanding allocations
> sms_nbytes                  0          .   SMS outstanding bytes
> sms_balloc              63928          .   SMS bytes allocated
> sms_bfree               63928          .   SMS bytes freed
> backend_req             13362         0.18 Backend requests made
> n_vcl                      31         0.00 N vcl total
> n_vcl_avail                31         0.00 N vcl available
> n_vcl_discard               0         0.00 N vcl discarded
> n_purge                     1          .   N total active purges
> n_purge_add                 1         0.00 N new purges added
> n_purge_retire              0         0.00 N old purges deleted
> n_purge_obj_test            0         0.00 N objects tested
> n_purge_re_test             0         0.00 N regexps tested against
> n_purge_dups                0         0.00 N duplicate purges removed
> hcb_nolock              18516         0.25 HCB Lookups without lock
> hcb_lock                 3911         0.05 HCB Lookups with lock
> hcb_insert               3910         0.05 HCB Inserts
> esi_parse                   0         0.00 Objects ESI parsed (unlock)
> esi_errors                  0         0.00 ESI parse errors (unlock)
> accept_fail                 0         0.00 Accept failures
> client_drop_late            0         0.00 Connection dropped late
> uptime                  72920         1.00 Client uptime
> critbit_cooler              0          .   Objhdr's on cool list
>
> }}}

New description:

 Whenever I try to run varnishstat and assert error is thrown saying:

 {{{
 Assert error in do_curses(), varnishstat_curses.c line 176:
 Condition((curs_set(0)) != ERR) not true.
 Aborted
 }}}

 If I run varnishstat -1 it outputs the statistics fine.


 {{{
 varnishstat -1
 client_conn             20411         0.28 Client connections accepted
 client_drop                 0         0.00 Connection dropped, no sess/wrk
 client_req              20411         0.28 Client requests received
 cache_hit                5048         0.07 Cache hits
 cache_hitpass               0         0.00 Cache hits for pass
 cache_miss              13468         0.18 Cache misses
 backend_conn             3715         0.05 Backend conn. success
 backend_unhealthy            0         0.00 Backend conn. not attempted
 backend_busy                0         0.00 Backend conn. too many
 backend_fail              133         0.00 Backend conn. failures
 backend_reuse           11515         0.16 Backend conn. reuses
 backend_toolate          1844         0.03 Backend conn. was closed
 backend_recycle         13360         0.18 Backend conn. recycles
 backend_unused              0         0.00 Backend conn. unused
 fetch_head                  0         0.00 Fetch head
 fetch_length            13361         0.18 Fetch with Length
 fetch_chunked               0         0.00 Fetch chunked
 fetch_eof                   0         0.00 Fetch EOF
 fetch_bad                   0         0.00 Fetch had bad headers
 fetch_close                 0         0.00 Fetch wanted close
 fetch_oldhttp               0         0.00 Fetch pre HTTP/1.1 closed
 fetch_zero                  0         0.00 Fetch zero len
 fetch_failed                0         0.00 Fetch failed
 n_sess_mem                 16          .   N struct sess_mem
 n_sess                      0          .   N struct sess
 n_object                  514          .   N struct object
 n_vampireobject             0          .   N unresurrected objects
 n_objectcore              516          .   N struct objectcore
 n_objecthead              189          .   N struct objecthead
 n_smf                    1029          .   N struct smf
 n_smf_frag                  0          .   N small free smf
 n_smf_large                 1          .   N large free smf
 n_vbe_conn                  1          .   N struct vbe_conn
 n_wrk                       2          .   N worker threads
 n_wrk_create               17         0.00 N worker threads created
 n_wrk_failed                0         0.00 N worker threads not created
 n_wrk_max                   0         0.00 N worker threads limited
 n_wrk_queue                 0         0.00 N queued work requests
 n_wrk_overflow            299         0.00 N overflowed work requests
 n_wrk_drop                  0         0.00 N dropped work requests
 n_backend                  20          .   N backends
 n_expired               12847          .   N expired objects
 n_lru_nuked                 0          .   N LRU nuked objects
 n_lru_saved                 0          .   N LRU saved objects
 n_lru_moved              2678          .   N LRU moved objects
 n_deathrow                  0          .   N objects on deathrow
 losthdr                     0         0.00 HTTP header overflows
 n_objsendfile               0         0.00 Objects sent with sendfile
 n_objwrite                505         0.01 Objects sent with write
 n_objoverflow               0         0.00 Objects overflowing workspace
 s_sess                  20411         0.28 Total Sessions
 s_req                   20411         0.28 Total Requests
 s_pipe                   1871         0.03 Total pipe
 s_pass                     24         0.00 Total pass
 s_fetch                 13361         0.18 Total fetch
 s_hdrbytes            7527067       103.22 Total header bytes
 s_bodybytes        1383973018     18979.33 Total body bytes
 sess_closed             20408         0.28 Session Closed
 sess_pipeline               0         0.00 Session Pipeline
 sess_readahead              2         0.00 Session Read Ahead
 sess_linger                12         0.00 Session Linger
 sess_herd                   3         0.00 Session herd
 shm_records           1121851        15.38 SHM records
 shm_writes             113574         1.56 SHM writes
 shm_flushes                 0         0.00 SHM flushes due to overflow
 shm_cont                    5         0.00 SHM MTX contention
 shm_cycles                  0         0.00 SHM cycles through buffer
 sm_nreq                 26722         0.37 allocator requests
 sm_nobj                  1028          .   outstanding allocations
 sm_balloc           703770624          .   bytes allocated
 sm_bfree         267731685376          .   bytes free
 sms_nreq                  131         0.00 SMS allocator requests
 sms_nobj                    0          .   SMS outstanding allocations
 sms_nbytes                  0          .   SMS outstanding bytes
 sms_balloc              63928          .   SMS bytes allocated
 sms_bfree               63928          .   SMS bytes freed
 backend_req             13362         0.18 Backend requests made
 n_vcl                      31         0.00 N vcl total
 n_vcl_avail                31         0.00 N vcl available
 n_vcl_discard               0         0.00 N vcl discarded
 n_purge                     1          .   N total active purges
 n_purge_add                 1         0.00 N new purges added
 n_purge_retire              0         0.00 N old purges deleted
 n_purge_obj_test            0         0.00 N objects tested
 n_purge_re_test             0         0.00 N regexps tested against
 n_purge_dups                0         0.00 N duplicate purges removed
 hcb_nolock              18516         0.25 HCB Lookups without lock
 hcb_lock                 3911         0.05 HCB Lookups with lock
 hcb_insert               3910         0.05 HCB Inserts
 esi_parse                   0         0.00 Objects ESI parsed (unlock)
 esi_errors                  0         0.00 ESI parse errors (unlock)
 accept_fail                 0         0.00 Accept failures
 client_drop_late            0         0.00 Connection dropped late
 uptime                  72920         1.00 Client uptime
 critbit_cooler              0          .   Objhdr's on cool list

 }}}

--

Comment:

 This should be fixed in r4951

-- 
Ticket URL: <http://varnish-cache.org/ticket/716#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 15 08:16:47 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 15 Jun 2010 08:16:47 -0000
Subject: [Varnish] #719: Panic message: Missing errorhandling code in
	parse_esi_tag(), cache_esi.c line 634
Message-ID: <045.1baf008aa3a50769ece42750f8e68de6@varnish-cache.org>

#719: Panic message: Missing errorhandling code in parse_esi_tag(), cache_esi.c
line 634
----------------------+-----------------------------------------------------
 Reporter:  tseliger  |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 We are getting the following (at the bottom of the mail) error on an ESI
 include, but I have no idea if this can be triggered by wrong
 configuration. The initial request goes to a local tomcat, the response
 html has the following ESI include:

 <esi:include
 src="/external/newsticker/snippet/template/snippet_neue_rechte_leiste/limit/6">

 The error does not happen everytime, but from time to time. I have not
 found a way to reproduce it for sure.

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



From varnish-bugs at varnish-cache.org  Tue Jun 15 11:11:58 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 15 Jun 2010 11:11:58 -0000
Subject: [Varnish] #720: esi confuses varnishncsa
Message-ID: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org>

#720: esi confuses varnishncsa
-------------------+--------------------------------------------------------
 Reporter:  knan   |        Type:  defect     
   Status:  new    |    Priority:  normal     
Milestone:         |   Component:  varnishncsa
  Version:  2.1.0  |    Severity:  normal     
 Keywords:         |  
-------------------+--------------------------------------------------------
 Varnishlog reports Length multiple times for an esi-processed request,
 which causes it to be marked bogus and ignored by varnishncsa.

 Will attach example and workaround.

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



From varnish-bugs at varnish-cache.org  Tue Jun 15 11:38:22 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 15 Jun 2010 11:38:22 -0000
Subject: [Varnish] #721: hash and client director docs.
Message-ID: <042.44046c3f38fda5026350770b01e061ae@varnish-cache.org>

#721: hash and client director docs.
---------------------------+------------------------------------------------
 Reporter:  perbu          |       Owner:       
     Type:  documentation  |      Status:  new  
 Priority:  normal         |   Milestone:       
Component:  build          |     Version:  trunk
 Severity:  normal         |    Keywords:  perbu
---------------------------+------------------------------------------------
 Document the "hash" and "client" directors in the VCL man page.

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



From varnish-bugs at varnish-cache.org  Tue Jun 15 12:11:48 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 15 Jun 2010 12:11:48 -0000
Subject: [Varnish] #720: esi confuses varnishncsa
In-Reply-To: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org>
References: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org>
Message-ID: <050.8c17a2846c4f89a0d969d981a2b3dfac@varnish-cache.org>

#720: esi confuses varnishncsa
-------------------+--------------------------------------------------------
 Reporter:  knan   |        Type:  defect     
   Status:  new    |    Priority:  normal     
Milestone:         |   Component:  varnishncsa
  Version:  2.1.0  |    Severity:  normal     
 Keywords:         |  
-------------------+--------------------------------------------------------

Comment(by knan):

 The varnishlog is from 2.1.2, btw, so the bug is still there. The customer
 was using plain 2.1.

-- 
Ticket URL: <http://varnish-cache.org/ticket/720#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Jun 16 21:18:56 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 16 Jun 2010 21:18:56 -0000
Subject: [Varnish] #722: Director cleanup issue on vcl.discard
Message-ID: <040.72efccced4c789e3b09e4a32f5ead9b1@varnish-cache.org>

#722: Director cleanup issue on vcl.discard
----------------------+-----------------------------------------------------
 Reporter:  phk       |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 We don't clean up directors and the backends they depend on in the right
 order in the compiled VGC_Fini() function.

 May cause panic.

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



From varnish-bugs at varnish-cache.org  Wed Jun 16 22:15:32 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 16 Jun 2010 22:15:32 -0000
Subject: [Varnish] #722: Director cleanup issue on vcl.discard
In-Reply-To: <040.72efccced4c789e3b09e4a32f5ead9b1@varnish-cache.org>
References: <040.72efccced4c789e3b09e4a32f5ead9b1@varnish-cache.org>
Message-ID: <049.ab844920ec2d6c7eceddede2d6b15130@varnish-cache.org>

#722: Director cleanup issue on vcl.discard
----------------------+-----------------------------------------------------
 Reporter:  phk       |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 (In [4967]) Fix a problem in director teardown at vcl.discard time:

 We didn't create/destroy directors and backends in a consistent order,
 and in some case we even destroyed directors more than once.

 Always destroy in opposite order of creation (which follows VCL
 source order).

 Turn the bottom element of the array into (only) an indication
 of which backend/director is the default.

 Fixes:  #722

-- 
Ticket URL: </ticket/722#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Jun 17 11:50:13 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 17 Jun 2010 11:50:13 -0000
Subject: [Varnish] #723: Incorrect SVN checkout URL in documentation
Message-ID: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>

#723: Incorrect SVN checkout URL in documentation
----------------------+-----------------------------------------------------
 Reporter:  walraven  |        Type:  documentation
   Status:  new       |    Priority:  normal       
Milestone:            |   Component:  build        
  Version:  trunk     |    Severity:  normal       
 Keywords:            |  
----------------------+-----------------------------------------------------
 svn co http://varnish-cache.org/svn/varnish/trunk
 svn: URL 'http://varnish-cache.org/svn/varnish/trunk' doesn't exist

 Path should point to /svn/trunk, also for the branches /svn/branches/2.1

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



From varnish-bugs at varnish-cache.org  Thu Jun 17 12:17:46 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 17 Jun 2010 12:17:46 -0000
Subject: [Varnish] #724: Panic message: Assert error in VRT_synth_page(),
	cache_vrt.c line 918
Message-ID: <045.1cc93d7e2d7a906a7cf5bf88afb252fb@varnish-cache.org>

#724: Panic message: Assert error in VRT_synth_page(), cache_vrt.c line 918
----------------------+-----------------------------------------------------
 Reporter:  tseliger  |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.2
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 We are getting errors like this from time to time. I cannot reproduce them
 for sure. This happens on different esi's.

 The following request was triggered by:

 {{{
 <esi:include src="/external/php/app/fast/snippets/index.php/wm2010" />
 }}}

 And the error in syslog:

 {{{
 Jun 17 09:57:34 pol-web-7 varnishd[3509]: Child (18002) Panic message:
 Assert error in VRT_synth_page(), cache_vrt.c line 918:   Condition((sp
 ->obj) != NULL) not true. thread = (cache-worker) ident =
 Linux,2.6.24-25-xen,x86_64,-smalloc,-hcritbit,epoll Backtrace:   0x4235e7:
 /usr/sbin
 /varnishd [0x4235e7]   0x42a7ba: /usr/sbin/varnishd(VRT_synth_page+0x1da)
 [0x42a7ba]   0x7fdf1ccf8cd6: ./vcl.1P9zoqAU.so [0x7fdf1ccf8cd6]   0x
 4280a6: /usr/sbin/varnishd(VCL_fetch_method+0x46) [0x4280a6]   0x4136e8:
 /usr/sbin/varnishd [0x4136e8]   0x414ebb: /usr/sbin/varnishd(CNT_Sess
 ion+0x39b) [0x414ebb]   0x41731d: /usr/sbin/varnishd(ESI_Deliver+0x2bd)
 [0x41731d]   0x425c4c: /usr/sbin/varnishd(RES_WriteObj+0x19c) [0x425c4c]
 0x4141ad: /usr/sbin/varnishd [0x4141ad]   0x414e97:
 /usr/sbin/varnishd(CNT_Session+0x377) [0x414e97] sp = 0x7fdf1c902008 {
 fd = 21, id = 21, xid = 0,   client = 93.203.220.17:38501,   step =
 STP_FETCH,   handling = deliver,   err_code = 301, err_reason = (null),
 restarts = 0, esis = 1   ws = 0x7fdf1c902078 {      id = "sess",
 {s,f,r,e} = {0x7fdf1c902c90,+600,(nil),+512000},   },   http[req] = {
 ws = 0x7fdf1c902078[sess]       "GET",
 "/app/fast/snippets/index.php/wm2010",       "HTTP/1.1",       "User-
 Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3)
 Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)",       "Accept:
 text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
 "Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3",       "Accept-
 Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",       "Keep-Alive: 115",
 "Connection: keep-alive",       "X_FORWARDED_PROTO: https",       "host:
 www.sueddeutsche.de",   },   worker = 0x7fddc7cd7e80 {     ws =
 0x7fddc7cd7fe8 {        id = "wrk",       {s,f,r,e} =
 {0x7fddc7c58e00,+536,(nil),+512000},     },     http[bereq] = {       ws =
 0x7fddc7cd7fe8[wrk]         "GET",
 "/app/fast/snippets/index.php/wm2010",         "HTTP/1.1",         "User-
 Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3)
 Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)",         "Accept:
 text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
 "Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3",         "Accept-
 Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",         "X_FORWARDED_PROTO:
 https",         "host: www.sueddeutsche.de",         "X-Varnish: 0",
 },     http[beresp] = {       ws = 0x7fddc7cd7fe8[wrk]         "HTTP/1.1",
 "301",         "Moved Permanently",         "Date: Thu, 17 Jun 2010
 09:57:34 GMT",         "Server: Apache",         "Location:
 http://www.sueddeutsche.de/app/fast/snippets/index.php/wm2010",
 "Vary: Accept-Encoding",         "Content-Length: 269",         "Content-
 Type: text/html; charset=iso-8859-1",     },     },     vcl = {
 srcname = {         "input",         "Default",       },     }, },

 }}}

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



From varnish-bugs at varnish-cache.org  Thu Jun 17 14:14:47 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 17 Jun 2010 14:14:47 -0000
Subject: [Varnish] #725: Assert error in _vsb_assert_integrity(), vsb.c line 84
Message-ID: <043.04a0ac6567238cab3f466b29de0abb3c@varnish-cache.org>

#725: Assert error in _vsb_assert_integrity(), vsb.c line 84
----------------------+-----------------------------------------------------
 Reporter:  anakin    |       Owner:  phk                
     Type:  defect    |      Status:  new                
 Priority:  normal    |   Milestone:  Varnish 2.1 release
Component:  varnishd  |     Version:  2.1.0              
 Severity:  normal    |    Keywords:                     
----------------------+-----------------------------------------------------
 I am getting two different panic messages when try to test the performance
 of just written VCL code. Before these I was getting an assert error on
 WS_Release, mentioned in different tickets and maked as fixed - that ended
 after I removed line changing header value in vcl_hit (increasing
 sess_workspace did nothing).

 Now im getting two different panic messages, every time I try to run
 multiple requests on Varnish.

 {{{
 Child (12510) Panic message: Assert error in _vsb_assert_integrity(),
 vsb.c line 84:
   Condition(s->s_magic == 0x4a82dd8a) not true.
 thread = (cache-worker)
 ident = Linux,2.6.18-6-xen-amd64,x86_64,-smalloc,-hcritbit,epoll
 Backtrace:
   0x422136: /usr/sbin/varnishd [0x422136]
   0x2b31f37bfab3: /usr/lib/libvarnish.so.1 [0x2b31f37bfab3]
   0x2b31f37bfdb3: /usr/lib/libvarnish.so.1(vsb_delete+0x13)
 [0x2b31f37bfdb3]
   0x43bf54: /usr/sbin/varnishd [0x43bf54]
   0x41afaf: /usr/sbin/varnishd(HSH_Freestore+0x2f) [0x41afaf]
   0x43bfd7: /usr/sbin/varnishd(SMS_Makesynth+0x47) [0x43bfd7]
   0x428da5: /usr/sbin/varnishd(VRT_synth_page+0xa5) [0x428da5]
   0x2aaaaad03405: ./vcl.1P9zoqAU.so [0x2aaaaad03405]
   0x2aaaaad04bbf: ./vcl.1P9zoqAU.so [0x2aaaaad04bbf]
   0x426726: /usr/sbin/varnishd(VCL_deliver_method+0x46) [0x426726]
 sp = 0x2aaaab408008 {
   fd = 14, id = 14, xid = 1732731011,
   client = 10.1.12.134:36792,
   step = STP_DELIVER,
   handling = deliver,
   restarts = 0, esis = 0
   ws = 0x2aaaab408078 {
     id = "sess",
     {s,f,r,e} = {0x2aaaab409510,+246,(nil),+131072},
   },
   http[req] = {
     ws = 0x2aaaab408078[sess]
       "GET",
       "/1",
       "HTTP/1.0",
       "User-Agent: ApacheBench/2.0.40-dev",
       "Host: uc1.avatars.pl",
       "Accept: */*",
       "_request_type: user_avatar",
       "_request_state: object_lookup",
       "X-Avatar-Size: small",
       "X-Avatar-Id: 0",
       "X-Avatar-Type: user",
   },
   worker = 0x4600ae80 {
     ws = 0x4600afe8 {
       id = "wrk",
       {s,f,r,e} = {0x45fe8e30,+94,(nil),+131072},
     },
     },
     vcl = {
       srcname = {
         "input",
         "Default",
         "/etc/varnish/conf-enabled/000-backend.avatars2.vcl",
         "/etc/varnish/conf-enabled/000-initialize.avatars2.vcl",
         "/etc/varnish/conf-enabled/010-error-handler.avatars2.vcl",
         "/etc/varnish/conf-enabled/100-common.avatars2.vcl",
         "/etc/varnish/conf-enabled/110-router.avatars2.vcl",
         "/etc/varnish/conf-enabled/200-user-
 avatar.application.avatars2.vcl",
         "/etc/varnish/conf-enabled/800-error-handler.avatars2.vcl",
         "/etc/varnish/conf-enabled/810-protocol-cleanup.avatars2.vcl",
         "/etc/varnish/conf-enabled/900-dummy.avatars2.vcl",
       },
     },
   obj = 0x2b31f4d1b000 {
     xid = 1732730854,
     ws = 0x2b31f4d1b020 {
       id = "obj",
       {s,f,r,e} = {0x2b31f4d1b25a,+335,(nil),+347},
     },
     http[obj] = {
       ws = 0x2b31f4d1b020[obj]
         "HTTP/1.1",
         "404",
         "Not Found",
         "X-Powered-By: PHP/5.2.9",
         "Cache-Control: public, max-age=86400, must-revalidate",
         "Expires: Thu, 17 Jun 2010 15:05:34 GMT",
         "Last-Modified: Thu, 17 Jun 2010 14:05:34 GMT",
         "X-Error: 2",
         "Content-type: text/html",
         "Date: Thu, 17 Jun 2010 14:05:34 GMT",
         "Server: lighttpd/1.4.19",
         "X-Cache: miss",
         "X-Status: 404",
     },
     len = 0,
     store = {
       0 {
       },
     },
   },
 },


 Child cleanup complete
 }}}


 {{{
 Child (12900) Panic message: Assert error in _vsb_assert_state(), vsb.c
 line 100:
   Condition((s->s_flags & 0x00020000) == state) not true.
 thread = (cache-worker)
 ident = Linux,2.6.18-6-xen-amd64,x86_64,-smalloc,-hcritbit,epoll
 Backtrace:
   0x422136: /usr/sbin/varnishd [0x422136]
   0x2b31f37bfbe4: /usr/lib/libvarnish.so.1(vsb_finish+0x24)
 [0x2b31f37bfbe4]
   0x43be12: /usr/sbin/varnishd(SMS_Finish+0x82) [0x43be12]
   0x428e4b: /usr/sbin/varnishd(VRT_synth_page+0x14b) [0x428e4b]
   0x2aaaaac03405: ./vcl.1P9zoqAU.so [0x2aaaaac03405]
   0x2aaaaac04bbf: ./vcl.1P9zoqAU.so [0x2aaaaac04bbf]
   0x426726: /usr/sbin/varnishd(VCL_deliver_method+0x46) [0x426726]
   0x41318f: /usr/sbin/varnishd [0x41318f]
   0x413ed3: /usr/sbin/varnishd(CNT_Session+0x373) [0x413ed3]
   0x424538: /usr/sbin/varnishd [0x424538]
 sp = 0x2aaaaab82008 {
   fd = 12, id = 12, xid = 327947177,
   client = 10.1.12.134:57507,
   step = STP_DELIVER,
   handling = deliver,
   restarts = 0, esis = 0
   ws = 0x2aaaaab82078 {
     id = "sess",
     {s,f,r,e} = {0x2aaaaab83510,+246,(nil),+131072},
   },
   http[req] = {
     ws = 0x2aaaaab82078[sess]
       "GET",
       "/1",
       "HTTP/1.0",
       "User-Agent: ApacheBench/2.0.40-dev",
       "Host: uc1.avatars.pl",
       "Accept: */*",
       "_request_type: user_avatar",
       "_request_state: object_lookup",
       "X-Avatar-Size: small",
       "X-Avatar-Id: 0",
       "X-Avatar-Type: user",
   },
   worker = 0x4800ee80 {
     ws = 0x4800efe8 {
       id = "wrk",
       {s,f,r,e} = {0x47fece30,+92,(nil),+131072},
     },
     },
     vcl = {
       srcname = {
         "input",
         "Default",
         "/etc/varnish/conf-enabled/000-backend.avatars2.vcl",
         "/etc/varnish/conf-enabled/000-initialize.avatars2.vcl",
         "/etc/varnish/conf-enabled/010-error-handler.avatars2.vcl",
         "/etc/varnish/conf-enabled/100-common.avatars2.vcl",
         "/etc/varnish/conf-enabled/110-router.avatars2.vcl",
         "/etc/varnish/conf-enabled/200-user-
 avatar.application.avatars2.vcl",
         "/etc/varnish/conf-enabled/800-error-handler.avatars2.vcl",
         "/etc/varnish/conf-enabled/810-protocol-cleanup.avatars2.vcl",
         "/etc/varnish/conf-enabled/900-dummy.avatars2.vcl",
       },
     },
   obj = 0x2b31f4d1b000 {
     xid = 327946745,
     ws = 0x2b31f4d1b020 {
       id = "obj",
       {s,f,r,e} = {0x2b31f4d1b25a,+335,(nil),+347},
     },
     http[obj] = {
       ws = 0x2b31f4d1b020[obj]
         "HTTP/1.1",
         "404",
         "Not Found",
         "X-Powered-By: PHP/5.2.9",
         "Cache-Control: public, max-age=86400, must-revalidate",
         "Expires: Thu, 17 Jun 2010 15:08:16 GMT",
         "Last-Modified: Thu, 17 Jun 2010 14:08:16 GMT",
         "X-Error: 2",
         "Content-type: text/html",
         "Date: Thu, 17 Jun 2010 14:08:16 GMT",
         "Server: lighttpd/1.4.19",
         "X-Cache: miss",
         "X-Status: 404",
     },
     len = 0,
     store = {
       0 {
       },
     },
   },
 },


 Child cleanup complete
 }}}

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



From varnish-bugs at varnish-cache.org  Thu Jun 17 15:25:33 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 17 Jun 2010 15:25:33 -0000
Subject: [Varnish] #724: Panic message: Assert error in VRT_synth_page(), 
	cache_vrt.c line 918
In-Reply-To: <045.1cc93d7e2d7a906a7cf5bf88afb252fb@varnish-cache.org>
References: <045.1cc93d7e2d7a906a7cf5bf88afb252fb@varnish-cache.org>
Message-ID: <054.938602ff2618c9f237debe90877e535f@varnish-cache.org>

#724: Panic message: Assert error in VRT_synth_page(), cache_vrt.c line 918
----------------------+-----------------------------------------------------
 Reporter:  tseliger  |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.2
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------

Comment(by tseliger):

 reformatted the panic message for better read experience:

 {{{
 Panic message: Assert error in VRT_synth_page(), cache_vrt.c line 918:
    Condition((sp->obj) != NULL) not true. thread = (cache-worker) ident =
 Linux,2.6.24-25-xen,x86_64,-smalloc,-hcritbit,epoll

 Backtrace:
    0x4235e7: /usr/sbin/varnishd [0x4235e7]
    0x42a7ba: /usr/sbin/varnishd(VRT_synth_page+0x1da) [0x42a7ba]
    0x7fdf1ccf8cd6: ./vcl.1P9zoqAU.so [0x7fdf1ccf8cd6]
    0x4280a6: /usr/sbin/varnishd(VCL_fetch_method+0x46) [0x4280a6]
    0x4136e8: /usr/sbin/varnishd [0x4136e8]
    0x414ebb: /usr/sbin/varnishd(CNT_Session+0x39b) [0x414ebb]
    0x41731d: /usr/sbin/varnishd(ESI_Deliver+0x2bd) [0x41731d]
    0x425c4c: /usr/sbin/varnishd(RES_WriteObj+0x19c) [0x425c4c]
    0x4141ad: /usr/sbin/varnishd [0x4141ad]
    0x414e97: /usr/sbin/varnishd(CNT_Session+0x377) [0x414e97]

 sp = 0x7fdf1c902008 {
    fd = 21, id = 21, xid = 0,
    client = 93.203.220.17:38501,
    step = STP_FETCH,
    handling = deliver,
    err_code = 301, err_reason = (null),
    restarts = 0, esis = 1
    ws = 0x7fdf1c902078 {
       id = "sess",
      {s,f,r,e} = {0x7fdf1c902c90,+600,(nil),+512000},
    },
    http[req] = {
      ws = 0x7fdf1c902078[sess]
        "GET",
        "/app/fast/snippets/index.php/wm2010",
        "HTTP/1.1",
        "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)",
        "Accept:
 text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
        "Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3",
        "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
        "Keep-Alive: 115",
        "Connection: keep-alive",
        "X_FORWARDED_PROTO: https",
        "host: www.sueddeutsche.de",
    },
    worker = 0x7fddc7cd7e80 {
      ws = 0x7fddc7cd7fe8 {
         id = "wrk",
        {s,f,r,e} = {0x7fddc7c58e00,+536,(nil),+512000},
      },
      http[bereq] = {
        ws = 0x7fddc7cd7fe8[wrk]
          "GET",
          "/app/fast/snippets/index.php/wm2010",
          "HTTP/1.1",
          "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)",
          "Accept:
 text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
          "Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3",
          "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
          "X_FORWARDED_PROTO: https",
          "host: www.sueddeutsche.de",
          "X-Varnish: 0",
      },
      http[beresp] = {
        ws = 0x7fddc7cd7fe8[wrk]
          "HTTP/1.1",
          "301",
          "Moved Permanently",
          "Date: Thu, 17 Jun 2010 09:57:34 GMT",
          "Server: Apache",
          "Location:
 http://www.sueddeutsche.de/app/fast/snippets/index.php/wm2010",
          "Vary: Accept-Encoding",
          "Content-Length: 269",
          "Content-Type: text/html; charset=iso-8859-1",
      },
      },
      vcl = {
        srcname = {
          "input",
          "Default",
        },
      },
  },

 }}}

-- 
Ticket URL: <http://varnish-cache.org/ticket/724#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Jun 17 15:34:41 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 17 Jun 2010 15:34:41 -0000
Subject: [Varnish] #719: Panic message: Missing errorhandling code in
	parse_esi_tag(), cache_esi.c line 634
In-Reply-To: <045.1baf008aa3a50769ece42750f8e68de6@varnish-cache.org>
References: <045.1baf008aa3a50769ece42750f8e68de6@varnish-cache.org>
Message-ID: <054.3f81cc2af0cc4663578f2427f54bd20e@varnish-cache.org>

#719: Panic message: Missing errorhandling code in parse_esi_tag(), cache_esi.c
line 634
----------------------+-----------------------------------------------------
 Reporter:  tseliger  |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------

Comment(by tseliger):

 reformatted panic message for better read experience:

 {{{
 Panic message: Missing errorhandling code in parse_esi_tag(), cache_esi.c
 line 634:

 Condition(q < ew->tag.e) not true.thread = (cache-worker) ident =
 Linux,2.6.24-25-xen,x86_64,-smalloc,-hcritbit,epoll
 Backtrace:
    0x4235e7: /usr/sbin/varnishd [0x4235e7]
    0x418955: /usr/sbin/varnishd [0x418955]
    0x41948d: /usr/sbin/varnishd(ESI_Parse+0x65d) [0x41948d]
    0x413d49: /usr/sbin/varnishd [0x413d49]
    0x414ebb: /usr/sbin/varnishd(CNT_Session+0x39b) [0x414ebb]
    0x425a38: /usr/sbin/varnishd [0x425a38]
    0x424d3e: /usr/sbin/varnishd [0x424d3e]
    0x7f4f2a7963f7: /lib/libpthread.so.0 [0x7f4f2a7963f7]
    0x7f4f2a06bbbd: /lib/libc.so.6(clone+0x6d) [0x7f4f2a06bbbd]

 sp = 0x7f4f23a80008 {   fd = 15, id = 15, xid = 1417192794,
    client = 195.145.180.106:31016,
    step = STP_FETCH,
    handling = deliver,
    err_code = 200, err_reason = (null),
    restarts = 0, esis = 0
    ws = 0x7f4f23a80078 {
       id = "sess",
      {s,f,r,e} = {0x7f4f23a80c90,+1624,(nil),+512000},
    },
    http[req] = {
      ws = 0x7f4f23a80078[sess]
        "GET",
        "/",
        "HTTP/1.0",
        "Accept: */*",
        "Accept-Language: de",
        "UA-CPU: x86",
        "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;
 SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; .NET CLR
 3.5.21022) Webwasher/6.8.6",
        "Via: 1.1 webwasher (Webwasher 6.8.6.6257), 1.1 vn-squid-1.ruv.de
 (squid), 1.0 rv-vvirus-10A:8081 (IWSS)",
        "X-Forwarded-For: 10.192.32.91",
        "Cache-Control: max-age=259200",
        "host: www.sueddeutsche.de",
    },
    worker = 0x4b1d8e80 {
      ws = 0x4b1d8fe8 {
         id = "wrk",
        {s,f,r,e} = {0x4b159e00,+27752,(nil),+512000},
      },
      http[bereq] = {
        ws = 0x4b1d8fe8[wrk]
          "GET",
          "/",
          "HTTP/1.1",
          "Accept: */*",
          "Accept-Language: de",
          "UA-CPU: x86",
          "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;
 SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; .NET CLR
 3.5.21022) Webwasher/6.8.6",
          "Via: 1.1 webwasher (Webwasher 6.8.6.6257), 1.1 vn-squid-1.ruv.de
 (squid), 1.0 rv-vvirus-10A:8081 (IWSS)",
          "X-Forwarded-For: 10.192.32.91",
          "host: www.sueddeutsche.de",
          "X-Varnish: 1417192794",
      },
      http[beresp] = {
        ws = 0x4b1d8fe8[wrk]
          "HTTP/1.1",
          "200",
          "OK",
          "Server: Apache-Coyote/1.1",
          "Expires: Tue, 15 Jun 2010 06:54:36 GMT",
          "Content-Type: text/html;charset=utf-8",
          "Transfer-Encoding: chunked",
          "Date: Tue, 15 Jun 2010 06:53:35 GMT",
          "Cache-Control: max-age=120",
      },
      },
      vcl = {
        srcname = {
          "input",
          "Default",
        },
      },
    obj = 0x7f4f23807300 {
      xid = 1417192794,
      ws = 0x7f4f23807320 {
         id = "obj",
        {s,f,r,e} = {0x7f4f23807508,+240,+248,+248},
      },
      http[obj] = {
        ws = 0x7f4f23807320[obj]
          "HTTP/1.1",
          "200",
          "OK",
          "Server: Apache-Coyote/1.1",
          "Expires: Tue, 15 Jun 2010 06:54:36 GMT",
          "Content-Type: text/html;charset=utf-8",
          "Date: Tue, 15 Jun 2010 06:53:35 GMT",
          "Cache-Control: max-age=120",
          "Content-Length: 139826",
      },
      len = 139826,
      store = {
        131072 {
          3c 21 44 4f 43 54 59 50 45 20 68 74 6d 6c 3e 0a |<!DOCTYPE
 html>.|
          3c 68 74 6d 6c 20 6c 61 6e 67 3d 22 64 65 22 3e |<html
 lang="de">|
          0a 3c 21 2d 2d 20 5b 53 54 41 52 54 20 48 45 41 |.<!-- [START
 HEA|
          44 45 52 5d 20 2d 2d 3e 0a 20 20 3c 68 65 61 64 |DER] -->.
 <head|
          [131008 more]
        },
        8754 {
          73 69 3a 69 6e 63 6c 75 64 65 20 73 72 63 3d 22 |si:include
 src="|
          2f 65 78 74 65 72 6e 61 6c 2f 6e 65 77 73 74 69
 |/external/newsti|
          63 6b 65 72 2f 73 6e 69 70 70 65 74 2f 74 65 6d
 |cker/snippet/tem|
          70 6c 61 74 65 2f 73 6e 69 70 70 65 74 5f 6e 65
 |plate/snippet_ne|
          [8690 more]
        },
      },
    },
  },

 }}}

-- 
Ticket URL: <http://varnish-cache.org/ticket/719#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Jun 18 08:44:29 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 18 Jun 2010 08:44:29 -0000
Subject: [Varnish] #708: XML display is not documented
In-Reply-To: <043.ef00f4612fb85c87d480634e4de05a49@varnish-cache.org>
References: <043.ef00f4612fb85c87d480634e4de05a49@varnish-cache.org>
Message-ID: <052.d785fb88f237888219bc769619329a16@varnish-cache.org>

#708: XML display is not documented
---------------------------+------------------------------------------------
 Reporter:  jerome         |       Owner:  perbu      
     Type:  documentation  |      Status:  new        
 Priority:  normal         |   Milestone:             
Component:  varnishstat    |     Version:  trunk      
 Severity:  minor          |    Keywords:  varnishstat
---------------------------+------------------------------------------------
Changes (by perbu):

  * owner:  phk => perbu


-- 
Ticket URL: <http://varnish-cache.org/ticket/708#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Jun 18 08:46:13 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 18 Jun 2010 08:46:13 -0000
Subject: [Varnish] #726: Assert error in http_SetH(), cache_http.c line 595
Message-ID: <043.c8576d811db370bb2c2909c6b71dc81a@varnish-cache.org>

#726: Assert error in http_SetH(), cache_http.c line 595
----------------------+-----------------------------------------------------
 Reporter:  anakin    |       Owner:  phk                
     Type:  defect    |      Status:  new                
 Priority:  normal    |   Milestone:  Varnish 2.1 release
Component:  varnishd  |     Version:  2.1.0              
 Severity:  normal    |    Keywords:                     
----------------------+-----------------------------------------------------
 Given simple VCL like that:

 {{{
 backend default {
   .host = "localhost";
   .port = "81";
 }

 sub vcl_recv {

   set req.backend = default;
   set req.http.Host = "uc1.avatars.pl";
   return (lookup);
 }

 sub vcl_hit {

   set obj.http.X-Cache = "hit";
 }

 sub vcl_deliver {

   remove resp.http.Via;
   remove resp.http.X-Varnish;
   remove resp.http.Server;
   remove resp.http.Retry-After;
   remove resp.http.Age;

   set resp.status = 200;
   set resp.response = "OK";
 }
 }}}

 Im getting panic message (varnishd (varnish-2.1 SVN 4640:4641)) detailed
 below every time i test Varnish performance on several concurrent
 connections. When we remove the line setting header in vcl_hit its getting
 better, however im still getting reset connections while testing with no
 error dump from varnishd.

 {{{
 Child (26095) Panic message: Assert error in http_SetH(), cache_http.c
 line 595:
   Condition((fm) != 0) not true.
 thread = (cache-worker)
 ident = Linux,2.6.18-6-xen-amd64,x86_64,-smalloc,-hcritbit,epoll
 Backtrace:
   0x422136: /usr/sbin/varnishd [0x422136]
   0x41e2a5: /usr/sbin/varnishd(http_SetH+0xc5) [0x41e2a5]
   0x2aaaaaf0171f: ./vcl.1P9zoqAU.so [0x2aaaaaf0171f]
   0x426726: /usr/sbin/varnishd(VCL_deliver_method+0x46) [0x426726]
   0x41318f: /usr/sbin/varnishd [0x41318f]
   0x413ed3: /usr/sbin/varnishd(CNT_Session+0x373) [0x413ed3]
   0x424538: /usr/sbin/varnishd [0x424538]
   0x423846: /usr/sbin/varnishd [0x423846]
   0x2b7217f51fc7: /lib/libpthread.so.0 [0x2b7217f51fc7]
   0x2b72186d259d: /lib/libc.so.6(clone+0x6d) [0x2b72186d259d]
 sp = 0x2aaaab424008 {
   fd = 14, id = 14, xid = 1551852669,
   client = 10.1.12.134:47782,
   step = STP_DELIVER,
   handling = deliver,
   restarts = 0, esis = 0
   ws = 0x2aaaab424078 {
     id = "sess",
     {s,f,r,e} = {0x2aaaab425510,+164,(nil),+131072},
   },
   http[req] = {
     ws = 0x2aaaab424078[sess]
       "GET",
       "/16026",
       "HTTP/1.0",
       "User-Agent: ApacheBench/2.0.40-dev",
       "Connection: Keep-Alive",
       "Accept: */*",
       "Host: uc1.avatars.pl",
   },
   worker = 0x4680be80 {
     ws = 0x4680bfe8 { overflow
       id = "wrk",
       {s,f,r,e} = {0x467e9e30,+131071,(nil),+131072},
     },
     },
     vcl = {
       srcname = {
         "input",
         "Default",
       },
     },
   obj = 0x2aaaaae2a400 {
     xid = 1551840220,
     ws = 0x2aaaaae2a420 {
       id = "obj",
       {s,f,r,e} = {0x2aaaaae2a638,+312,(nil),+321},
     },
     http[obj] = {
       ws = 0x2aaaaae2a420[obj]
         "HTTP/1.1",
         "200",
         "OK",
         "X-Powered-By: PHP/5.2.6-1+lenny4",
         "Content-type: image/jpg",
         "X-Avatar-Size: 0",
         "X-Avatar-Id: small",
         "Vary: X-Avatar-Id, X-Avatar-Size",
         "Cache-Control: public, max-age=86400, must-revalidate",
         "Date: Fri, 18 Jun 2010 08:37:54 GMT",
         "Server: lighttpd/1.4.19",
         "Content-Length: 2796",
     },
     len = 2796,
     store = {
       2796 {
         ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 48 |......JFIF.....H|
         00 48 00 00 ff db 00 43 00 03 02 02 03 02 02 03 |.H.....C........|
         03 03 03 04 03 03 04 05 08 05 05 04 04 05 0a 07 |................|
         07 06 08 0c 0a 0c 0c 0b 0a 0b 0b 0d 0e 12 10 0d |................|
         [2732 more]
       },
     },
   },
 },


 Child cleanup complete
 }}}

 Header is not being set anyway, single request generates LostHeader every
 time:
 {{{
 12 VCL_call     c recv
 12 VCL_return   c lookup
 12 VCL_call     c hash
 12 VCL_return   c hash
 12 Hit          c 1551840220
 12 VCL_call     c hit
 12 LostHeader   c X-Cache:
 12 VCL_return   c deliver
 }}}

 Command line:
 {{{
 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f
 /etc/varnish/1.vcl -s malloc,1G -p http_headers=128 -p
 sess_workspace=131072 -F
 }}}

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



From varnish-bugs at varnish-cache.org  Mon Jun 21 08:15:23 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Jun 2010 08:15:23 -0000
Subject: [Varnish] #719: Panic message: Missing errorhandling code in
	parse_esi_tag(), cache_esi.c line 634
In-Reply-To: <045.1baf008aa3a50769ece42750f8e68de6@varnish-cache.org>
References: <045.1baf008aa3a50769ece42750f8e68de6@varnish-cache.org>
Message-ID: <054.3e6f79b45947170c2582dff42e904f52@varnish-cache.org>

#719: Panic message: Missing errorhandling code in parse_esi_tag(), cache_esi.c
line 634
----------------------+-----------------------------------------------------
 Reporter:  tseliger  |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 (In [4975]) Fix a bug when ESI elements span storage elements, which only
 the
 tightfisted -smalloc would trigger.

 Fixes: #719

-- 
Ticket URL: </ticket/719#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 21 13:26:50 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Jun 2010 13:26:50 -0000
Subject: [Varnish] #710: check_varnish.c fails to compile against
	varnish 2.1.x
In-Reply-To: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org>
References: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org>
Message-ID: <052.4884be8cde0f717922f45d7f75761345@varnish-cache.org>

#710: check_varnish.c fails to compile against varnish 2.1.x
--------------------+-------------------------------------------------------
 Reporter:  netmax  |        Type:  defect
   Status:  new     |    Priority:  normal
Milestone:          |   Component:  nagios
  Version:  2.1.2   |    Severity:  normal
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by mfournier):

 Replying to [comment:2 sascha]:
 > I'm not certain, but I believe the errors above stem from trying to
 build the nagios plugin from trunk against installed libs from a 2.0.x
 version; at least the same just happened to me.


 You are right. This specific "macro MAC_STAT" error was fixed in r4009. It
 is important to fetch the nagios plugin from the branch matching your
 varnish
 version, not from -trunk.



 > However, the plugin still doesn't build against a fresh 2.1.2 install:
 >
 > check_varnish.c: In function 'check_stats':
 > check_varnish.c:176: error: 'struct varnish_stats' has no member named
 'start_time'
 > make[1]: *** [check_varnish-check_varnish.o] Error 1
 > make[1]: Leaving directory `/root/varnish-svn-trunk/varnish-
 tools/nagios'
 > make: *** [all] Error 2
 >
 >

 From what I understood, the chronology of events is as follows:

  * r509 VSL_stats->start_time got added to varnish
  * r4010 nagios/check_varnish.c adds a "-p uptime" option based on
 VSL_stats->start_time
  * r4519 adds VSL_stats->uptime
  * r4553 removes VSL_stats->start_time, which is considered obsoleted by
 VSL_stats->uptime



 > if I change the line that raises the error to
 >
 > -       up = tv.tv_sec - VSL_stats->start_time;
 > +       up = VSL_stats->uptime;
 >

 I would suggest to revert r4010 instead.

 As VSL_stats->uptime conveniently has the same name as the option added by
 r4010, "-p uptime" wouldn't get broken.



 > /usr/lib/libvarnishapi.so: undefined reference to `VRE_compile'
 > /usr/lib/libvarnishapi.so: undefined reference to `VRE_exec'
 > collect2: ld returned 1 exit status
 > make[1]: *** [check_varnish] Error 1
 > make[1]: Leaving directory `/root/varnish-svn-trunk/varnish-
 tools/nagios'
 > make: *** [all] Error 2
 >
 > }}}

 This seems to have been corrected recently. Please take a look at this
 message and the next ones:

 http://lists.varnish-cache.org/pipermail/varnish-dev/2010-June/002494.html

 Workaround: edit the Makefile and change:
 {{{
 VARNISHAPI_LIBS = -lvarnishapi
 }}}
 to:
 {{{
 VARNISHAPI_LIBS = -lvarnishapi -lvarnish -lvarnishcompat
 }}}



 > BTW, please allow me to hijack the issue with a hint for a little
 enhancement to make the plugin output more human readable:

 +1

 As this bugreport is in a mess, maybe you should open a new one just for
 this feature request ?

 Marc

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/710#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 21 13:53:50 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Jun 2010 13:53:50 -0000
Subject: [Varnish] #727: Tiny Patch: Human readable nagios output
Message-ID: <043.c3df909e2981935706b069f554e595ef@varnish-cache.org>

#727: Tiny Patch: Human readable nagios output
--------------------+-------------------------------------------------------
 Reporter:  sascha  |        Type:  enhancement
   Status:  new     |    Priority:  normal     
Milestone:          |   Component:  build      
  Version:  trunk   |    Severity:  normal     
 Keywords:          |  
--------------------+-------------------------------------------------------
 as mentioned in #710, I suggest a little change to make big number easier
 readable:

 {{{
 ~/varnish-svn-trunk/varnish-tools/nagios# svn diff
 Index: check_varnish.c
 ===================================================================
 --- check_varnish.c     (revision 4936)
 +++ check_varnish.c     (working copy)
 @@ -31,6 +31,7 @@
   */

  #include <inttypes.h>
 +#include <locale.h>
  #include <limits.h>
  #include <stdint.h>
  #include <stdio.h>
 @@ -200,7 +201,8 @@
                 printf("Unknown parameter '%s'\n", param);

         status = check_thresholds(value);
 -       printf("VARNISH %s: %s|%s=%jd\n", status_text[status], info,
 param, value);
 +       setlocale(LC_ALL, "");
 +       printf("VARNISH %s: %s (%'jd)|%s=%jd\n", status_text[status],
 info, value, param, value);
         exit(status);
  }

 }}}

 Cheers

 Sascha

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



From varnish-bugs at varnish-cache.org  Mon Jun 21 13:56:00 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Jun 2010 13:56:00 -0000
Subject: [Varnish] #710: check_varnish.c fails to compile against
	varnish 2.1.x
In-Reply-To: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org>
References: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org>
Message-ID: <052.538351df66d866fdac4393d381d76898@varnish-cache.org>

#710: check_varnish.c fails to compile against varnish 2.1.x
--------------------+-------------------------------------------------------
 Reporter:  netmax  |        Type:  defect
   Status:  new     |    Priority:  normal
Milestone:          |   Component:  nagios
  Version:  2.1.2   |    Severity:  normal
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by sascha):

 Marc,

 right you are, opened #727 about the output formatting.

 Cheers

 Sascha

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/710#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 21 14:27:06 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 21 Jun 2010 14:27:06 -0000
Subject: [Varnish] #720: esi confuses varnishncsa
In-Reply-To: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org>
References: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org>
Message-ID: <050.55867f36d8858e27cafbf4f47c4eee40@varnish-cache.org>

#720: esi confuses varnishncsa
-------------------+--------------------------------------------------------
 Reporter:  knan   |        Type:  defect     
   Status:  new    |    Priority:  normal     
Milestone:         |   Component:  varnishncsa
  Version:  2.1.0  |    Severity:  normal     
 Keywords:         |  
-------------------+--------------------------------------------------------

Comment(by knan):

 Also causes lines like:

 {{{ - - - [01/Jun/2010:14:00:02 +0000] "(null) (null) (null)" (null) - "-"
 "-" }}}

 in the logs. (For the esi subrequests.)

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/720#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 07:15:26 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 07:15:26 -0000
Subject: [Varnish] #709: After SessionClose c EOF there is a second
	ReqEnd c 0
In-Reply-To: <042.16a2342d3909d7941dfeb29bf1a0df6b@varnish-cache.org>
References: <042.16a2342d3909d7941dfeb29bf1a0df6b@varnish-cache.org>
Message-ID: <051.559b67285d71d2573bbc6900c9ad3131@varnish-cache.org>

#709: After SessionClose c EOF there is a second  ReqEnd       c 0
----------------------+-----------------------------------------------------
 Reporter:  jdzst     |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:        
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 (In [4980]) Emit Length for client side right before ReqEnd, to summarize
 ESI
 transactions correctly.

 Only Emmit Length and ReqEnd if we have an XID.

 Fixes: #709
 Fixes: #720

-- 
Ticket URL: </ticket/709#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 07:15:26 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 07:15:26 -0000
Subject: [Varnish] #720: esi confuses varnishncsa
In-Reply-To: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org>
References: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org>
Message-ID: <050.cef8fc3cdee674e5aff3ac604fcf4770@varnish-cache.org>

#720: esi confuses varnishncsa
---------------------+------------------------------------------------------
  Reporter:  knan    |        Type:  defect     
    Status:  closed  |    Priority:  normal     
 Milestone:          |   Component:  varnishncsa
   Version:  2.1.0   |    Severity:  normal     
Resolution:  fixed   |    Keywords:             
---------------------+------------------------------------------------------
Changes (by phk):

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


Comment:

 (In [4980]) Emit Length for client side right before ReqEnd, to summarize
 ESI
 transactions correctly.

 Only Emmit Length and ReqEnd if we have an XID.

 Fixes: #709
 Fixes: #720

-- 
Ticket URL: </ticket/720#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 07:23:33 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 07:23:33 -0000
Subject: [Varnish] #718: obj.hits or beresp.hits not available in
	vcl_deliver
In-Reply-To: <045.5748da70e8b1ff16bbfb8a7df7047260@varnish-cache.org>
References: <045.5748da70e8b1ff16bbfb8a7df7047260@varnish-cache.org>
Message-ID: <054.0262c6a887dab32b3c5781435fee1a18@varnish-cache.org>

#718: obj.hits or beresp.hits not available in vcl_deliver
----------------------+-----------------------------------------------------
 Reporter:  grosser2  |        Owner:  phk       
     Type:  defect    |       Status:  closed    
 Priority:  normal    |    Milestone:            
Component:  varnishd  |      Version:  2.1.2     
 Severity:  normal    |   Resolution:  worksforme
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 obj.hits is available in vcl_deliver{} and vcl_hits{}

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/718#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 07:24:43 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 07:24:43 -0000
Subject: [Varnish] #717: obj.hash and beresp.hash do not work inside
	vcl_deliver
In-Reply-To: <045.35ab9c6f4e4ddedcbb91cc6911a9f3a5@varnish-cache.org>
References: <045.35ab9c6f4e4ddedcbb91cc6911a9f3a5@varnish-cache.org>
Message-ID: <054.e02ce7728fdbebcb7d6b0c432f79fc5b@varnish-cache.org>

#717: obj.hash and beresp.hash do not work inside vcl_deliver
----------------------+-----------------------------------------------------
 Reporter:  grosser2  |        Owner:  phk       
     Type:  defect    |       Status:  closed    
 Priority:  normal    |    Milestone:            
Component:  varnishd  |      Version:  2.1.2     
 Severity:  normal    |   Resolution:  worksforme
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 The hash string is no longer available for reading, it was a waste of
 storage.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/717#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 07:25:55 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 07:25:55 -0000
Subject: [Varnish] #714: VRT_l_* calls cause memory exhaustion under
	high load
In-Reply-To: <044.a9de153ab7995312e07d85a04d71434e@varnish-cache.org>
References: <044.a9de153ab7995312e07d85a04d71434e@varnish-cache.org>
Message-ID: <053.29b32227c6656ccf6b4f78bbd17cd82c@varnish-cache.org>

#714: VRT_l_* calls cause memory exhaustion under high load
-------------------------+--------------------------------------------------
  Reporter:  ferivar     |        Type:  defect
    Status:  closed      |    Priority:  normal
 Milestone:              |   Component:  build 
   Version:  2.1.2       |    Severity:  normal
Resolution:  worksforme  |    Keywords:        
-------------------------+--------------------------------------------------
Changes (by phk):

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


Comment:

 It does not when I try it.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/714#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 07:37:23 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 07:37:23 -0000
Subject: [Varnish] #681: problems using regular expressions with varnishlog
In-Reply-To: <050.b94feb298b633fc0e0c4e91b0d52be3f@varnish-cache.org>
References: <050.b94feb298b633fc0e0c4e91b0d52be3f@varnish-cache.org>
Message-ID: <059.33076f1b44cb73877f7b77e1931208a7@varnish-cache.org>

#681: problems using regular expressions with varnishlog
--------------------------------------------+-------------------------------
 Reporter:  danielpicolli                   |        Owner:  phk                
     Type:  defect                          |       Status:  closed             
 Priority:  normal                          |    Milestone:  Varnish 2.1 release
Component:  varnishlog                      |      Version:                     
 Severity:  critical                        |   Resolution:  fixed              
 Keywords:  regular expressions varnishlog  |  
--------------------------------------------+-------------------------------
Changes (by phk):

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


Comment:

 (In [4981]) Typo in -X matching in varnishapi

 Fixes: #681

-- 
Ticket URL: </ticket/681#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 07:47:15 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 07:47:15 -0000
Subject: [Varnish] #695: Varnish trunk 4516 segmentation fault in FreeBSD
In-Reply-To: <043.0c8af4e7ee3cb80191b04279eace67a7@varnish-cache.org>
References: <043.0c8af4e7ee3cb80191b04279eace67a7@varnish-cache.org>
Message-ID: <052.400d8748236b08db21d08000106e38ac@varnish-cache.org>

#695: Varnish trunk 4516 segmentation fault in FreeBSD
----------------------+-----------------------------------------------------
 Reporter:  anders    |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  trunk 
 Severity:  normal    |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 This was fixed in r4547 in another context.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/695#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 08:53:47 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 08:53:47 -0000
Subject: [Varnish] #717: obj.hash and beresp.hash do not work inside
	vcl_deliver
In-Reply-To: <045.35ab9c6f4e4ddedcbb91cc6911a9f3a5@varnish-cache.org>
References: <045.35ab9c6f4e4ddedcbb91cc6911a9f3a5@varnish-cache.org>
Message-ID: <054.174fceabdf7e3c927b0e4510d39d23e8@varnish-cache.org>

#717: obj.hash and beresp.hash do not work inside vcl_deliver
----------------------+-----------------------------------------------------
 Reporter:  grosser2  |        Owner:  phk       
     Type:  defect    |       Status:  closed    
 Priority:  normal    |    Milestone:            
Component:  varnishd  |      Version:  2.1.2     
 Severity:  normal    |   Resolution:  worksforme
 Keywords:            |  
----------------------+-----------------------------------------------------

Comment(by grosser2):

 how can it be "worksforme" if it does not work...

 Is there another way to get this hash? We are using it to test if our
 varnish hashing code works correctly.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/717#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 09:24:22 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 09:24:22 -0000
Subject: [Varnish] #717: obj.hash and beresp.hash do not work inside
	vcl_deliver
In-Reply-To: <045.35ab9c6f4e4ddedcbb91cc6911a9f3a5@varnish-cache.org>
References: <045.35ab9c6f4e4ddedcbb91cc6911a9f3a5@varnish-cache.org>
Message-ID: <054.a2e03c4fe447d8a21700c0a07cb66da0@varnish-cache.org>

#717: obj.hash and beresp.hash do not work inside vcl_deliver
----------------------+-----------------------------------------------------
 Reporter:  grosser2  |        Owner:  phk       
     Type:  defect    |       Status:  closed    
 Priority:  normal    |    Milestone:            
Component:  varnishd  |      Version:  2.1.2     
 Severity:  normal    |   Resolution:  worksforme
 Keywords:            |  
----------------------+-----------------------------------------------------

Comment(by phk):

 You can log the components used to build the hash to the shmlog, set the
 parameter log_hashstring

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/717#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 19:28:26 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 19:28:26 -0000
Subject: [Varnish] #728: Assert error in vrt_selecthttp
Message-ID: <044.9cc89873e1a79840033b81198c97a2c2@varnish-cache.org>

#728: Assert error in vrt_selecthttp
----------------------+-----------------------------------------------------
 Reporter:  utdrmac   |       Owner:  phk                 
     Type:  defect    |      Status:  new                 
 Priority:  highest   |   Milestone:  Varnish 2.1 release 
Component:  varnishd  |     Version:  2.1.2               
 Severity:  blocker   |    Keywords:  assert, error, crash
----------------------+-----------------------------------------------------
 Using latest 2.1.2 RPMs on RHEL 5.5

 Using the default "default.vcl" and we get this error upon attempts:

 varnishd[4528]: Child (4529) Panic message: Assert error in
 vrt_selecthttp(), cache_vrt.c line 118:   Condition((sp->obj) != NULL) not
 true. thread = (cache-worker) ident =
 Linux,2.6.18-194.el5,x86_64,-smalloc,-hclassic,epoll

 Backtrace:

 0x422616: /usr/sbin/varnishd [0x422616]
 0x42a069: /usr/sbin/varnishd [0x42a069]
 0x42bd57: /usr/sbin/varnishd(VRT_GetHdr+0x57) [0x42bd57]
 0x2aaaaef01444: ./vcl.1P9zoqAU.so [0x2aaaaef01444]
 0x427693: /usr/sbin/varnishd(VCL_recv_method+0x43) [0x427693]
 0x414097: /usr/sbin/varnishd(CNT_Session+0x5b7) [0x414097]
 0x424a68: /usr/sbin/varnishd [0x424a68]
 0x423d4d: /usr/sbin/varnishd [0x423d4d]
 0x3201a0673d: /lib64/libpthread.so.0 [0x3201a0673d]
 0x3200ad3d1d: /lib64/libc.so.6(clone+0x6d) [0x3200ad3d1d] sp =
 0x2aaaaf203008 {   fd = 12, id = 12, xid = 338362043,   client =
 10.155.255.0:7845,   step = STP_RECV,   handling = deliver,   restarts =
 0, esis = 0   ws = 0x2aaaaf203078 {      id = "sess",     {s,f,r,e} =
 {0x2aaaaf203c90,+464,(nil),+6553

 Tried to roll back to 2.1.1 but that just segfaults right away with no
 output similar to above. Going to rollback to 2.1 here in a bit and just
 keep rolling back until it works again.

 -Matthew

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



From varnish-bugs at varnish-cache.org  Tue Jun 22 19:31:58 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 19:31:58 -0000
Subject: [Varnish] #728: Assert error in vrt_selecthttp
In-Reply-To: <044.9cc89873e1a79840033b81198c97a2c2@varnish-cache.org>
References: <044.9cc89873e1a79840033b81198c97a2c2@varnish-cache.org>
Message-ID: <053.e8df07627c8066afb9981a103c2ffa87@varnish-cache.org>

#728: Assert error in vrt_selecthttp
----------------------+-----------------------------------------------------
 Reporter:  utdrmac   |       Owner:  phk                 
     Type:  defect    |      Status:  new                 
 Priority:  highest   |   Milestone:  Varnish 2.1 release 
Component:  varnishd  |     Version:  2.1.2               
 Severity:  blocker   |    Keywords:  assert, error, crash
----------------------+-----------------------------------------------------

Comment(by utdrmac):

 rpm -qa | grep libevent
 libevent-devel-1.4.13-1
 libevent-1.4.13-1

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/728#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 22 20:14:40 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 22 Jun 2010 20:14:40 -0000
Subject: [Varnish] #728: Assert error in vrt_selecthttp
In-Reply-To: <044.9cc89873e1a79840033b81198c97a2c2@varnish-cache.org>
References: <044.9cc89873e1a79840033b81198c97a2c2@varnish-cache.org>
Message-ID: <053.3f00218843abe49eec94688f095a133f@varnish-cache.org>

#728: Assert error in vrt_selecthttp
----------------------+-----------------------------------------------------
 Reporter:  utdrmac   |       Owner:  phk                 
     Type:  defect    |      Status:  new                 
 Priority:  highest   |   Milestone:  Varnish 2.1 release 
Component:  varnishd  |     Version:  2.1.2               
 Severity:  blocker   |    Keywords:  assert, error, crash
----------------------+-----------------------------------------------------

Comment(by utdrmac):

 had to rollback to 2.0.6 and create our own RPMs

 -Matthew

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/728#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Jun 23 12:23:23 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 23 Jun 2010 12:23:23 -0000
Subject: [Varnish] #729: Varnish loosing all its cache content
Message-ID: <044.9f09dc9e220f2e64dc817db6d03c36d1@varnish-cache.org>

#729: Varnish loosing all its cache content
----------------------+-----------------------------------------------------
 Reporter:  fabrice   |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  high      |   Milestone:     
Component:  varnishd  |     Version:  2.0
 Severity:  critical  |    Keywords:     
----------------------+-----------------------------------------------------
 We are using Varnish (on 2 servers) to cache our images coming from Apache
 (2 servers as well). The problem we have is that couples of times a day,
 Varnish looses all it cache content.
 It is quite random and luckily, the 2 Varnish servers did not do that yet
 at the same time (which would kill our Apache backend). In any case,
 varnishstat shows about 90% hit ratio and all of the sudden drops to 0 and
 builds back its cache.

 The only thing in the logs that looks a bit strange are messages like
 this:
 Jun 23 11:19:15 cache1 varnishd[17821]: Child (5617) not responding to
 ping, killing it.
 Jun 23 11:19:39 cache1 varnishd[17821]: Child (5617) died signal=3

 But even if those messages are strange (or maybe not) they do not relate
 in time with the issue we are having.

 The daemon settings are:
 -f /opt/blocket/conf/varnish.vcl -s malloc,63G -u varnish -g varnish -p
 thread_pools 4 -p thread_pool_min 32 -p listen_depth 4096 -p lru_interval
 600 -h classic,400009 -p obj_workspace 8192 -p log_hashstring off -p
 shm_workspace 16384 -p srcaddr_ttl 0 -p ping_interval 2 -p default_grace
 3600 -p pipe_timeout 10 -p sess_timeout 5 -p send_timeout 10

 Our VCL is attached (with some offuscated data)

 Maybe this is something very stupid on our side but any idea is very
 welcome to help us here.
 Thanks,
 Fabrice.

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



From varnish-bugs at varnish-cache.org  Wed Jun 23 13:35:49 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 23 Jun 2010 13:35:49 -0000
Subject: [Varnish] #720: esi confuses varnishncsa
In-Reply-To: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org>
References: <041.c09e8a59b3e10283db71d953dea38190@varnish-cache.org>
Message-ID: <050.9aff7a6a004093b2d2bbfa05cf5d8fc2@varnish-cache.org>

#720: esi confuses varnishncsa
---------------------+------------------------------------------------------
  Reporter:  knan    |        Type:  defect     
    Status:  closed  |    Priority:  normal     
 Milestone:          |   Component:  varnishncsa
   Version:  2.1.0   |    Severity:  normal     
Resolution:  fixed   |    Keywords:             
---------------------+------------------------------------------------------

Comment(by knan):

 r4980 still buggy, emitted client Length is from document start to the end
 of the first included esi segment, not the complete delivered length.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/720#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Jun 24 23:10:40 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 24 Jun 2010 23:10:40 -0000
Subject: [Varnish] #545: synthetic screws national characters
In-Reply-To: <041.ca57a3dedbc1a621c14a034da6d01e9d@varnish-cache.org>
References: <041.ca57a3dedbc1a621c14a034da6d01e9d@varnish-cache.org>
Message-ID: <050.e6a3dd0146c68bccc2d182390da53015@varnish-cache.org>

#545: synthetic screws national characters
----------------------+-----------------------------------------------------
 Reporter:  kolo      |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:     
Component:  varnishd  |     Version:  2.0
 Severity:  normal    |    Keywords:     
----------------------+-----------------------------------------------------

Comment(by josh_k):

 Looks like the issue is improper UTF-8 encoding. It's not just entities,
 but alt charsets are also mangled in the same way. E.g.

 <h1>???????????????</h1>

 becomes

 <h1>?77777743?77777602?77777665....</h1>

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/545#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Jun 24 23:19:28 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 24 Jun 2010 23:19:28 -0000
Subject: [Varnish] #545: synthetic screws national characters
In-Reply-To: <041.ca57a3dedbc1a621c14a034da6d01e9d@varnish-cache.org>
References: <041.ca57a3dedbc1a621c14a034da6d01e9d@varnish-cache.org>
Message-ID: <050.41d226649db7d20b4257cf9a5b8e9e66@varnish-cache.org>

#545: synthetic screws national characters
----------------------+-----------------------------------------------------
 Reporter:  kolo      |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:     
Component:  varnishd  |     Version:  2.0
 Severity:  normal    |    Keywords:     
----------------------+-----------------------------------------------------

Comment(by josh_k):

 FWIW the workaround is to encode everything. This PHP function worked for
 my crazy multilingual "down" page:

 http://www.php.net/manual/en/function.htmlentities.php#96648

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/545#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Jun 25 11:19:29 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 25 Jun 2010 11:19:29 -0000
Subject: [Varnish] #711: 64bit Catch 22 on Solaris (gcc _builtin_xxx
	functions)
In-Reply-To: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>
References: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>
Message-ID: <050.17a53fe21a27d5603d9ff0334c093189@varnish-cache.org>

#711: 64bit Catch 22 on Solaris (gcc _builtin_xxx functions)
--------------------------------+-------------------------------------------
  Reporter:  tinl               |        Type:  defect                                              
    Status:  reopened           |    Priority:  normal                                              
 Milestone:  After Varnish 2.1  |   Component:  build                                               
   Version:  trunk              |    Severity:  major                                               
Resolution:                     |    Keywords:  __builtin_isfinite, link error, 64-bit, solaris, gcc
--------------------------------+-------------------------------------------

Comment(by jdzst):

 I had the same issue in Solaris 10 with GCC compiler.

 After some investigations, I saw that was a problem with GCC version 3.4.3
 that expected some diferent system files in Solaris:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933

 I resolved the problem installing GCC versi?n 3.4.6 packages and all its
 dependences:
   * Intel: http://www.sunfreeware.com/programlistintel10.html#gcc34
   * Sparc: http://www.sunfreeware.com/programlistsparc10.html#gcc34

 The new version works OK.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/711#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 01:53:42 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 01:53:42 -0000
Subject: [Varnish] #729: Varnish loosing all its cache content
In-Reply-To: <044.9f09dc9e220f2e64dc817db6d03c36d1@varnish-cache.org>
References: <044.9f09dc9e220f2e64dc817db6d03c36d1@varnish-cache.org>
Message-ID: <053.3cc780744494352cd83027d07915a8e7@varnish-cache.org>

#729: Varnish loosing all its cache content
----------------------+-----------------------------------------------------
 Reporter:  fabrice   |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  high      |   Milestone:     
Component:  varnishd  |     Version:  2.0
 Severity:  critical  |    Keywords:     
----------------------+-----------------------------------------------------

Comment(by chrismsnz):

 Hi,

 I'd just like to add that we're seeing this a couple of times a day on our
 systems as well...

 {{{
 syslog:Jun 28 13:33:42 abu varnishd[1145]: Child (25134) not responding to
 ping, killing it.
 syslog:Jun 28 13:33:52 abu varnishd[1145]: last message repeated 2 times
 syslog:Jun 28 13:33:52 abu varnishd[1145]: Child (25134) died signal=3
 syslog:Jun 28 13:33:52 abu varnishd[1145]: Child cleanup complete
 syslog:Jun 28 13:33:52 abu varnishd[1145]: child (26261) Started
 syslog:Jun 28 13:33:52 abu varnishd[1145]: Child (26261) said Closed fds:
 4 5 6 7 11 12 14 15
 syslog:Jun 28 13:33:52 abu varnishd[1145]: Child (26261) said Child starts
 syslog:Jun 28 13:33:52 abu varnishd[1145]: Child (26261) said managed to
 mmap 2147479552 bytes of 2147479552
 }}}

 Here are the daemon settings for us:
 {{{
 /usr/sbin/varnishd -P /var/run/varnishd.pid -a :80 -f
 /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1500,120 -S
 /etc/varnish/secret -s file,/var/lib/varnish/abu/varnish_storage.bin,2G
 }}}

 We're running Varnish 2.1.0 on Ubuntu LTS 10.04 32-bit (older servers,
 hence small cache size).

 Just let me know if there's anything further you need from us

 Cheers,
 Chris.

-- 
Ticket URL: <http://varnish-cache.org/ticket/729#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 07:40:49 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 07:40:49 -0000
Subject: [Varnish] #729: Varnish loosing all its cache content
In-Reply-To: <044.9f09dc9e220f2e64dc817db6d03c36d1@varnish-cache.org>
References: <044.9f09dc9e220f2e64dc817db6d03c36d1@varnish-cache.org>
Message-ID: <053.246897ce8cd858f9c39d49bf081fc5db@varnish-cache.org>

#729: Varnish loosing all its cache content
----------------------+-----------------------------------------------------
 Reporter:  fabrice   |        Owner:  phk       
     Type:  defect    |       Status:  closed    
 Priority:  high      |    Milestone:            
Component:  varnishd  |      Version:  2.0       
 Severity:  critical  |   Resolution:  worksforme
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 Hi Chris,

 Those messages (not responding to ping, killing it.) are indeed relevant:
 They tell that the master process could not get a CLI reply out of the
 child inside the timeout, and therefore have decided that it is stuck,
 killed it, and started a fresh copy.

 This usually happens because your varnish child process gets stuck in
 disk-I/O and/or paging activity.

 If the responsetime is otherwise OK for you (use varnishhist to monitor
 it) you can increase the parameter "cli_timeout" to make the master
 process more patient.

 Poul-Henning

-- 
Ticket URL: <http://varnish-cache.org/ticket/729#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 07:46:36 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 07:46:36 -0000
Subject: [Varnish] #711: 64bit Catch 22 on Solaris (gcc _builtin_xxx
	functions)
In-Reply-To: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>
References: <041.6beb21c62b3cd4e2769c2670e45892bd@varnish-cache.org>
Message-ID: <050.6fc90ed4ea5b9d60c93836c747c205be@varnish-cache.org>

#711: 64bit Catch 22 on Solaris (gcc _builtin_xxx functions)
--------------------------------+-------------------------------------------
  Reporter:  tinl               |        Type:  defect                                              
    Status:  closed             |    Priority:  normal                                              
 Milestone:  After Varnish 2.1  |   Component:  build                                               
   Version:  trunk              |    Severity:  major                                               
Resolution:  invalid            |    Keywords:  __builtin_isfinite, link error, 64-bit, solaris, gcc
--------------------------------+-------------------------------------------
Changes (by phk):

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


Comment:

 Thanks a lot!

 That was the kind of issue I would not haven gotten around to fix in
 finite time myself.

 I have added an entry in our TroubleLog.

-- 
Ticket URL: <http://varnish-cache.org/ticket/711#comment:5>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 08:01:44 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 08:01:44 -0000
Subject: [Varnish] #729: Varnish loosing all its cache content
In-Reply-To: <044.9f09dc9e220f2e64dc817db6d03c36d1@varnish-cache.org>
References: <044.9f09dc9e220f2e64dc817db6d03c36d1@varnish-cache.org>
Message-ID: <053.ee4c1ba85dc81025cb7fd415912cf11f@varnish-cache.org>

#729: Varnish loosing all its cache content
----------------------+-----------------------------------------------------
 Reporter:  fabrice   |        Owner:  phk       
     Type:  defect    |       Status:  closed    
 Priority:  high      |    Milestone:            
Component:  varnishd  |      Version:  2.0       
 Severity:  critical  |   Resolution:  worksforme
 Keywords:            |  
----------------------+-----------------------------------------------------

Comment(by fabrice):

 Hi Poul-Henning,
 I will increase cli_timeout to 10s. I understand that in Varnish before
 2.1.0, cli_timeout is set to 3s. Since we are running 2.0.6, I will set it
 to 10s as in 2.1.0 and see if that fixes this. If not, what else should we
 look at (I do not see any IO wait or high CPU load)?

 Thanks,
 Fabrice.

-- 
Ticket URL: <http://varnish-cache.org/ticket/729#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 11:30:37 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 11:30:37 -0000
Subject: [Varnish] #728: Assert error in vrt_selecthttp
In-Reply-To: <044.9cc89873e1a79840033b81198c97a2c2@varnish-cache.org>
References: <044.9cc89873e1a79840033b81198c97a2c2@varnish-cache.org>
Message-ID: <053.ee5de579969f83022582d91e2bb12bfb@varnish-cache.org>

#728: Assert error in vrt_selecthttp
----------------------+-----------------------------------------------------
 Reporter:  utdrmac   |       Owner:  phk                 
     Type:  defect    |      Status:  new                 
 Priority:  highest   |   Milestone:  Varnish 2.1 release 
Component:  varnishd  |     Version:  2.1.2               
 Severity:  blocker   |    Keywords:  assert, error, crash
----------------------+-----------------------------------------------------
Description changed by phk:

Old description:

> Using latest 2.1.2 RPMs on RHEL 5.5
>
> Using the default "default.vcl" and we get this error upon attempts:
>
> varnishd[4528]: Child (4529) Panic message: Assert error in
> vrt_selecthttp(), cache_vrt.c line 118:   Condition((sp->obj) != NULL)
> not true. thread = (cache-worker) ident =
> Linux,2.6.18-194.el5,x86_64,-smalloc,-hclassic,epoll
>
> Backtrace:
>
> 0x422616: /usr/sbin/varnishd [0x422616]
> 0x42a069: /usr/sbin/varnishd [0x42a069]
> 0x42bd57: /usr/sbin/varnishd(VRT_GetHdr+0x57) [0x42bd57]
> 0x2aaaaef01444: ./vcl.1P9zoqAU.so [0x2aaaaef01444]
> 0x427693: /usr/sbin/varnishd(VCL_recv_method+0x43) [0x427693]
> 0x414097: /usr/sbin/varnishd(CNT_Session+0x5b7) [0x414097]
> 0x424a68: /usr/sbin/varnishd [0x424a68]
> 0x423d4d: /usr/sbin/varnishd [0x423d4d]
> 0x3201a0673d: /lib64/libpthread.so.0 [0x3201a0673d]
> 0x3200ad3d1d: /lib64/libc.so.6(clone+0x6d) [0x3200ad3d1d] sp =
> 0x2aaaaf203008 {   fd = 12, id = 12, xid = 338362043,   client =
> 10.155.255.0:7845,   step = STP_RECV,   handling = deliver,   restarts =
> 0, esis = 0   ws = 0x2aaaaf203078 {      id = "sess",     {s,f,r,e} =
> {0x2aaaaf203c90,+464,(nil),+6553
>
> Tried to roll back to 2.1.1 but that just segfaults right away with no
> output similar to above. Going to rollback to 2.1 here in a bit and just
> keep rolling back until it works again.
>
> -Matthew

New description:

 Using latest 2.1.2 RPMs on RHEL 5.5

 Using the default "default.vcl" and we get this error upon attempts:

 {{{
 varnishd[4528]: Child (4529) Panic message: Assert error in
 vrt_selecthttp(), cache_vrt.c line 118:
    Condition((sp->obj) != NULL) not true.
    thread = (cache-worker)
    ident = Linux,2.6.18-194.el5,x86_64,-smalloc,-hclassic,epoll

 Backtrace:

 0x422616: /usr/sbin/varnishd [0x422616]
 0x42a069: /usr/sbin/varnishd [0x42a069]
 0x42bd57: /usr/sbin/varnishd(VRT_GetHdr+0x57) [0x42bd57]
 0x2aaaaef01444: ./vcl.1P9zoqAU.so [0x2aaaaef01444]
 0x427693: /usr/sbin/varnishd(VCL_recv_method+0x43) [0x427693]
 0x414097: /usr/sbin/varnishd(CNT_Session+0x5b7) [0x414097]
 0x424a68: /usr/sbin/varnishd [0x424a68]
 0x423d4d: /usr/sbin/varnishd [0x423d4d]
 0x3201a0673d: /lib64/libpthread.so.0 [0x3201a0673d]
 0x3200ad3d1d: /lib64/libc.so.6(clone+0x6d) [0x3200ad3d1d] sp =
 0x2aaaaf203008 {   fd = 12, id = 12, xid = 338362043,   client =
 10.155.255.0:7845,   step = STP_RECV,   handling = deliver,   restarts =
 0, esis = 0   ws = 0x2aaaaf203078 {      id = "sess",     {s,f,r,e} =
 {0x2aaaaf203c90,+464,(nil),+6553
 }}}
 Tried to roll back to 2.1.1 but that just segfaults right away with no
 output similar to above. Going to rollback to 2.1 here in a bit and just
 keep rolling back until it works again.

 -Matthew

--

-- 
Ticket URL: <http://varnish-cache.org/ticket/728#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 11:38:22 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 11:38:22 -0000
Subject: [Varnish] #726: Assert error in http_SetH(), cache_http.c line 595
In-Reply-To: <043.c8576d811db370bb2c2909c6b71dc81a@varnish-cache.org>
References: <043.c8576d811db370bb2c2909c6b71dc81a@varnish-cache.org>
Message-ID: <052.1439e2c5ce8cc9673efd54cb8898490a@varnish-cache.org>

#726: Assert error in http_SetH(), cache_http.c line 595
----------------------+-----------------------------------------------------
 Reporter:  anakin    |        Owner:  phk                
     Type:  defect    |       Status:  closed             
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  2.1.0              
 Severity:  normal    |   Resolution:  fixed              
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 It is a bug that you can set obj.http* in vcl_hit, please don't do that.

 This is fixed in -trunk.

-- 
Ticket URL: <http://varnish-cache.org/ticket/726#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 11:40:46 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 11:40:46 -0000
Subject: [Varnish] #728: Assert error in vrt_selecthttp
In-Reply-To: <044.9cc89873e1a79840033b81198c97a2c2@varnish-cache.org>
References: <044.9cc89873e1a79840033b81198c97a2c2@varnish-cache.org>
Message-ID: <053.508dc2a6606248ce0f87349213ad6977@varnish-cache.org>

#728: Assert error in vrt_selecthttp
----------------------------------+-----------------------------------------
 Reporter:  utdrmac               |        Owner:  phk                
     Type:  defect                |       Status:  closed             
 Priority:  highest               |    Milestone:  Varnish 2.1 release
Component:  varnishd              |      Version:  2.1.2              
 Severity:  blocker               |   Resolution:  worksforme         
 Keywords:  assert, error, crash  |  
----------------------------------+-----------------------------------------
Changes (by phk):

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


Comment:

 I can make no heads or tails of that backtrace under the assumption that
 you are indeed using a unchanged default.vcl.

 I have no idea how you got handling=deliver in STP_recv, that sounds like
 buggy inline-C code ?

-- 
Ticket URL: <http://varnish-cache.org/ticket/728#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 11:47:27 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 11:47:27 -0000
Subject: [Varnish] #724: Panic message: Assert error in VRT_synth_page(), 
	cache_vrt.c line 918
In-Reply-To: <045.1cc93d7e2d7a906a7cf5bf88afb252fb@varnish-cache.org>
References: <045.1cc93d7e2d7a906a7cf5bf88afb252fb@varnish-cache.org>
Message-ID: <054.b2e76ae685462e78fe8ab9ad9f606695@varnish-cache.org>

#724: Panic message: Assert error in VRT_synth_page(), cache_vrt.c line 918
----------------------+-----------------------------------------------------
 Reporter:  tseliger  |        Owner:  phk       
     Type:  defect    |       Status:  closed    
 Priority:  normal    |    Milestone:            
Component:  varnishd  |      Version:  2.1.2     
 Severity:  normal    |   Resolution:  worksforme
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 I'm guessing you are using "synth {...}" in vcl_fetch{}, that's not legal,
 you can only use that in vcl_error{}.

 (Hoping to make synth{} legal everywhere in 3.0, but not there yet)

-- 
Ticket URL: <http://varnish-cache.org/ticket/724#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 11:49:13 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 11:49:13 -0000
Subject: [Varnish] #725: Assert error in _vsb_assert_integrity(),
	vsb.c line 84
In-Reply-To: <043.04a0ac6567238cab3f466b29de0abb3c@varnish-cache.org>
References: <043.04a0ac6567238cab3f466b29de0abb3c@varnish-cache.org>
Message-ID: <052.69e81755741fb6ec87af1bb635b32675@varnish-cache.org>

#725: Assert error in _vsb_assert_integrity(), vsb.c line 84
----------------------+-----------------------------------------------------
 Reporter:  anakin    |        Owner:  phk                
     Type:  defect    |       Status:  closed             
 Priority:  normal    |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  2.1.0              
 Severity:  normal    |   Resolution:  fixed              
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 It looks like you are using synth{} in vcl_deliver{}, that is not
 supported, please do that only in vcl_error{}.

-- 
Ticket URL: <http://varnish-cache.org/ticket/725#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 11:53:20 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 11:53:20 -0000
Subject: [Varnish] #723: Incorrect SVN checkout URL in documentation
In-Reply-To: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>
References: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>
Message-ID: <054.54a8d641f78d56f10618ace821c7bda2@varnish-cache.org>

#723: Incorrect SVN checkout URL in documentation
---------------------------+------------------------------------------------
 Reporter:  walraven       |       Owner:  perbu
     Type:  documentation  |      Status:  new  
 Priority:  normal         |   Milestone:       
Component:  build          |     Version:  trunk
 Severity:  normal         |    Keywords:       
---------------------------+------------------------------------------------
Changes (by tfheen):

  * owner:  => perbu


Comment:

 I'm guessing this is from http://varnish-
 cache.org/docs/installation/install/ ; Per, care to fix this?

-- 
Ticket URL: <http://varnish-cache.org/ticket/723#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 11:53:36 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 11:53:36 -0000
Subject: [Varnish] #723: Incorrect SVN checkout URL in documentation
In-Reply-To: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>
References: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>
Message-ID: <054.eb5c1254053d34ffacc0dca9b39634cb@varnish-cache.org>

#723: Incorrect SVN checkout URL in documentation
---------------------------+------------------------------------------------
 Reporter:  walraven       |        Owner:  perbu 
     Type:  documentation  |       Status:  closed
 Priority:  normal         |    Milestone:        
Component:  build          |      Version:  trunk 
 Severity:  normal         |   Resolution:  fixed 
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by phk):

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


Comment:

 (In [4988]) Fix SVN urls.

 Fixes: #723

-- 
Ticket URL: </ticket/723#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 11:55:17 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 11:55:17 -0000
Subject: [Varnish] #723: Incorrect SVN checkout URL in documentation
In-Reply-To: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>
References: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>
Message-ID: <054.bcb8a30072322053873ca5e46b692d60@varnish-cache.org>

#723: Incorrect SVN checkout URL in documentation
---------------------------+------------------------------------------------
 Reporter:  walraven       |        Owner:  perbu   
     Type:  documentation  |       Status:  reopened
 Priority:  normal         |    Milestone:          
Component:  build          |      Version:  trunk   
 Severity:  normal         |   Resolution:          
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by phk):

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


Comment:

 Oops, didn't mean to close this.

 Per: check other references (wiki ?)

-- 
Ticket URL: <http://varnish-cache.org/ticket/723#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 11:55:34 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 11:55:34 -0000
Subject: [Varnish] #723: Incorrect SVN checkout URL in documentation
In-Reply-To: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>
References: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>
Message-ID: <054.4d95fa81c787d3f48f9fdc452470d95c@varnish-cache.org>

#723: Incorrect SVN checkout URL in documentation
---------------------------+------------------------------------------------
 Reporter:  walraven       |        Owner:  perbu
     Type:  documentation  |       Status:  new  
 Priority:  normal         |    Milestone:       
Component:  build          |      Version:  trunk
 Severity:  normal         |   Resolution:       
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by phk):

  * status:  reopened => new


-- 
Ticket URL: <http://varnish-cache.org/ticket/723#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Jun 28 11:57:28 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 28 Jun 2010 11:57:28 -0000
Subject: [Varnish] #715: CLI communication error (hdr) on vcl.discard
In-Reply-To: <044.1375c3ee53ef8b1f435bb3ec5c0d8820@varnish-cache.org>
References: <044.1375c3ee53ef8b1f435bb3ec5c0d8820@varnish-cache.org>
Message-ID: <053.efd58ab79f16e36885bd620d8f3dd28a@varnish-cache.org>

#715: CLI communication error (hdr) on vcl.discard
----------------------+-----------------------------------------------------
  Reporter:  Estartu  |        Type:  defect
    Status:  closed   |    Priority:  normal
 Milestone:           |   Component:  build 
   Version:  2.1.2    |    Severity:  normal
Resolution:  fixed    |    Keywords:        
----------------------+-----------------------------------------------------
Changes (by phk):

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


Comment:

 Fixed under #722, see that.

 Will be fixed in 2.1.3

-- 
Ticket URL: <http://varnish-cache.org/ticket/715#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Jun 29 09:26:52 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 29 Jun 2010 09:26:52 -0000
Subject: [Varnish] #723: Incorrect SVN checkout URL in documentation
In-Reply-To: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>
References: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org>
Message-ID: <054.2a171e3653262428af7928c5168b4813@varnish-cache.org>

#723: Incorrect SVN checkout URL in documentation
---------------------------+------------------------------------------------
 Reporter:  walraven       |        Owner:  perbu 
     Type:  documentation  |       Status:  closed
 Priority:  normal         |    Milestone:        
Component:  build          |      Version:  trunk 
 Severity:  normal         |   Resolution:  fixed 
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by perbu):

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


Comment:

 Wiki is OK.

-- 
Ticket URL: <http://varnish-cache.org/ticket/723#comment:5>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Jun 30 21:24:41 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 30 Jun 2010 21:24:41 -0000
Subject: [Varnish] #730: varnishd/cache_fetch.c:FetchBody dropping
	Content-Length on HEAD
Message-ID: <045.5df7efb5659ea0e86c7a2e1129826a07@varnish-cache.org>

#730: varnishd/cache_fetch.c:FetchBody dropping Content-Length on HEAD
----------------------+-----------------------------------------------------
 Reporter:  dormando  |        Type:  defect
   Status:  new       |    Priority:  normal
Milestone:            |   Component:  build 
  Version:  trunk     |    Severity:  normal
 Keywords:            |  
----------------------+-----------------------------------------------------
 Above is more or less it. Run a HEAD request against any webserver, and
 it'll return a Content-Length, which is useful for presizing, embedding
 length of remote objects into RSS feeds, etc.

 Varnish elects to not add the header if the request is a HEAD request.

 cache_fetch.c:FetchBody should have the 'if (is_head)' check within the
 Content-Length test and continue to set mklen = 1, although I think the
 mklen flag is rendered useless by this and could just be dropped.

 Unless there's some reason for this? Apache sends back a Content-Length
 with HEAD, and I can't see anywhere in the RFC which states you can't or
 shouldn't do that.

 thanks!

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