From varnish-bugs at varnish-cache.org  Wed Oct  1 13:05:20 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 01 Oct 2014 13:05:20 -0000
Subject: [Varnish] #1600: PRIV_{REQ,
 SESS} can't be used in multiple VMODs loaded at the same time.
Message-ID: <043.71f98f45d54ff15bc52838edc7e4b713@varnish-cache.org>

#1600: PRIV_{REQ,SESS} can't be used in multiple VMODs loaded at the same time.
----------------------+---------------------
 Reporter:  daghf     |      Owner:
     Type:  defect    |     Status:  new
 Priority:  normal    |  Milestone:
Component:  varnishd  |    Version:  unknown
 Severity:  normal    |   Keywords:
----------------------+---------------------
 PRIV_REQ (and PRIV_SESS) currently hands out the same vmod_priv object to
 every vmod when you have multiple loaded.

 (patch/test case coming)

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1600>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Oct  1 13:14:43 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 01 Oct 2014 13:14:43 -0000
Subject: [Varnish] #1600: PRIV_{REQ,
 SESS} can't be used in multiple VMODs loaded at the same time.
In-Reply-To: <043.71f98f45d54ff15bc52838edc7e4b713@varnish-cache.org>
References: <043.71f98f45d54ff15bc52838edc7e4b713@varnish-cache.org>
Message-ID: <058.5f99d303cad4d4e801a77d95944aaa73@varnish-cache.org>

#1600: PRIV_{REQ,SESS} can't be used in multiple VMODs loaded at the same time.
----------------------+----------------------
 Reporter:  daghf     |       Owner:
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  unknown
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+----------------------

Comment (by daghf):

 The attached test case is kind of heavy handed in that it actually adds
 another VMOD to the varnish source tree. We can probably drop this, and
 postpone a test case until another vmod that actually uses PRIV_REQ
 (vmod_cookie?) is contributed.

 The attached fix adds another parameter to the VRT_priv_{req,sess}
 functions for discerning one VMOD's priv obj from another's. VCC will pass
 a pointer to the VMOD's VGC_vmod_<name> object, which acts as a unique id
 for that VMOD.

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



From varnish-bugs at varnish-cache.org  Wed Oct  1 14:06:48 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 01 Oct 2014 14:06:48 -0000
Subject: [Varnish] #1600: PRIV_{REQ,
 SESS} can't be used in multiple VMODs loaded at the same time.
In-Reply-To: <043.71f98f45d54ff15bc52838edc7e4b713@varnish-cache.org>
References: <043.71f98f45d54ff15bc52838edc7e4b713@varnish-cache.org>
Message-ID: <058.077770123274b8d4ce47a9c3de6a083d@varnish-cache.org>

#1600: PRIV_{REQ,SESS} can't be used in multiple VMODs loaded at the same time.
----------------------+--------------------
 Reporter:  daghf     |       Owner:
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------
Changes (by daghf):

 * version:  unknown => trunk


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



From varnish-bugs at varnish-cache.org  Wed Oct  1 14:20:53 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 01 Oct 2014 14:20:53 -0000
Subject: [Varnish] #1601: PRIV_{REQ,
 SESS} method invocations crash in vcl_backend_*
Message-ID: <043.4159ad35442738d960b0976a1759d0e8@varnish-cache.org>

#1601: PRIV_{REQ,SESS} method invocations crash in vcl_backend_*
----------------------+-------------------
 Reporter:  daghf     |      Owner:
     Type:  defect    |     Status:  new
 Priority:  normal    |  Milestone:
Component:  varnishd  |    Version:  trunk
 Severity:  normal    |   Keywords:
----------------------+-------------------
 The following segfaults in cache_vrt_priv.c:VRT_priv_dynamic() upon
 dereferencing ctx->req:

 {{{
 sub vcl_backend_fetch {
     set bereq.http.b0 = debug.test_priv_req(bereq.url);
 }
 }}}

 (I guess this also begs the question - what should be the semantics of
 PRIV_REQ/SESS in vcl_backend_*?)

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1601>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct  2 07:01:38 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 02 Oct 2014 07:01:38 -0000
Subject: [Varnish] #1600: PRIV_{REQ,
 SESS} can't be used in multiple VMODs loaded at the same time.
In-Reply-To: <043.71f98f45d54ff15bc52838edc7e4b713@varnish-cache.org>
References: <043.71f98f45d54ff15bc52838edc7e4b713@varnish-cache.org>
Message-ID: <058.2d97ca353dd41eb01d6639a14d1ba202@varnish-cache.org>

#1600: PRIV_{REQ,SESS} can't be used in multiple VMODs loaded at the same time.
----------------------+----------------------------------------
 Reporter:  daghf     |       Owner:  Poul-Henning Kamp <phk@?>
     Type:  defect    |      Status:  closed
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |  Resolution:  fixed
 Keywords:            |
----------------------+----------------------------------------
Changes (by Poul-Henning Kamp <phk@?>):

 * owner:   => Poul-Henning Kamp <phk@?>
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [a1cb65112c717d0de3d6f3bd03da2f07d4dbe6ba]:
 {{{
 #!CommitTicketReference repository=""
 revision="a1cb65112c717d0de3d6f3bd03da2f07d4dbe6ba"
 Fix my brainfart in PRIV_SESS and PRIV_REQ:  We want one variable for
 each VMOD which asks.

 Patch by:       mithrandir
 Fixes #1600
 }}}

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



From varnish-bugs at varnish-cache.org  Fri Oct  3 00:03:57 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 03 Oct 2014 00:03:57 -0000
Subject: [Varnish] #1602: Assert error in ESI_DeliverChild(),
 cache/cache_esi_deliver.c line 530
Message-ID: <049.f27733d43af26eeaf7d4a9265aac0f8d@varnish-cache.org>

#1602: Assert error in ESI_DeliverChild(), cache/cache_esi_deliver.c line 530
-------------------------+--------------------
 Reporter:  cache_layer  |       Type:  defect
   Status:  new          |   Priority:  normal
Milestone:               |  Component:  build
  Version:  4.0.1        |   Severity:  normal
 Keywords:               |
-------------------------+--------------------
 Hi,

 I observed several times at irregular intervals that varnish panics with
 the following error:


 {{{
 Last panic at: Tue, 23 Sep 2014 08:05:49 GMT
 Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:
   Condition(uu == bo->fetch_obj->len) not true.
 thread = (cache-worker)
 ident = Linux,3.2.0-55-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
   0x432de5: pan_ic+0xc5
   0x420ee4: vbf_fetch_thread+0x18d4
   0x435cf0: Pool_Work_Thread+0x370
   0x448808: wrk_thread_real+0xc8
   0x7f57bcfcce9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)
 [0x7f57bcfcce9a]
   0x7f57bccfa31d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)
 [0x7f57bccfa31d]
   busyobj = 0x7f5758d95e50 {
     ws = 0x7f5758d95f10 {
       id = "bo",
       {s,f,r,e} = {0x7f5758d97e30,+15344,(nil),+57376},
     },
   refcnt = 1
   retries = 0
   failed = 0
   state = 3
     is_do_esi
     is_uncacheable
     is_is_gzip
     is_should_close
     bodystatus = 4 (eof),
     },
     ws = 0x7f5758d96098 {
       id = "obj",
       {s,f,r,e} = {0x7f54b84ba678,+920,(nil),+920},
     },
   objcore (FETCH) = 0x7f55f8505660 {
     refcnt = 2
     flags = 0x4
     objhead = 0x7f55f86a3450
   }
   obj (FETCH) = 0x7f54b84ba450 {
     vxid = 2186935878,
     http[obj] = {
       ws = 0x7f5758d96098[obj]
         "HTTP/1.0",
         "200",
         "OK",
         "Date: Tue, 23 Sep 2014 08:05:47 GMT",
         "Vary: Accept-Encoding",
         "Content-Encoding: gzip",
         "Content-Type: text/html; charset=UTF-8",
     },
     len = 21523,
     store = {
     },
   },
 }
 }}}

 Best regards

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1602>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Oct  3 00:17:20 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 03 Oct 2014 00:17:20 -0000
Subject: [Varnish] #1602: Assert error in ESI_DeliverChild(),
 cache/cache_esi_deliver.c line 530
In-Reply-To: <049.f27733d43af26eeaf7d4a9265aac0f8d@varnish-cache.org>
References: <049.f27733d43af26eeaf7d4a9265aac0f8d@varnish-cache.org>
Message-ID: <064.7dc61df27efa2fa3dd0e1de305f79d3d@varnish-cache.org>

#1602: Assert error in ESI_DeliverChild(), cache/cache_esi_deliver.c line 530
-------------------------+--------------------
 Reporter:  cache_layer  |       Owner:
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:
Component:  build        |     Version:  4.0.1
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+--------------------

Comment (by cache_layer):

 By mistake, in ticket was pasted another varnish error. The error from
 title in attachment.

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



From varnish-bugs at varnish-cache.org  Fri Oct  3 18:17:29 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 03 Oct 2014 18:17:29 -0000
Subject: [Varnish] #1602: Assert error in ESI_DeliverChild(),
 cache/cache_esi_deliver.c line 530
In-Reply-To: <049.f27733d43af26eeaf7d4a9265aac0f8d@varnish-cache.org>
References: <049.f27733d43af26eeaf7d4a9265aac0f8d@varnish-cache.org>
Message-ID: <064.a89a1295b7707cd21f245fd98fc777e6@varnish-cache.org>

#1602: Assert error in ESI_DeliverChild(), cache/cache_esi_deliver.c line 530
-------------------------+--------------------
 Reporter:  cache_layer  |       Owner:
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:
Component:  build        |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+--------------------
Changes (by fgsch):

 * version:  4.0.1 => trunk


Comment:

 Confirmed.

 Test case attached.

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



From varnish-bugs at varnish-cache.org  Fri Oct  3 18:21:37 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 03 Oct 2014 18:21:37 -0000
Subject: [Varnish] #1602: Assert error in ESI_DeliverChild(),
 cache/cache_esi_deliver.c line 530
In-Reply-To: <049.f27733d43af26eeaf7d4a9265aac0f8d@varnish-cache.org>
References: <049.f27733d43af26eeaf7d4a9265aac0f8d@varnish-cache.org>
Message-ID: <064.7eec4dd1380c361bc9639a3e0feade58@varnish-cache.org>

#1602: Assert error in ESI_DeliverChild(), cache/cache_esi_deliver.c line 530
-------------------------+--------------------
 Reporter:  cache_layer  |       Owner:
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:
Component:  build        |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+--------------------
Description changed by fgsch:

Old description:

> Hi,
>
> I observed several times at irregular intervals that varnish panics with
> the following error:
>

> {{{
> Last panic at: Tue, 23 Sep 2014 08:05:49 GMT
> Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:
>   Condition(uu == bo->fetch_obj->len) not true.
> thread = (cache-worker)
> ident = Linux,3.2.0-55-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll
> Backtrace:
>   0x432de5: pan_ic+0xc5
>   0x420ee4: vbf_fetch_thread+0x18d4
>   0x435cf0: Pool_Work_Thread+0x370
>   0x448808: wrk_thread_real+0xc8
>   0x7f57bcfcce9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)
> [0x7f57bcfcce9a]
>   0x7f57bccfa31d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)
> [0x7f57bccfa31d]
>   busyobj = 0x7f5758d95e50 {
>     ws = 0x7f5758d95f10 {
>       id = "bo",
>       {s,f,r,e} = {0x7f5758d97e30,+15344,(nil),+57376},
>     },
>   refcnt = 1
>   retries = 0
>   failed = 0
>   state = 3
>     is_do_esi
>     is_uncacheable
>     is_is_gzip
>     is_should_close
>     bodystatus = 4 (eof),
>     },
>     ws = 0x7f5758d96098 {
>       id = "obj",
>       {s,f,r,e} = {0x7f54b84ba678,+920,(nil),+920},
>     },
>   objcore (FETCH) = 0x7f55f8505660 {
>     refcnt = 2
>     flags = 0x4
>     objhead = 0x7f55f86a3450
>   }
>   obj (FETCH) = 0x7f54b84ba450 {
>     vxid = 2186935878,
>     http[obj] = {
>       ws = 0x7f5758d96098[obj]
>         "HTTP/1.0",
>         "200",
>         "OK",
>         "Date: Tue, 23 Sep 2014 08:05:47 GMT",
>         "Vary: Accept-Encoding",
>         "Content-Encoding: gzip",
>         "Content-Type: text/html; charset=UTF-8",
>     },
>     len = 21523,
>     store = {
>     },
>   },
> }
> }}}
>
> Best regards

New description:

 Hi,

 I observed several times at irregular intervals that varnish panics with
 the following error:

 {{{
 Last panic at: Thu, 02 Oct 2014 18:14:24 GMT
 Assert error in ESI_DeliverChild(), cache/cache_esi_deliver.c line 530:
   Condition(start > 0 && start < obj->len * 8) not true.
 thread = (cache-worker)
 ident = Linux,3.2.0-55-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
   0x432de5: pan_ic+0xc5
   0x419de3: ESI_DeliverChild+0x4a3
   0x43a005: V1D_Deliver+0x245
   0x436e64: CNT_Request+0x394
   0x419386: ESI_Deliver+0x806
   0x43a2e8: V1D_Deliver+0x528
   0x436e64: CNT_Request+0x394
   0x42ce6b: HTTP1_Session+0x3eb
   0x43b418: ses_req_pool_task+0x68
   0x43c3e9: SES_pool_accept_task+0x2a9
 req = 0x3cad750 {
   sp = 0x7f4085c21bd0, vxid = 1579135918,  step = R_STP_DELIVER,
   req_body = R_BODY_NONE,
   err_code = 200, err_reason = (null),
   restarts = 0, esi_level = 1
   sp = 0x7f4085c21bd0 {
     fd = 341, vxid = 505394083,
     client = 10.214.6.19 57913,
     step = S_STP_WORKING,
   },
   worker = 0x7f43dc025c60 {
     ws = 0x7f43dc025e78 {
       id = "wrk",
       {s,f,r,e} = {0x7f43dc025450,+88,+2048,+2048},
     },
   VCL::method = 0x0,
   VCL::return = deliver,
   },
   ws = 0x3cad8e8 {
     id = "req",
     {s,f,r,e} = {0x3caf740,+128,(nil),+57360},
   },
   http[req] = {
     ws = 0x44eea98[req]
       "GET",
       "/esi/sample",
       "HTTP/1.1",
       "Host: domain.com",
       "Accept:
 text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
       "Connection: keep-alive",
       "Cookie: cokie",
       "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5)
 AppleWebKit/600.1.17 (KHTML, like Gecko) Version/7.1 Safari/537.85.10",
       "Accept-Language: nl-nl",
       "Referer: http://domain.com/",
       "X-UA-Device: pc",
       "Accept-Encoding: gzip",
       "grace: none",
       "Surrogate-Capability: abc=ESI/1.0",
       "X-Port: 80",
   },
   http[resp] = {
     ws = 0x3cad8e8[req]
       "HTTP/1.1",
       "200",
       "OK",
       "Cache-Control: max-age=60,public",
       "X-Content-Type-Options: nosniff",
       "Content-Type: text/html;charset=UTF-8",
       "Content-Language: nl-NL",
       "Date: Thu, 02 Oct 2014 18:14:20 GMT",
       "X-Backend: backend",
       "Content-Encoding: gzip",
       "Age: 0",
       "X-Hit: HIT 0",
       "X-Origin: varnish",
       "grace: none",
       "Transfer-Encoding: chunked",
       "Connection: keep-alive",
   },
   vcl = {
     srcname = {
       "input",
       "Builtin",
       "devicedetect.vcl",
     },
   },
   obj (REQ) = 0x7f41d4d9b150 {
     vxid = 2652877743,
     http[obj] = {
       ws = 0x7f42a1224698[obj]
         "HTTP/1.1",
         "200",
         "OK",
         "Cache-Control: max-age=60,public",
         "X-Content-Type-Options: nosniff",
         "Content-Type: text/html;charset=UTF-8",
         "Content-Language: nl-NL",
         "Date: Thu, 02 Oct 2014 18:14:20 GMT",
         "X-Backend: backend",
         "Content-Encoding: gzip",
     },
     len = 10,
     store = {
       10 {
         1f 8b 08 00 00 00 00 00 00 03                   |..........|
       },
     },
   },
 },
 }}}

 Best regards

--

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



From varnish-bugs at varnish-cache.org  Mon Oct  6 10:16:57 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 06 Oct 2014 10:16:57 -0000
Subject: [Varnish] #1602: Assert error in ESI_DeliverChild(),
 cache/cache_esi_deliver.c line 530
In-Reply-To: <049.f27733d43af26eeaf7d4a9265aac0f8d@varnish-cache.org>
References: <049.f27733d43af26eeaf7d4a9265aac0f8d@varnish-cache.org>
Message-ID: <064.afab83c8c2d99c7748cc591d48a1ccbd@varnish-cache.org>

#1602: Assert error in ESI_DeliverChild(), cache/cache_esi_deliver.c line 530
-------------------------+----------------------------------------
 Reporter:  cache_layer  |       Owner:  Poul-Henning Kamp <phk@?>
     Type:  defect       |      Status:  closed
 Priority:  normal       |   Milestone:
Component:  build        |     Version:  trunk
 Severity:  normal       |  Resolution:  fixed
 Keywords:               |
-------------------------+----------------------------------------
Changes (by Poul-Henning Kamp <phk@?>):

 * owner:   => Poul-Henning Kamp <phk@?>
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [b6071feb7a94cc2c76b103629c86ea8a5ac42ded]:
 {{{
 #!CommitTicketReference repository=""
 revision="b6071feb7a94cc2c76b103629c86ea8a5ac42ded"
 If we know an beresp.body is zero bytes long, zap any Content-Encoding: it
 might have, it doesn't make any sense.

 Fixes   #1602
 }}}

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



From varnish-bugs at varnish-cache.org  Tue Oct  7 10:50:44 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 07 Oct 2014 10:50:44 -0000
Subject: [Varnish] #1603: vcl_hit: rename return(fetch) to return(miss) or
 have return(fetch) go to backend / v_b_f
Message-ID: <043.338aecd00b2faa76f529dbbd6a5e8012@varnish-cache.org>

#1603: vcl_hit: rename return(fetch) to return(miss) or have return(fetch) go to
backend / v_b_f
----------------------+-------------------
 Reporter:  slink     |      Owner:
     Type:  defect    |     Status:  new
 Priority:  normal    |  Milestone:
Component:  varnishd  |    Version:  trunk
 Severity:  normal    |   Keywords:
----------------------+-------------------
 fix up inconsistency

 go to v_b_f is probably to be preferred to allow for conditional requests

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1603>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Oct  7 13:31:03 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 07 Oct 2014 13:31:03 -0000
Subject: [Varnish] #1487: VCL flow outdated
In-Reply-To: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org>
References: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org>
Message-ID: <058.c9fd36d1ce8b93ed9dfadb7344e17d9b@varnish-cache.org>

#1487: VCL flow outdated
---------------------------+---------------------
 Reporter:  fgsch          |       Owner:  slink
     Type:  defect         |      Status:  closed
 Priority:  low            |   Milestone:
Component:  documentation  |     Version:  trunk
 Severity:  normal         |  Resolution:  fixed
 Keywords:                 |
---------------------------+---------------------
Changes (by slink):

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


Comment:

 As of c4520659c02d938969ba3d5d37c4be9489b11198 we should now have up-to-
 date dot files in master.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1487#comment:7>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct  9 10:47:37 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 09 Oct 2014 10:47:37 -0000
Subject: [Varnish] #1604: Reject request lines that don't conform to the
 Request-URI definition in HTTP/1.1
Message-ID: <050.14a3350c32e64c2892a15e7ace57f8e4@varnish-cache.org>

#1604: Reject request lines that don't conform to the Request-URI definition in
HTTP/1.1
--------------------------+----------------------
 Reporter:  mattrobenolt  |       Type:  defect
   Status:  new           |   Priority:  normal
Milestone:                |  Component:  varnishd
  Version:  trunk         |   Severity:  normal
 Keywords:  http          |
--------------------------+----------------------
 Right now, Varnish just happily accepts a request like:

 {{{
 GET Foo HTTP/1.1
 }}}

 Which is not a valid `Reqest-URI` as defined by RFC2616 section 5.1.2 as:

 {{{
 Request-URI    = "*" | absoluteURI | abs_path | authority
 }}}

 And in this case, `abs_path` is defined as

 {{{
 abs_path      = "/"  path_segments
 }}}

 The `absoluteURI` case is already being handled, but we are failing to
 handle `*` or `abs_path` according to RFC2396.

 This also covers the case of `authority` since an `authority` must be
 prefixed with a `//`.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1604>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct  9 11:00:42 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 09 Oct 2014 11:00:42 -0000
Subject: [Varnish] #1605: Resize a storage backend at runtime
Message-ID: <050.4dbf3fe1c587f3d3138d237f2bd32469@varnish-cache.org>

#1605: Resize a storage backend at runtime
--------------------------+-------------------------
 Reporter:  mattrobenolt  |       Type:  enhancement
   Status:  new           |   Priority:  normal
Milestone:                |  Component:  varnishd
  Version:  unknown       |   Severity:  normal
 Keywords:                |
--------------------------+-------------------------
 I talked about this with phk in IRC a while back, so documenting here.

 It would be really awesome to be able to size up/down the storage backend
 without restarting and dumping the whole cache.

 Typically, this is really only important when you're initially trying to
 size your cache correctly.

 Say you get a machine with 96G of RAM dedicated to varnish, and we want to
 tune it just right without waste or going over.

 My process today is such that I set our -smalloc to ~50% of RAM and let
 the cache fill up until it starts evicting objects because of space
 (n_lru_nuked). Then I increase, and try again, but I need to start with an
 empty cache every time.

 Increasing the cache size should be much easier to handle, since it's just
 adding more space. But downsizing would require immediately evicting all
 the old objects until achieving the desired size.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1605>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct  9 11:16:51 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 09 Oct 2014 11:16:51 -0000
Subject: [Varnish] #1605: Resize a storage backend at runtime
In-Reply-To: <050.4dbf3fe1c587f3d3138d237f2bd32469@varnish-cache.org>
References: <050.4dbf3fe1c587f3d3138d237f2bd32469@varnish-cache.org>
Message-ID: <065.e1eb404b73427b897c9e922259f3cc5c@varnish-cache.org>

#1605: Resize a storage backend at runtime
--------------------------+----------------------
 Reporter:  mattrobenolt  |       Owner:
     Type:  enhancement   |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  varnishd      |     Version:  unknown
 Severity:  normal        |  Resolution:  invalid
 Keywords:                |
--------------------------+----------------------
Changes (by scoof):

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


Comment:

 Added to Future_Feature

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



From varnish-bugs at varnish-cache.org  Thu Oct  9 12:26:26 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 09 Oct 2014 12:26:26 -0000
Subject: [Varnish] #1606: Assert error in VDI_Finish(),
 cache/cache_director.c line 120:
Message-ID: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>

#1606: Assert error in VDI_Finish(), cache/cache_director.c line 120:
-------------------------+--------------------
 Reporter:  cache_layer  |       Type:  defect
   Status:  new          |   Priority:  normal
Milestone:               |  Component:  build
  Version:  trunk        |   Severity:  normal
 Keywords:               |
-------------------------+--------------------
 Hi!,

 During testing of the varnish 4 build from master (trunk), I notice the
 following problem. Version 4.0.1 had no such panics.



 {{{
 Last panic at: Thu, 09 Oct 2014 08:26:50 GMT
 Assert error in VDI_Finish(), cache/cache_director.c line 120:
   Condition(bo->director_state != DIR_S_NULL) not true.
 thread = (cache-worker)
 ident = Linux,3.2.0-55-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
   0x4327e5: pan_ic+0xc5
   0x41959d: VDI_Finish+0xbd
   0x421e31: vbf_fetch_thread+0x1201
   0x435041: Pool_Work_Thread+0x361
   0x447abf: WRK_Thread+0x11f
   0x433ddb: pool_thread+0x2b
   0x7fa61b19ee9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)
 [0x7fa61b19ee9a]
   0x7fa61aecc31d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)
 [0x7fa61aecc31d]
   busyobj = 0x7fa398238c70 {
     ws = 0x7fa398238d30 {
       id = "bo",
       {s,f,r,e} = {0x7fa39823ac70,+736,(nil),+57344},
     },
   refcnt = 2
   retries = 0
   failed = 0
   state = 1
     is_do_pass
     is_uncacheable
     is_is_gunzip
     bodystatus = 0 (none),
     },
     http[bereq] = {
       ws = 0x7fa398238d30[bo]
         "GET",
         "/",
         "HTTP/1.0",
         "X-UA-Device: pc",
         "grace: none",
         "X-Forwarded-For: 10.64.16.18",
         "X-VaaS-Prefix: /",
         "Surrogate-Capability: abc=ESI/1.0",
         "X-Port: 80",
         "X-Varnish: 2655139",
         "Host: 10.196.4.122",
     },
     http[beresp] = {
       ws = 0x7fa398238d30[bo]
         "HTTP/1.1",
         "301",
         "Moved Permanently",
         "Date: Thu, 09 Oct 2014 08:26:49 GMT",
         "Vary: Accept-Encoding",
         "Set-Cookie: cookie",
         "Location: /",
         "Content-Length: 0",
         "Connection: close",
         "Content-Type: text/html; charset=UTF-8",
         "X-Backend: backend",
     },
   objcore (FETCH) = 0x7fa48405f230 {
     refcnt = 2
     flags = 0x104
     objhead = 0x1c33680
     stevedore = 0x1c2e370 (malloc Transient)
   }
   }
 }}}

 Best regards

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1606>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct  9 14:50:09 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 09 Oct 2014 14:50:09 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229:#012
Message-ID: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229:#012
----------------------+----------------------
 Reporter:  coredump  |       Type:  defect
   Status:  new       |   Priority:  normal
Milestone:            |  Component:  varnishd
  Version:  4.0.2     |   Severity:  normal
 Keywords:            |
----------------------+----------------------
 `Ubuntu 12.04`

 `Varnish 4.0.2-1~precise`

 {{{
 Linux varnish1 3.2.0-61-generic #93-Ubuntu SMP Fri May 2 21:31:50 UTC 2014
 x86_64 x86_64 x86_64 GNU/Linux
 }}}

 Using `malloc`

 Full message:
 {{{
 Oct  9 13:56:24 varnish1 varnish1[17773]: Child (17831) not responding to
 CLI, killing it.
 Oct  9 13:56:25 varnish1 varnish1[17773]: Child (17831) died signal=6
 Oct  9 13:56:25 varnish1 varnish1[17773]: Child (17831) Panic
 message:#012Assert error in SES_ScheduleReq(), cache/cache_session.c line
 229:#012  Condition((sp)->magic == 0x2c2f9c5a) not true.#012thread =
 (cache-timeout)#012ident =
 Linux,3.2.0-61-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x433135: /usr/sbin/varnishd() [0x433135]#012  0x43be2d:
 /usr/sbin/varnishd(SES_ScheduleReq+0x16d) [0x43be2d]#012  0x425338:
 /usr/sbin/varnishd() [0x425338]#012  0x42696a:
 /usr/sbin/varnishd(HSH_DerefObjCore+0xba) [0x42696a]#012  0x41d977:
 /usr/sbin/varnishd() [0x41d977]#012  0x4491d1: /usr/sbin/varnishd()
 [0x4491d1]#012  0x7f2332ec3e9a: /lib/x86_64-linux-
 gnu/libpthread.so.0(+0x7e9a) [0x7f2332ec3e9a]#012  0x7f2332bf03fd:
 /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f2332bf03fd]#012
 Oct  9 13:56:25 varnish1 varnish1[17773]: Child cleanup complete
 Oct  9 13:56:25 varnish1 varnish1[17773]: child (24312) Started
 Oct  9 13:56:25 varnish1 varnish1[17773]: Child (24312) said Child starts
 }}}

 From varnishadm:
 {{{
 Last panic at: Thu, 09 Oct 2014 13:56:25 GMT
 Assert error in SES_ScheduleReq(), cache/cache_session.c line 229:
   Condition((sp)->magic == 0x2c2f9c5a) not true.
 thread = (cache-timeout)
 ident = Linux,3.2.0-61-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
   0x433135: /usr/sbin/varnishd() [0x433135]
   0x43be2d: /usr/sbin/varnishd(SES_ScheduleReq+0x16d) [0x43be2d]
   0x425338: /usr/sbin/varnishd() [0x425338]
   0x42696a: /usr/sbin/varnishd(HSH_DerefObjCore+0xba) [0x42696a]
   0x41d977: /usr/sbin/varnishd() [0x41d977]
   0x4491d1: /usr/sbin/varnishd() [0x4491d1]
   0x7f2332ec3e9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)
 [0x7f2332ec3e9a]
   0x7f2332bf03fd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)
 [0x7f2332bf03fd]
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1607>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct  9 18:27:06 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 09 Oct 2014 18:27:06 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229 (was: Assert error in
 SES_ScheduleReq(), cache/cache_session.c line 229:#012)
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.5b0221ebbe0e5601306d367b4e3a3746@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+-----------------------
 Reporter:  coredump  |       Owner:
     Type:  defect    |      Status:  needinfo
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+-----------------------
Changes (by fgsch):

 * status:  new => needinfo


Comment:

 Hi.

 Are you able to reproduce it?
 Also, could you supply your VCL, vmods, etc?

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



From varnish-bugs at varnish-cache.org  Thu Oct  9 22:35:32 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 09 Oct 2014 22:35:32 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.6dab26e600a9d396c741ccb360902548@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+-----------------------
 Reporter:  coredump  |       Owner:
     Type:  defect    |      Status:  needinfo
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+-----------------------

Comment (by coredump):

 I can't reproduce it, afaik. Looking at my graphs I don't see anything
 different, nor the log showed anything different. It didn't happen again,
 though. I will keep an eye if it does.

 Vmods loaded when it happened:
 - directors
 - std
 - uuid (using this version https://github.com/mondia/libvmod-uuid.git that
 is an update for varnish 4)

 VCL: I need a private way to send that.

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



From varnish-bugs at varnish-cache.org  Thu Oct  9 23:25:56 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 09 Oct 2014 23:25:56 -0000
Subject: [Varnish] #1608: Varnish does not return 413 or 414
Message-ID: <043.855604c38eb44e6eba395fc067ec62e2@varnish-cache.org>

#1608: Varnish does not return 413 or 414
--------------------+-------------------
 Reporter:  fgsch   |      Owner:
     Type:  defect  |     Status:  new
 Priority:  normal  |  Milestone:
Component:  build   |    Version:  trunk
 Severity:  normal  |   Keywords:
--------------------+-------------------
 If the buffer with size req_http_size is exhausted before we get a request
 Varnish will close the connection.
 It might be desired to return 413 or 414 depending whether we can
 discriminate between uri and headers instead and increase some counter on
 that effect.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1608>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct  9 23:27:16 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 09 Oct 2014 23:27:16 -0000
Subject: [Varnish] #1606: Assert error in VDI_Finish(),
 cache/cache_director.c line 120:
In-Reply-To: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>
References: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>
Message-ID: <064.41cbebb412bf99334799cc4dbaa29d5b@varnish-cache.org>

#1606: Assert error in VDI_Finish(), cache/cache_director.c line 120:
-------------------------+-----------------------
 Reporter:  cache_layer  |       Owner:
     Type:  defect       |      Status:  needinfo
 Priority:  normal       |   Milestone:
Component:  build        |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+-----------------------
Changes (by fgsch):

 * status:  new => needinfo


Comment:

 Can you provide the revision number this was built upon and the VCL in
 use?
 Also, is this something you can reproduce?

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



From varnish-bugs at varnish-cache.org  Fri Oct 10 04:21:56 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 10 Oct 2014 04:21:56 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.f230672cdcdf4180632f6782d75c18c6@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+-----------------------
 Reporter:  coredump  |       Owner:
     Type:  defect    |      Status:  needinfo
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+-----------------------

Comment (by coredump):

 Got some more during the day

 {{{
 Last panic at: Thu, 09 Oct 2014 20:08:28 GMT
 Assert error in SES_ScheduleReq(), cache/cache_session.c line 229:
   Condition((sp)->magic == 0x2c2f9c5a) not true.
 errno = 32 (Broken pipe)
 thread = (cache-worker)
 ident = Linux,3.2.0-61-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
   0x433135: /usr/sbin/varnishd() [0x433135]
   0x43be2d: /usr/sbin/varnishd(SES_ScheduleReq+0x16d) [0x43be2d]
   0x425338: /usr/sbin/varnishd() [0x425338]
   0x4261ea: /usr/sbin/varnishd(HSH_Unbusy+0xea) [0x4261ea]
   0x420b38: /usr/sbin/varnishd() [0x420b38]
   0x436033: /usr/sbin/varnishd(Pool_Work_Thread+0x373) [0x436033]
   0x4492f8: /usr/sbin/varnishd() [0x4492f8]
   0x7f2332ec3e9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)
 [0x7f2332ec3e9a]
   0x7f2332bf03fd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)
 [0x7f2332bf03fd]
   busyobj = 0x7f2167287020 {
     ws = 0x7f21672870e0 {
       id = "bo",
       {s,f,r,e} = {0x7f2167289008,+1120,(nil),+57368},
     },
   refcnt = 2
   retries = 0
   failed = 0
   state = 1
     is_do_stream
     is_is_gunzip
     bodystatus = 2 (chunked),
     },
     http[bereq] = {
       ws = 0x7f21672870e0[bo]
         "GET",
         "/chorus_images/41399832/cinema/rss_large/1412883743",
         "HTTP/1.1",
         "Host: www.eater.com",
         "Accept: */*",
         "Accept-Language: en-us",
         "User-Agent: Flipboard/2.1.1 CFNetwork/672.0.2 Darwin/14.0.0",
         "X-Forwarded-For: 189.171.25.194",
         "X-Vox-ID: 068c66d6-4ff0-11e4-b169-fb5fd9519e71",
         "X-Vox-App: chorus",
         "Accept-Encoding: gzip",
         "X-Varnish: 34418404",
     },
     http[beresp] = {
       ws = 0x7f21672870e0[bo]
         "HTTP/1.1",
         "301",
         "Moved Permanently",
         "Server: nginx",
         "Date: Thu, 09 Oct 2014 20:08:25 GMT",
         "Content-Type: text/html; charset=utf-8",
         "Transfer-Encoding: chunked",
         "Connection: keep-alive",
         "Status: 301 Moved Permanently",
         "Location: http://cdn1.vox-
 cdn.com/uploads/chorus_image/image/41402754/OTable-Google-
 App-4.0.0_cinema_400.0.jpg",
         "X-UA-Compatible: IE=Edge,chrome=1",
         "Cache-Control: no-cache",
         "X-Request-Id: 8ba719b9c5d3f0bf28243d3af34fd60d",
         "X-Runtime: 1.130832",
         "P3P: CP="CAO DSP COR CURa ADMa DEVa PSAa PSDa CONi OUR IND PHY
 ONL UNI COM NAV INT CNT STA"",
     },
     ws = 0x7f2167287270 {
       id = "obj",
       {s,f,r,e} = {0x7f22c1589df8,+520,(nil),+520},
     },
   objcore (FETCH) = 0x7f1a85d85400 {
     refcnt = 3
     flags = 0x0
     objhead = 0x7f19ef3fd320
   }
   obj (FETCH) = 0x7f22c1589c00 {
     vxid = 2181902052,
     http[obj] = {
       ws = (nil)[]
         "HTTP/1.1",
         "301",
         "Moved Permanently",
         "Server: nginx",
         "Date: Thu, 09 Oct 2014 20:08:25 GMT",
         "Content-Type: text/html; charset=utf-8",
         "Status: 301 Moved Permanently",
         "Location: http://cdn1.vox-
 cdn.com/uploads/chorus_image/image/41402754/OTable-Google-
 App-4.0.0_cinema_400.0.jpg",
         "X-UA-Compatible: IE=Edge,chrome=1",
         "Cache-Control: no-cache",
         "X-Request-Id: 8ba719b9c5d3f0bf28243d3af34fd60d",
         "X-Runtime: 1.130832",
         "P3P: CP="CAO DSP COR CURa ADMa DEVa PSAa PSDa CONi OUR IND PHY
 ONL UNI COM NAV INT CNT STA"",
     },
     len = 0,
     store = {
     },
   },
   }
 }}}

 {{{
 Oct  9 15:49:33 varnish1 varnish1[17773]: Child (24312) Panic
 message:#012Assert error in SES_Schedul
 eReq(), cache/cache_session.c line 229:#012  Condition((sp)->magic ==
 0x2c2f9c5a) not true.#012thread
  = (cache-timeout)#012ident =
 Linux,3.2.0-61-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Back
 trace:#012  0x433135: /usr/sbin/varnishd() [0x433135]#012  0x43be2d:
 /usr/sbin/varnishd(SES_ScheduleR
 eq+0x16d) [0x43be2d]#012  0x425338: /usr/sbin/varnishd() [0x425338]#012
 0x42696a: /usr/sbin/varnishd
 (HSH_DerefObjCore+0xba) [0x42696a]#012  0x41d977: /usr/sbin/varnishd()
 [0x41d977]#012  0x4491d1: /usr
 /sbin/varnishd() [0x4491d1]#012  0x7f2332ec3e9a: /lib/x86_64-linux-
 gnu/libpthread.so.0(+0x7e9a) [0x7f
 2332ec3e9a]#012  0x7f2332bf03fd: /lib/x86_64-linux-
 gnu/libc.so.6(clone+0x6d) [0x7f2332bf03fd]#012
 }}}

 {{{
 Oct  9 18:57:07 varnish1 varnish1[17773]: Child (21947) Panic
 message:#012Assert error in SES_Schedul
 eReq(), cache/cache_session.c line 229:#012  Condition((sp)->magic ==
 0x2c2f9c5a) not true.#012thread
  = (cache-worker)#012ident =
 Linux,3.2.0-61-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backt
 race:#012  0x433135: /usr/sbin/varnishd() [0x433135]#012  0x43be2d:
 /usr/sbin/varnishd(SES_ScheduleRe
 q+0x16d) [0x43be2d]#012  0x425338: /usr/sbin/varnishd() [0x425338]#012
 0x4261ea: /usr/sbin/varnishd(
 HSH_Unbusy+0xea) [0x4261ea]#012  0x420b38: /usr/sbin/varnishd()
 [0x420b38]#012  0x436033: /usr/sbin/v
 arnishd(Pool_Work_Thread+0x373) [0x436033]#012  0x4492f8:
 /usr/sbin/varnishd() [0x4492f8]#012  0x7f23
 32ec3e9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)
 [0x7f2332ec3e9a]#012  0x7f2332bf03fd: /lib/x
 86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f2332bf03fd]#012  busyobj =
 0x7f2027426020 {#012    ws = 0x
 7f20274260e0 {#012      id = "bo",#012      {s,f,r,e} =
 {0x7f2027428008,+7720,(nil),+57368},#012    }
 ,#012  refcnt = 2#012  retries = 0#012  failed = 0#012  state = 1#012
 is_do_stream#012    is_is_gu
 nzip#012    bodystatus = 2 (chunked),#012    },#012    http[bereq] = {#012
 ws = 0x7f20274260e0[b
 o]#012        "GET",#012        "/polygon_entries/polybar/forums",#012
 "HTTP/1.1",#012
 "X-Requested-With: XMLHttpRequest",#012        "Accept: text/html, */*;
 q=0.01",#012        "Referer:
  http://www.polygon.com/2014/5/23/5745986/watch-dogs-gameplay-video-
 walkthrough",#012        "Accept-
 Language: en-GB",#012        "User-Agent: Mozilla/5.0 (Windows NT 6.1;
 WOW64; Trident/7.0; rv:11.0) l
 ike Gecko",#012        "Host: www.polygon.com",#012        "X-Forwarded-
 For: 82.24.191.42",#012        "X-Vox-ID:
 0f025578-4fe6-11e4-b036-f7597b3b6c5e",#012        "Accept-Encoding:
 gzip",#012        "X-Varnish: 167418799",#012    },#012    http[beresp] =
 {#012      ws = 0x7f20274260e0[bo]#012        "HTTP/1.1",#012
 "200",#012        "OK",#012        "Server: nginx",#012        "Date: Thu,
 09 Oct 2014 18:57:04 GMT",#012
 }}}

 Sorry for the formatting, had to get the previous ones from the log.

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



From varnish-bugs at varnish-cache.org  Fri Oct 10 04:35:59 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 10 Oct 2014 04:35:59 -0000
Subject: [Varnish] #1609: Reset MGT.child_panic after a panic.clear
Message-ID: <046.f6154daa50f9ea4015af5bbbbd99f173@varnish-cache.org>

#1609: Reset MGT.child_panic after a panic.clear
----------------------+-------------------------
 Reporter:  coredump  |       Type:  enhancement
   Status:  new       |   Priority:  normal
Milestone:            |  Component:  build
  Version:  4.0.2     |   Severity:  normal
 Keywords:            |
----------------------+-------------------------
 When you use `panic.clear` on `varnishadmin` the MGT counter on
 `varnishstats` doesn't reset back to zero. If you are doing a test with a
 tool like the nagios scripts that check that value for critical and
 warning values you will end on that status forever after a panic.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1609>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Oct 10 16:39:13 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 10 Oct 2014 16:39:13 -0000
Subject: [Varnish] #1610: Varnish 4.0 troubleshooting guide's varnishlog
 example is out of date
Message-ID: <045.d2e4c622b3a4d0b67ccf4dc8df052246@varnish-cache.org>

#1610: Varnish 4.0 troubleshooting guide's varnishlog example is out of date
---------------------------------+---------------------------
 Reporter:  gtaylor              |       Type:  defect
   Status:  new                  |   Priority:  normal
Milestone:  Varnish 4.0 release  |  Component:  documentation
  Version:  trunk                |   Severity:  normal
 Keywords:  varnishlog guide     |
---------------------------------+---------------------------
 The varnishlog section at the bottom for viewing 503s appears to be out of
 date:

 https://www.varnish-cache.org/docs/trunk/users-guide/troubleshooting.html
 #varnish-gives-me-guru-meditation

 It asks for something like:


 {{{
 $ varnishlog -c -m TxStatus:503
 }}}

 But it appears that the -m flag is no longer present in 4.0.

 I'm not sure if TxStatus exists anymore, either.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1610>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 13 10:03:03 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 10:03:03 -0000
Subject: [Varnish] #1610: Varnish 4.0 troubleshooting guide's varnishlog
 example is out of date
In-Reply-To: <045.d2e4c622b3a4d0b67ccf4dc8df052246@varnish-cache.org>
References: <045.d2e4c622b3a4d0b67ccf4dc8df052246@varnish-cache.org>
Message-ID: <060.bdbf5a2436a8865a70f4feb287a83369@varnish-cache.org>

#1610: Varnish 4.0 troubleshooting guide's varnishlog example is out of date
------------------------------+----------------------------------
 Reporter:  gtaylor           |       Owner:  daghf
     Type:  defect            |      Status:  new
 Priority:  normal            |   Milestone:  Varnish 4.0 release
Component:  documentation     |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  varnishlog guide  |
------------------------------+----------------------------------
Changes (by daghf):

 * owner:   => daghf


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



From varnish-bugs at varnish-cache.org  Mon Oct 13 10:15:55 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 10:15:55 -0000
Subject: [Varnish] #1609: Reset MGT.child_panic after a panic.clear
In-Reply-To: <046.f6154daa50f9ea4015af5bbbbd99f173@varnish-cache.org>
References: <046.f6154daa50f9ea4015af5bbbbd99f173@varnish-cache.org>
Message-ID: <061.6cab99c04725664557bdae39a4737bfb@varnish-cache.org>

#1609: Reset MGT.child_panic after a panic.clear
-------------------------+--------------------
 Reporter:  coredump     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:
Component:  build        |     Version:  4.0.2
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+--------------------

Comment (by lkarsten):

 Discussed during bugwash today. We'll add a -z (or similar) option to
 panic.clear that will clear this counter.

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



From varnish-bugs at varnish-cache.org  Mon Oct 13 10:20:26 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 10:20:26 -0000
Subject: [Varnish] #1606: Assert error in VDI_Finish(),
 cache/cache_director.c line 120:
In-Reply-To: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>
References: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>
Message-ID: <064.a4c1eff73942572540acf8562128fc04@varnish-cache.org>

#1606: Assert error in VDI_Finish(), cache/cache_director.c line 120:
-------------------------+--------------------
 Reporter:  cache_layer  |       Owner:  phk
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:
Component:  build        |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+--------------------
Changes (by phk):

 * owner:   => phk
 * status:  needinfo => new


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



From varnish-bugs at varnish-cache.org  Mon Oct 13 10:20:45 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 10:20:45 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.4c08820298af2635c59f7c06f7c29417@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+--------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------
Changes (by phk):

 * owner:   => phk
 * status:  needinfo => new


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



From varnish-bugs at varnish-cache.org  Mon Oct 13 10:35:07 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 10:35:07 -0000
Subject: [Varnish] #1611: Unreferenced counters
Message-ID: <043.ca60d02c4bb03bb598dd3994a53a3ab2@varnish-cache.org>

#1611: Unreferenced counters
--------------------+-------------------
 Reporter:  daghf   |      Owner:
     Type:  defect  |     Status:  new
 Priority:  normal  |  Milestone:
Component:  build   |    Version:  trunk
 Severity:  normal  |   Keywords:
--------------------+-------------------
 The following counters are not updated anywhere:

 client_req_411
 client_req_413
 sms_nreq
 sms_nobj
 sms_nbytes
 sms_balloc
 sms_bfree

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1611>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 13 10:35:25 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 10:35:25 -0000
Subject: [Varnish] #1611: Unreferenced counters
In-Reply-To: <043.ca60d02c4bb03bb598dd3994a53a3ab2@varnish-cache.org>
References: <043.ca60d02c4bb03bb598dd3994a53a3ab2@varnish-cache.org>
Message-ID: <058.a743520ec29631bd26a54dbde42cc44b@varnish-cache.org>

#1611: Unreferenced counters
--------------------+--------------------
 Reporter:  daghf   |       Owner:
     Type:  defect  |      Status:  new
 Priority:  normal  |   Milestone:
Component:  build   |     Version:  trunk
 Severity:  normal  |  Resolution:
 Keywords:          |
--------------------+--------------------
Description changed by daghf:

Old description:

> The following counters are not updated anywhere:
>
> client_req_411
> client_req_413
> sms_nreq
> sms_nobj
> sms_nbytes
> sms_balloc
> sms_bfree

New description:

 The following counters are not updated anywhere:
 {{{
 client_req_411
 client_req_413
 sms_nreq
 sms_nobj
 sms_nbytes
 sms_balloc
 sms_bfree
 }}}

--

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



From varnish-bugs at varnish-cache.org  Mon Oct 13 11:57:01 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 11:57:01 -0000
Subject: [Varnish] #1610: Varnish 4.0 troubleshooting guide's varnishlog
 example is out of date
In-Reply-To: <045.d2e4c622b3a4d0b67ccf4dc8df052246@varnish-cache.org>
References: <045.d2e4c622b3a4d0b67ccf4dc8df052246@varnish-cache.org>
Message-ID: <060.0fa26851f5096713dc0c3b728bbc24f9@varnish-cache.org>

#1610: Varnish 4.0 troubleshooting guide's varnishlog example is out of date
------------------------------+----------------------------------
 Reporter:  gtaylor           |       Owner:  daghf
     Type:  defect            |      Status:  closed
 Priority:  normal            |   Milestone:  Varnish 4.0 release
Component:  documentation     |     Version:  trunk
 Severity:  normal            |  Resolution:  fixed
 Keywords:  varnishlog guide  |
------------------------------+----------------------------------
Changes (by Dag Haavi Finstad <daghf@?>):

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


Comment:

 In [b3e08acc60e1c5652ce5f82cf84f26cc917341b9]:
 {{{
 #!CommitTicketReference repository=""
 revision="b3e08acc60e1c5652ce5f82cf84f26cc917341b9"
 Update forgotten varnishlog example to 4.0 syntax.

 Fixes: #1610
 }}}

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



From varnish-bugs at varnish-cache.org  Mon Oct 13 12:14:46 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 12:14:46 -0000
Subject: [Varnish] #1462: ReqURL is emitted twice
In-Reply-To: <043.4c15f0afe4e6c22dd922a9ce48ae670c@varnish-cache.org>
References: <043.4c15f0afe4e6c22dd922a9ce48ae670c@varnish-cache.org>
Message-ID: <058.a21685456a79dd0efd0021e9eca347a8@varnish-cache.org>

#1462: ReqURL is emitted twice
--------------------+-----------------------------------------------
 Reporter:  scoof   |       Owner:  Martin Blix Grydeland <martin@?>
     Type:  defect  |      Status:  reopened
 Priority:  normal  |   Milestone:  Varnish 4.0-TP2
Component:  build   |     Version:  trunk
 Severity:  normal  |  Resolution:
 Keywords:          |
--------------------+-----------------------------------------------
Changes (by lkarsten):

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


Comment:

 This new behaviour makes varnishncsa log the wrong value for synth-ed
 responses.

 Observed behaviour: For the following varnishlog entry, varnishncsa logs
 799 as the response status.
 Expected result: log the 200 response status set in vcl_synth.

 {{{
 *   << Request  >> 5434
 -   Begin          req 164125 rxreq
 -   Timestamp      Start: 1413201790.974362 0.000000 0.000000
 -   Timestamp      Req: 1413201790.974362 0.000000 0.000000
 -   ReqStart       2001:16d8:ee00:1c1::2 57184
 -   ReqMethod      GET
 -   ReqURL         /rtstatus.json
 -   ReqProtocol    HTTP/1.1
 [..]
 -   Debug          "VCL_error(799, OK)"
 -   VCL_return     synth
 -   ReqUnset       Accept-Encoding: gzip,deflate,sdch
 -   ReqHeader      Accept-Encoding: gzip
 -   VCL_call       HASH
 -   VCL_return     lookup
 -   Timestamp      Process: 1413201790.974451 0.000089 0.000089
 -   RespHeader     Date: Mon, 13 Oct 2014 12:03:10 GMT
 -   RespHeader     Server: Varnish
 -   RespHeader     X-Varnish: 5434
 -   RespProtocol   HTTP/1.1
 -   RespStatus     799
 -   RespReason     Unknown HTTP Status
 -   RespReason     OK
 -   VCL_call       SYNTH
 -   RespStatus     200
 -   RespReason     OK
 -   VCL_return     deliver
 [..]
 }}}

 {{{
 2001:16d8:ee00:1c1::2 - - [13/Oct/2014:14:12:56 +0200] "GET
 http://hyse.org/rtstatus.json HTTP/1.1" 799 29345
 "http://hyse.org/rtstatus" "Mozilla/5.0 (X11; Linux x86_64)
 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36"
 }}}

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



From varnish-bugs at varnish-cache.org  Mon Oct 13 17:17:06 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 17:17:06 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.01e09f1c345e880d96151578d51ee13a@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+--------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by coredump):

 Same panic happened 4 times again today, 3 of the times happening less
 than 5 minutes apart.

 Backported libjemalloc 3.5 from ubuntu trusty to precise, installed and
 restarted varnish, will monitor if that change makes any difference.

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



From varnish-bugs at varnish-cache.org  Mon Oct 13 17:35:58 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 17:35:58 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.fc6806f651711b75b34e02b1ab9c4717@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+--------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by coredump):

 Nope, didn't help.

 {{{
 Last panic at: Mon, 13 Oct 2014 17:33:55 GMT
 Assert error in SES_ScheduleReq(), cache/cache_session.c line 229:
   Condition((sp)->magic == 0x2c2f9c5a) not true.
 thread = (cache-worker)
 ident = Linux,3.2.0-61-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
   0x433135: /usr/sbin/varnishd() [0x433135]
   0x43be2d: /usr/sbin/varnishd(SES_ScheduleReq+0x16d) [0x43be2d]
   0x425338: /usr/sbin/varnishd() [0x425338]
   0x4261ea: /usr/sbin/varnishd(HSH_Unbusy+0xea) [0x4261ea]
   0x420b38: /usr/sbin/varnishd() [0x420b38]
   0x436033: /usr/sbin/varnishd(Pool_Work_Thread+0x373) [0x436033]
   0x4492f8: /usr/sbin/varnishd() [0x4492f8]
   0x7f00faffae9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)
 [0x7f00faffae9a]
   0x7f00fad273fd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)
 [0x7f00fad273fd]
   busyobj = 0x7f007e2bf020 {
     ws = 0x7f007e2bf0e0 {
       id = "bo",
       {s,f,r,e} = {0x7f007e2c1008,+1304,(nil),+57368},
     },
   refcnt = 2
   retries = 0
   failed = 0
   state = 1
     is_do_stream
     is_is_gunzip
     bodystatus = 2 (chunked),
     },
     http[bereq] = {
       ws = 0x7f007e2bf0e0[bo]
         "GET",
         "/chorus_images/41743702/cinema/rss_large/1413199650",
         "HTTP/1.1",
         "Host: www.polygon.com",
         "Accept: image/webp,*/*;q=0.8",
         "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5)
 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101
 Safari/537.36",
         "DNT: 1",
         "Referer: http://s3.feedly.com/production/head/",
         "Accept-Language: en-US,en;q=0.8",
         "X-Forwarded-For: 74.3.127.50",
         "X-Vox-ID: 19f4d99e-52ff-11e4-8cd1-e70ff75d5723",
         "X-Vox-App: chorus",
         "Accept-Encoding: gzip",
         "X-Varnish: 53380443",
     },
     http[beresp] = {
       ws = 0x7f007e2bf0e0[bo]
         "HTTP/1.1",
         "301",
         "Moved Permanently",
         "Server: nginx",
         "Date: Mon, 13 Oct 2014 17:33:53 GMT",
         "Content-Type: text/html; charset=utf-8",
         "Transfer-Encoding: chunked",
         "Connection: keep-alive",
         "Status: 301 Moved Permanently",
         "Location: http://cdn2.vox-
 cdn.com/uploads/chorus_image/image/41744604/residentevilrevelations_review_a_1500.0_cinema_720.0.jpg",
         "X-UA-Compatible: IE=Edge,chrome=1",
         "Cache-Control: no-cache",
         "X-Request-Id: 58e7591bf3cdabb570d520cf2522c4a1",
         "X-Runtime: 0.626189",
         "P3P: CP="CAO DSP COR CURa ADMa DEVa PSAa PSDa CONi OUR IND PHY
 ONL UNI COM NAV INT CNT STA"",
     },
     ws = 0x7f007e2bf270 {
       id = "obj",
       {s,f,r,e} = {0x7f005aa32ff8,+536,(nil),+536},
     },
   objcore (FETCH) = 0x7f002d7be880 {
     refcnt = 3
     flags = 0x0
     objhead = 0x7f00b8cc91d0
   }
   obj (FETCH) = 0x7f005aa32e00 {
     vxid = 2200864091,
     http[obj] = {
       ws = (nil)[]
         "HTTP/1.1",
         "301",
         "Moved Permanently",
         "Server: nginx",
         "Date: Mon, 13 Oct 2014 17:33:53 GMT",
         "Content-Type: text/html; charset=utf-8",
         "Status: 301 Moved Permanently",
         "Location: http://cdn2.vox-
 cdn.com/uploads/chorus_image/image/41744604/residentevilrevelations_review_a_1500.0_cinema_720.0.jpg",
         "X-UA-Compatible: IE=Edge,chrome=1",
         "Cache-Control: no-cache",
         "X-Request-Id: 58e7591bf3cdabb570d520cf2522c4a1",
         "X-Runtime: 0.626189",
         "P3P: CP="CAO DSP COR CURa ADMa DEVa PSAa PSDa CONi OUR IND PHY
 ONL UNI COM NAV INT CNT STA"",
     },
     len = 0,
     store = {
     },
   },
   }
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1607#comment:6>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 13 20:16:27 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 13 Oct 2014 20:16:27 -0000
Subject: [Varnish] #1611: Unreferenced counters
In-Reply-To: <043.ca60d02c4bb03bb598dd3994a53a3ab2@varnish-cache.org>
References: <043.ca60d02c4bb03bb598dd3994a53a3ab2@varnish-cache.org>
Message-ID: <058.6b1122be800e1a8f387fecba59272a29@varnish-cache.org>

#1611: Unreferenced counters
--------------------+--------------------
 Reporter:  daghf   |       Owner:
     Type:  defect  |      Status:  new
 Priority:  normal  |   Milestone:
Component:  build   |     Version:  trunk
 Severity:  normal  |  Resolution:
 Keywords:          |
--------------------+--------------------

Comment (by lkarsten):

 sess_drop can be added to this list.

 In SES_Pool_accept_task(), ses_new() will never return NULL without
 asserting first, so VCA_FailSess() is never called.

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



From varnish-bugs at varnish-cache.org  Tue Oct 14 00:52:20 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 14 Oct 2014 00:52:20 -0000
Subject: [Varnish] #1557: regsuball() doesn't honor lookahead assertion
 on repeated strings
In-Reply-To: <059.714287d6d2b95c176d62f92faff8648e@varnish-cache.org>
References: <059.714287d6d2b95c176d62f92faff8648e@varnish-cache.org>
Message-ID: <074.17a785ce59b00495b3a43ffc14e50692@varnish-cache.org>

#1557: regsuball() doesn't honor lookahead assertion on repeated strings
--------------------------------------+---------------------
 Reporter:  varnish@?                 |       Owner:  martin
     Type:  defect                    |      Status:  closed
 Priority:  normal                    |   Milestone:
Component:  varnishd                  |     Version:  trunk
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  lookahead pcre regsuball  |
--------------------------------------+---------------------
Changes (by Federico G. Schwindt <fgsch@?>):

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


Comment:

 In [b9e53ea2ebbb59d739bb2307b16743a9179090a4]:
 {{{
 #!CommitTicketReference repository=""
 revision="b9e53ea2ebbb59d739bb2307b16743a9179090a4"
 Fix lookbehind handling in regsuball

 Do not advance the subject but use the ovector information as offset,
 pcre might need to peek back when handling lookbehinds.

 Original patch from MegaMaddin via github.

 Fixes: #1557
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1557#comment:6>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Oct 14 13:10:21 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 14 Oct 2014 13:10:21 -0000
Subject: [Varnish] #1606: Assert error in VDI_Finish(),
 cache/cache_director.c line 120:
In-Reply-To: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>
References: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>
Message-ID: <064.13192983c2b61f067c029073bb5a5142@varnish-cache.org>

#1606: Assert error in VDI_Finish(), cache/cache_director.c line 120:
-------------------------+--------------------
 Reporter:  cache_layer  |       Owner:  phk
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:
Component:  build        |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+--------------------

Comment (by cache_layer):

 Can I send the vcl on a private mail?
 We built this varnish from trunk, with the latest commit:

 b4da6893d263b26f8c4f4308673bf0e4d67055cb
 Author: Federico G. Schwindt <fgsch at lodoss.net>
 Date:???Wed Oct 8 17:10:35 2014 +0100


 First panic occurred after 10 minutes from varnish start. I think there
 will not be a problem with the reproduce this issue.

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



From varnish-bugs at varnish-cache.org  Tue Oct 14 14:32:37 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 14 Oct 2014 14:32:37 -0000
Subject: [Varnish] #1606: Assert error in VDI_Finish(),
 cache/cache_director.c line 120:
In-Reply-To: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>
References: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>
Message-ID: <064.92a586631c2fa790f5db77226df36159@varnish-cache.org>

#1606: Assert error in VDI_Finish(), cache/cache_director.c line 120:
-------------------------+--------------------
 Reporter:  cache_layer  |       Owner:  phk
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:
Component:  build        |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+--------------------

Comment (by fgsch):

 Feel free to send me the VCL privately and we'll take a look.

 AS for running trunk (master really) I'd suggest to go for 4.0.2 instead
 if this is for prod.
 While is great that you are giving master a spin this is where development
 happens and there might be some instability from time to time.

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



From varnish-bugs at varnish-cache.org  Tue Oct 14 14:36:01 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 14 Oct 2014 14:36:01 -0000
Subject: [Varnish] #1525: free() in VBO_DerefBusyObj causes child crash
In-Reply-To: <044.d5889a74d0ac7c4cb6b2eb7d0991d0bb@varnish-cache.org>
References: <044.d5889a74d0ac7c4cb6b2eb7d0991d0bb@varnish-cache.org>
Message-ID: <059.c996f4582571fd950b8a8ffd600950e7@varnish-cache.org>

#1525: free() in VBO_DerefBusyObj causes child crash
----------------------+-----------------------
 Reporter:  joakim    |       Owner:
     Type:  defect    |      Status:  needinfo
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.0
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+-----------------------

Comment (by fgsch):

 joakim, can you give 4.0.2 a spin? These issues should be fixed there.

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



From varnish-bugs at varnish-cache.org  Tue Oct 14 14:43:36 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 14 Oct 2014 14:43:36 -0000
Subject: [Varnish] #1527: Assert error in hcb_insert(),
 hash/hash_critbit.c line 226:   Condition(noh == NULL) not true.
In-Reply-To: <044.291983e897d6be23b7193869c25cc93a@varnish-cache.org>
References: <044.291983e897d6be23b7193869c25cc93a@varnish-cache.org>
Message-ID: <059.85f93270c30d4787155ed27598f720a5@varnish-cache.org>

#1527: Assert error in hcb_insert(), hash/hash_critbit.c line 226:   Condition(noh
== NULL) not true.
----------------------+-----------------------
 Reporter:  joakim    |       Owner:
     Type:  defect    |      Status:  needinfo
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.0
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+-----------------------

Comment (by fgsch):

 joakim, any update on this?

 also, can you give 4.0.2 a spin and report back?

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



From varnish-bugs at varnish-cache.org  Wed Oct 15 07:17:26 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 15 Oct 2014 07:17:26 -0000
Subject: [Varnish] #1239: Problem with cleaning up "gone" bans
In-Reply-To: <042.4f254c324d62a995d9a1391b1db24d2f@varnish-cache.org>
References: <042.4f254c324d62a995d9a1391b1db24d2f@varnish-cache.org>
Message-ID: <057.5ee669df8ecd17b149e6e602a0b684df@varnish-cache.org>

#1239: Problem with cleaning up "gone" bans
----------------------+----------------------
 Reporter:  xani      |       Owner:  martin
     Type:  defect    |      Status:  closed
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  3.0.3
 Severity:  normal    |  Resolution:  invalid
 Keywords:            |
----------------------+----------------------

Comment (by domtheo):

 [http://www.papdan.com/ melbourne web designer] | [http://www.papdan.com
 /seo-services-search-engine-optimisation.php Melbourne SEO Services] |
 [[http://www.oxone-online.com Oxone]

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1239#comment:7>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Oct 15 12:10:15 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 15 Oct 2014 12:10:15 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.1cbf732c6a4448ed9c89f093836a8e96@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+--------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by Jay):

 I get the same assert error, several times a day

 {{{
 Oct 15 10:19:42 p4-varnish01 varnishd[1907]: Child (1236) Panic message:
 Assert error in SES_ScheduleReq(), cache/cache_session.c line 229:
 Condition((sp)->magic == 0x2c2f9c5a) n
 ot true. thread = (cache-worker) ident =
 Linux,3.14.11,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
 0x434c88: pan_ic+0xd8   0x43dcbd: SES_ScheduleReq+0x18d
 0x425168: hsh_rush+0xb8
 0x427743: HSH_DerefObjCore+0x173
 0x438c83: cnt_deliver+0x363
 0x439209: CNT_Request+0xf9
 0x42d06b: HTTP1_Session+0x43b
 0x43d707: ses_req_pool_task+0x67
 0x4378fe: Pool_Work_Thread+0x36e
 0x44af6d: wrk_thread_real+0xad req = 0x7ff77c1087e0
 {   sp = 0x7ff77c0cdb50, vxid = 4915234,  step = R_STP_DELIVER,   req_body
 = R_BODY_NONE,   restart
 s = 0, esi_level = 0   sp = 0x7ff77c0cdb50 {     fd = 2776, vxid =
 4915233,     client = x.x.x.x 27417,     step = S_STP_WORKING,   },
 worker = 0x7ff78d0d8c70 {     ws = 0x
 7ff78d0d8e80 {       id = "wrk",       {s,f,r,e} =
 {0x7ff78d0d8470,0x7ff78d0d8470,(nil),+2048},     },   VCL::method =
 DELIVER,
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1607#comment:7>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct 16 08:40:19 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 16 Oct 2014 08:40:19 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.0e5a07803f9fa46a1fa481eaf44e1ac4@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+--------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by phk):

 Can you please try increasing workspace_session parameter to something
 like 1kB ?

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1607#comment:8>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct 16 09:15:17 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 16 Oct 2014 09:15:17 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.fde95065ed0a5ef2f9c852a69a9c458b@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+--------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by phk):

 Please also try a fresh -trunk, I have added some extra checks.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1607#comment:9>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct 16 13:42:26 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 16 Oct 2014 13:42:26 -0000
Subject: [Varnish] #1506: Make better use of Content-Length information:
 Avoid chunked responses, more control over Range handling
In-Reply-To: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org>
References: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org>
Message-ID: <065.7429b11f793e30f8bf6b42214431b241@varnish-cache.org>

#1506: Make better use of Content-Length information: Avoid chunked responses,
more control over Range handling
--------------------------+----------------------------------
 Reporter:  DonMacAskill  |       Owner:  phk
     Type:  defect        |      Status:  new
 Priority:  normal        |   Milestone:  Varnish 4.0 release
Component:  varnishd      |     Version:  4.0.0
 Severity:  critical      |  Resolution:
 Keywords:                |
--------------------------+----------------------------------

Comment (by r):

 The b2b6e3 change fixes one problem, but it seems there is another
 problem.
 We observe Varnish occasionally trying to (unsuccessfully) send a chunked
 response even if beresp.do_stream = false.  When this happens, Varnish
 abruptly closes the connection with no payload being sent.

 From a rather quick code inspection, it seems the bug is a race condition
 between threads.  Here is a more detailed description of what is going on:

 CNT_Request() in cache_req_fsm.c processes the request by going through
 the
 different states of the FSM.  In a case of cache miss, cnt_miss() is
 entered
 which calls VBF_Fetch().  This routine starts fetching the object
 concurrently
 in a separate thread:

 https://www.varnish-
 cache.org/trac/browser/bin/varnishd/cache/cache_fetch.c?rev=bfe7cd198d07ab2197f7d178b08df0caa5e6b7a3#L917

 The caller waits only for the partial fetch i.e. it waits for the
 BOS_STREAM
 state which is set and signalled on vbf_stp_fetch().  Then in continues,
 while
 the fetch is still in progress.  The FSM  eventually reaches cnt_deliver()
 routine which acquires a reference to req->obj->objcore->busyobj and calls
 V1D_Deliver():

 https://www.varnish-
 cache.org/trac/browser/bin/varnishd/cache/cache_req_fsm.c?rev=bfe7cd198d07ab2197f7d178b08df0caa5e6b7a3#L169

 The busyobj is cleared when vbf_fetch_thread() calls HSH_Complete(),
 therefore
 it is volatile when the reference is being acquired; i.e. the fetch thread
 may
 or may not have completed its fetch.  When it is not, the following check
 in
 V1D_Deliver() fails:

 https://www.varnish-
 cache.org/trac/browser/bin/varnishd/cache/cache_http1_deliver.c?rev=bfe7cd198d07ab2197f7d178b08df0caa5e6b7a3#L251

 This results in RES_CHUNKED being set and eventual failure as described in
 the beginning.  Note: the code inspection was done on 4.0.2 source code.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1506#comment:8>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct 16 14:50:55 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 16 Oct 2014 14:50:55 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.369dd589e7705587b7d64bbf4590b670@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+--------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by eitch):

 I'm also getting the same panic messages several times today (and only
 today, even if I was using 4.0.2 since last week and 4.0.1 since a month
 ago).

 VMODs: director, std
 System: Debian GNU/Linux 7.6 (wheezy)

 {{{
 Last panic at: Thu, 16 Oct 2014 14:35:44 GMT
 Assert error in SES_ScheduleReq(), cache/cache_session.c line 229:
   Condition((sp)->magic == 0x2c2f9c5a) not true.
 thread = (cache-worker)
 ident = Linux,3.2.0-4-amd64,x86_64,-sfile,-smalloc,-hclassic,epoll
 Backtrace:
   0x434225: /usr/sbin/varnishd() [0x434225]
   0x43cf3d: /usr/sbin/varnishd(SES_ScheduleReq+0x16d) [0x43cf3d]
   0x4263f8: /usr/sbin/varnishd() [0x4263f8]
   0x427a3a: /usr/sbin/varnishd(HSH_DerefObjCore+0xba) [0x427a3a]
   0x427d74: /usr/sbin/varnishd(HSH_DerefObj+0x34) [0x427d74]
   0x4382d5: /usr/sbin/varnishd() [0x4382d5]
   0x4387d1: /usr/sbin/varnishd(CNT_Request+0x111) [0x4387d1]
   0x42e60b: /usr/sbin/varnishd(HTTP1_Session+0x77b) [0x42e60b]
   0x43c848: /usr/sbin/varnishd() [0x43c848]
   0x4370e3: /usr/sbin/varnishd(Pool_Work_Thread+0x373) [0x4370e3]
 req = 0x7f2e2d0ea020 {
   sp = 0x7f571709d120, vxid = 1074790429,  step = R_STP_DELIVER,
   req_body = R_BODY_NONE,
   err_code = 200, err_reason = (null),
   restarts = 0, esi_level = 0
   sp = 0x7f571709d120 {
     fd = 123, vxid = 1048591,
     client = 201.6.6.196 43675,
     step = S_STP_WORKING,
   },
   worker = 0x7f5724c0ec50 {
     ws = 0x7f5724c0ee68 {
       id = "wrk",
       {s,f,r,e} = {0x7f5724c0e450,0x7f5724c0e450,(nil),+2048},
     },
   VCL::method = 0x0,
   VCL::return = restart,
   },
   ws = 0x7f2e2d0ea1b8 {
     id = "req",
     {s,f,r,e} = {0x7f2e2d0ec010,+1936,(nil),+57360},
   },
   http[req] = {
     ws = 0x7f2e2d0ea1b8[req]
       "GET",
       "/some_url?page=7",
       "HTTP/1.1",
       "Accept: text/html, application/xhtml+xml, */*",
       "Referer: http://some_url?page=6",
       "Accept-Language: pt-BR",
       "User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1;
 Trident/5.0)",
       "TE:  chunked;q=1.0",
       "Connection: TE",
       "Host: some_domain",
       "Pragma: no-cache",
       "Cache-Control: no-cache, max-age=0",
       "Connection: keep-alive",
       "X-Forwarded-For: 186.204.38.4, 201.6.6.196, 201.6.6.196",
       "Accept-Encoding: gzip",
   },
   http[resp] = {
     ws = 0x7f2e2d0ea1b8[req]
       "HTTP/1.1",
       "200",
       "OK",
       "Content-Type: text/html; charset=utf-8",
       "ETag: "-897655702"",
       "Vary: Accept-Encoding",
       "Content-Encoding: gzip",
       "Date: Thu, 16 Oct 2014 14:35:43 GMT",
       "X-Varnish: 1048605",
       "Age: 0",
       "Via: 1.1 varnish-v4",
   },
   vcl = {
     srcname = {
       "input",
       "Builtin",
     },
   },
 },
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1607#comment:10>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Oct 16 15:41:48 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 16 Oct 2014 15:41:48 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.98cf9edbb0f38fc02e23b21f8386bcb1@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+--------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by coredump):

 I tried increasing workspace_session and will see how it behaves. The
 random nature of those crashes aren't very conducting to experiments.
 Yesterday I had 1 panic, the day before I had 4 in less than 2 hours.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1607#comment:11>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 20 09:13:19 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 20 Oct 2014 09:13:19 -0000
Subject: [Varnish] #1506: Make better use of Content-Length information:
 Avoid chunked responses, more control over Range handling
In-Reply-To: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org>
References: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org>
Message-ID: <065.b8669faea325b1e7bca1bce31eccadd8@varnish-cache.org>

#1506: Make better use of Content-Length information: Avoid chunked responses,
more control over Range handling
--------------------------+----------------------------------
 Reporter:  DonMacAskill  |       Owner:  phk
     Type:  defect        |      Status:  new
 Priority:  normal        |   Milestone:  Varnish 4.0 release
Component:  varnishd      |     Version:  4.0.0
 Severity:  critical      |  Resolution:
 Keywords:                |
--------------------------+----------------------------------

Comment (by phk):

 "We observe Varnish occasionally trying to (unsuccessfully) send a chunked
 response even if beresp.do_stream = false. When this happens, Varnish
 abruptly closes the connection with no payload being sent. "

 I belive this is fixed now (1e639d1c41b0be6af3007b3b832ba8829655b00e)

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1506#comment:9>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 20 10:08:52 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 20 Oct 2014 10:08:52 -0000
Subject: [Varnish] #1406: Setting a header to a falsy value than getting
 it returns true
In-Reply-To: <053.67b679cfde5eb48e50df6e81d4e36d86@varnish-cache.org>
References: <053.67b679cfde5eb48e50df6e81d4e36d86@varnish-cache.org>
Message-ID: <068.d95dae036c09f1a59aa8b21a0d65c9e9@varnish-cache.org>

#1406: Setting a header to a falsy value than getting it returns true
-----------------------------+-----------------------
 Reporter:  brandonwamboldt  |       Owner:  lkarsten
     Type:  defect           |      Status:  closed
 Priority:  high             |   Milestone:
Component:  varnishd         |     Version:  3.0.4
 Severity:  normal           |  Resolution:  fixed
 Keywords:                   |
-----------------------------+-----------------------
Changes (by lkarsten):

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


Comment:

 Added to doc/changes.rst in 3.0. Closing.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1406#comment:6>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 20 11:03:47 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 20 Oct 2014 11:03:47 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.5b69c63b3e25ea6c5ce9767c6b2a80aa@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+--------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by lkarsten):

 Reproduced this on fryer. 4.0 branch. default_(keep|grace)=0,
 default_ttl=2s. 1600 concurrent connections hitting the same ~1MB object.

 Crashes within 5-10 seconds.
 {{{
 Last panic at: Mon, 20 Oct 2014 11:01:15 GMT
 Assert error in SES_ScheduleReq(), cache/cache_session.c line 229:
   Condition((sp)->magic == 0x2c2f9c5a) not true.
 thread = (cache-worker)
 ident = Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
   0x43c236: pan_backtrace+0x19
   0x43c547: pan_ic+0x1e9
   0x4477aa: SES_ScheduleReq+0xf5
   0x42bfc0: hsh_rush+0x273
   0x42d3bc: HSH_DerefObjCore+0x28f
   0x42d126: HSH_DerefObj+0xe8
   0x440cf4: cnt_deliver+0x93f
   0x443f2f: CNT_Request+0x529
   0x434aa0: HTTP1_Session+0x427
   0x446ee7: ses_req_pool_task+0x166
 req = 0x7f0590002360 {
   sp = 0x7f0590001d00, vxid = 1077673986,  step = R_STP_DELIVER,
   req_body = R_BODY_NONE,
   restarts = 0, esi_level = 0
   sp = 0x7f0590001d00 {
     fd = 209, vxid = 3932161,
     client = 194.31.39.161 44604,
     step = S_STP_WORKING,
   },
   worker = 0x7f05a7515c50 {
     ws = 0x7f05a7515e68 {
       id = "wrk",
       {s,f,r,e} = {0x7f05a7515400,0x7f05a7515400,(nil),+2048},
     },
   VCL::method = 0x0,
   VCL::return = deliver,
   },
   ws = 0x7f05900024f8 {
     id = "req",
     {s,f,r,e} = {0x7f0590004350,+192,(nil),+57360},
   },
   http[req] = {
     ws = 0x7f05900024f8[req]
       "GET",
       "/cacheabledata/set_medialibrary1/file82.bin",
       "HTTP/1.1",
       "Host: localhost",
       "Connection: close",
       "X-Forwarded-For: 194.31.39.161",
   },
   http[resp] = {
     ws = 0x7f05900024f8[req]
       "HTTP/1.1",
       "200",
       "OK",
       "Date: Mon, 20 Oct 2014 11:01:12 GMT",
       "Server: Apache/2.2.22 (Ubuntu)",
       "Last-Modified: Wed, 18 Sep 2013 10:27:01 GMT",
       "ETag: "824677-fd530-4e6a5e0c7307b"",
       "Cache-Control: max-age=31104000",
       "Expires: Thu, 15 Oct 2015 11:01:12 GMT",
       "Content-Type: application/octet-stream",
       "X-Varnish: 3932162 1671171",
       "Age: 0",
       "Via: 1.1 varnish-v4",
       "Content-Length: 1037616",
       "Connection: close",
       "Accept-Ranges: bytes",
   },
   vcl = {
     srcname = {
       "input",
       "Builtin",
     },
   },
 },
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1607#comment:12>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 20 11:07:11 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 20 Oct 2014 11:07:11 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.42b5c4bdd32060984c2a148574983309@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+--------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by lkarsten):

 Same behaviour on master, with workspace_session=1k.

 {{{
 Last panic at: Mon, 20 Oct 2014 11:06:25 GMT
 Assert error in SES_ScheduleReq(), cache/cache_session.c line 233:
   Condition((sp)->magic == 0x2c2f9c5a) not true.
 thread = (cache-worker)
 version = varnish-trunk revision 7b3bfa0
 ident = Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
   0x43b37b: pan_backtrace+0x19
   0x43b6ac: pan_ic+0x209
   0x444c5b: SES_ScheduleReq+0xf5
   0x42dae5: hsh_rush+0x2e1
   0x42ec79: HSH_DerefObjCore+0x2c9
   0x440252: cnt_deliver+0x8ed
   0x443226: CNT_Request+0x53f
   0x4607ac: HTTP1_Session+0x413
   0x444321: ses_req_pool_task+0x166
   0x43db3d: Pool_Work_Thread+0x503
 req = 0x7f7ae4034990 {
   sp = 0x7f7ae40344f0, vxid = 2785284,  step = R_STP_DELIVER,
   req_body = R_BODY_NONE,
   restarts = 0, esi_level = 0
   sp = 0x7f7ae40344f0 {
     fd = 247, vxid = 2785283,
     client = 194.31.39.161 46478,
     step = S_STP_WORKING,
   },
   worker = 0x7f7b05d1fc20 {
     stack = {0x7f7b05d20000 -> 0x7f7b05d14000}
     ws = 0x7f7b05d1fe30 {
       id = "wrk",
       {s,f,r,e} = {0x7f7b05d1f3d0,0x7f7b05d1f3d0,(nil),+2040},
     },
   VCL::method = DELIVER,
   VCL::return = deliver,
   VCL::methods = {HIT, DELIVER},
   },
   ws = 0x7f7ae4034b50 {
     id = "req",
     {s,f,r,e} = {0x7f7ae40369a8,+192,(nil),+57312},
   },
   http[req] = {
     ws = 0x7f7ae4034b50[req]
       "GET",
       "/cacheabledata/set_medialibrary1/file82.bin",
       "HTTP/1.1",
       "Host: localhost",
       "Connection: close",
       "X-Forwarded-For: 194.31.39.161",
   },
   http[resp] = {
     ws = 0x7f7ae4034b50[req]
       "HTTP/1.1",
       "200",
       "OK",
       "Date: Mon, 20 Oct 2014 11:06:22 GMT",
       "Server: Apache/2.2.22 (Ubuntu)",
       "Last-Modified: Wed, 18 Sep 2013 10:27:01 GMT",
       "ETag: "824677-fd530-4e6a5e0c7307b"",
       "Cache-Control: max-age=31104000",
       "Expires: Thu, 15 Oct 2015 11:06:22 GMT",
       "Content-Type: application/octet-stream",
       "X-Varnish: 2785284 3964931",
       "Age: 1",
       "Via: 1.1 varnish-v4",
       "Content-Length: 1037616",
       "Connection: close",
       "Accept-Ranges: bytes",
   },
   vcl = {
     srcname = {
       "input",
       "Builtin",
     },
   },
 },

 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1607#comment:13>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 20 12:22:24 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 20 Oct 2014 12:22:24 -0000
Subject: [Varnish] #1607: Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229
In-Reply-To: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
References: <046.9e6bd8d750958a8524136f038db2e568@varnish-cache.org>
Message-ID: <061.ae44360e94e386710bd2042891bb6f22@varnish-cache.org>

#1607: Assert error in SES_ScheduleReq(), cache/cache_session.c line 229
----------------------+---------------------
 Reporter:  coredump  |       Owner:  phk
     Type:  defect    |      Status:  closed
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:  fixed
 Keywords:            |
----------------------+---------------------
Changes (by Poul-Henning Kamp <phk@?>):

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


Comment:

 In [9a2a221c713b7329231d7a1b9e996a4a41eedcf2]:
 {{{
 #!CommitTicketReference repository=""
 revision="9a2a221c713b7329231d7a1b9e996a4a41eedcf2"
 Fix the leaking req on failure to put a waiting-list session back
 in play in a way that does not lead to panics.

 Spotted by:     Martin
 Fixes           #1607
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1607#comment:14>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 20 13:48:26 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 20 Oct 2014 13:48:26 -0000
Subject: [Varnish] #1612: Bug with Transfer-Encoding and zero-byte chunks
 (and keep-alive)
Message-ID: <046.d77b4e9b9c077f0f582e94e48b4803b2@varnish-cache.org>

#1612: Bug with Transfer-Encoding and zero-byte chunks (and keep-alive)
----------------------+----------------------
 Reporter:  zviratko  |       Type:  defect
   Status:  new       |   Priority:  normal
Milestone:            |  Component:  varnishd
  Version:  4.0.1     |   Severity:  normal
 Keywords:            |
----------------------+----------------------
 Varnish should not enable keep-alive unless the response is either chunked
 or has a Content-Length - if neither condition is met, there is no way for
 the client to tell if it got the data.

 What I see

 1) client makes a request:

 -   ReqMethod      GET
 -   ReqURL         /aden_prace/ad/86e3d6a0-239f-4cef-a52a-
 f50978c3fd95/orders/item
 -   ReqProtocol    HTTP/1.1
 -   ReqHeader      Host: Aden

 2) varnish makes a request:

 -   BereqMethod    GET
 -   BereqURL       /aden_prace/ad/86e3d6a0-239f-4cef-a52a-
 f50978c3fd95/orders/item
 -   BereqProtocol  HTTP/1.1
 -   BereqHeader    Host: Aden

 (so far so good)

 3) varnish gets a reply:

  BerespProtocol HTTP/1.1
 -   BerespStatus   200
 -   BerespReason   OK
 -   BerespHeader   Server: Apache-Coyote/1.1
 -   BerespHeader   Cache-Control: no-cache, no-transform
 -   BerespHeader   Content-Type: text/plain
 -   BerespHeader   Transfer-Encoding: chunked
 -   BerespHeader   Date: Mon, 20 Oct 2014 10:55:44 GMT
 -   TTL            RFC 30 -1 -1 1413802545 1413802545 1413802544 0 0
 -   VCL_call       BACKEND_RESPONSE
 -   BerespHeader   X-BE: aden01
 -   TTL            VCL 120 10 0 1413802545
 -   VCL_return     deliver
 -   Storage        malloc Transient
 -   ObjProtocol    HTTP/1.1
 -   ObjStatus      200
 -   ObjReason      OK
 -   ObjHeader      Server: Apache-Coyote/1.1
 -   ObjHeader      Cache-Control: no-cache, no-transform
 -   ObjHeader      Content-Type: text/plain
 -   ObjHeader      Date: Mon, 20 Oct 2014 10:55:44 GMT
 -   ObjHeader      X-BE: aden01
 -   Fetch_Body     2 chunked stream
 -   BackendReuse   47 aden01(10.0.36.31,,8080)
 -   Timestamp      BerespBody: 1413802544.791182 0.007085 0.000257
 -   Length         0

 emulated with telnet to see the body:

 GET /aden_prace/ad/86e3d6a0-239f-4cef-a52a-f50978c3fd95/orders/item
 HTTP/1.1
 Host: aden

 HTTP/1.1 200 OK
 Server: Apache-Coyote/1.1
 Cache-Control: no-cache, no-transform
 Content-Type: text/plain
 Transfer-Encoding: chunked
 Date: Mon, 20 Oct 2014 13:32:24 GMT

 0

 4) varnish sends a response, note that there is no Content-Length or T-E:
 Chunked:

  RespProtocol   HTTP/1.1
 -   RespStatus     200
 -   RespReason     OK
 -   RespHeader     Server: Apache-Coyote/1.1
 -   RespHeader     Cache-Control: no-cache, no-transform
 -   RespHeader     Content-Type: text/plain
 -   RespHeader     Date: Mon, 20 Oct 2014 10:55:44 GMT
 -   RespHeader     X-BE: aden01
 -   RespHeader     X-Varnish: 1442041
 -   RespHeader     Age: 0
 -   RespHeader     Via: 1.1 varnish-v4
 -   VCL_call       DELIVER
 -   RespHeader     X-Vokurka: not found!
 -   RespHeader     X-Server: Skrutener Zviratko 31.5
 -   VCL_return     deliver
 -   Timestamp      Process: 1413802544.791202 1.451451 0.000036
 -   Debug          "RES_MODE 2"
 -   RespHeader     Connection: keep-alive
 -   RespHeader     Accept-Ranges: bytes
 -   Timestamp      Resp: 1413802544.791260 1.451510 0.000058
 -   Debug          "XXX REF 1"
 -   ReqAcct        92 0 92 315 0 315
 -   End

 How this looks with telnet:

 GET /aden_prace/ad/86e3d6a0-239f-4cef-a52a-f50978c3fd95/orders/item
 HTTP/1.1
 Host: aden

 HTTP/1.1 200 OK
 Server: Apache-Coyote/1.1
 Cache-Control: no-cache, no-transform
 Content-Type: text/plain
 Date: Mon, 20 Oct 2014 13:37:52 GMT
 X-BE: aden01
 X-Varnish: 377168
 Age: 0
 Via: 1.1 varnish-v4
 X-Vokurka: not found!
 X-Server: Skrutener Zviratko 31.5
 Connection: keep-alive
 Accept-Ranges: bytes

 <hangs in there until timeout!!!>

 -------------------

 Varnish doesn't even send the 0-byte chunk it got from the backend, so
 client is kept waiting for the body to arrive (or in effect the connection
 to close).

 I believe this is a serious bug. I didn't notice it until I raised all the
 timeouts to something like 300s and encountered timeout in applications
 waiting for the data.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1612>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 20 14:36:08 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 20 Oct 2014 14:36:08 -0000
Subject: [Varnish] #1613: keep-alive is enabled even if req.http.Connection
 is set to "close"
Message-ID: <046.7db229749aec5a5a59468cb8dc65960a@varnish-cache.org>

#1613: keep-alive is enabled even if req.http.Connection is set to "close"
----------------------+----------------------
 Reporter:  zviratko  |       Type:  defect
   Status:  new       |   Priority:  normal
Milestone:            |  Component:  varnishd
  Version:  4.0.1     |   Severity:  normal
 Keywords:            |
----------------------+----------------------
 Relevant part of VCL (tried as workaround for #1612):

 sub vcl_recv {
     if (!req.http.Connection ~ "keep-alive") {
         set req.http.Connection = "close";
     }
 }

 varnishlog shows Connection: close header (not present in the original
 request)
 but still uses keep-alive on response

 *   << Request  >> 229454
 -   Begin          req 229452 rxreq
 -   Timestamp      Start: 1413815519.025922 0.000000 0.000000
 -   Timestamp      Req: 1413815519.759714 0.733793 0.733793
 -   ReqStart       10.1.0.1 53459
 -   ReqMethod      GET
 -   ReqURL         /aden_prace/ad/86e3d6a0-239f-4cef-a52a-
 f50978c3fd95/orders/item
 -   ReqProtocol    HTTP/1.1
 -   ReqHeader      Host: aden
 -   ReqHeader      X-Forwarded-For: 10.1.0.1
 -   VCL_call       RECV
 -   ReqHeader      X-Hash-Key: 10.1.0.1
 -   ReqHeader      Connection: close
 -   VCL_acl        MATCH lbaden "10.0.36.222"
 -   ReqHeader      X-VIP: aden
 -   ReqHeader      X-Rule: setbackendaden;
 -   VCL_acl        NO_MATCH lbasmt
 -   VCL_acl        NO_MATCH lblang
 -   VCL_acl        NO_MATCH lbswift
 -   VCL_return     hash
 -   VCL_call       HASH
 -   VCL_return     lookup
 -   Debug          "XXXX HIT-FOR-PASS"
 -   HitPass        2147745808
 -   VCL_call       PASS
 -   VCL_return     fetch
 -   Link           bereq 229455 pass
 -   Timestamp      Fetch: 1413815519.766031 0.740109 0.006316
 -   RespProtocol   HTTP/1.1
 -   RespStatus     200
 -   RespReason     OK
 -   RespHeader     Server: Apache-Coyote/1.1
 -   RespHeader     Cache-Control: no-cache, no-transform
 -   RespHeader     Content-Type: text/plain
 -   RespHeader     Date: Mon, 20 Oct 2014 14:31:59 GMT
 -   RespHeader     X-BE: aden01
 -   RespHeader     X-Varnish: 229454
 -   RespHeader     Age: 0
 -   RespHeader     Via: 1.1 varnish-v4
 -   VCL_call       DELIVER
 -   RespHeader     X-Vokurka: not found!
 -   RespHeader     X-Server: Skrutener Zviratko 31.5
 -   VCL_return     deliver
 -   Timestamp      Process: 1413815519.766071 0.740149 0.000040
 -   Debug          "RES_MODE 2"
 -   RespHeader     Connection: keep-alive
 -   RespHeader     Accept-Ranges: bytes
 -   Timestamp      Resp: 1413815519.766112 0.740190 0.000041
 -   Debug          "XXX REF 1"
 -   ReqAcct        92 0 92 314 0 314
 -   End

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1613>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 20 15:38:53 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 20 Oct 2014 15:38:53 -0000
Subject: [Varnish] #1612: Bug with Transfer-Encoding and zero-byte
 chunks (and keep-alive)
In-Reply-To: <046.d77b4e9b9c077f0f582e94e48b4803b2@varnish-cache.org>
References: <046.d77b4e9b9c077f0f582e94e48b4803b2@varnish-cache.org>
Message-ID: <061.5c3b44d4f58da038ff061ffee306336a@varnish-cache.org>

#1612: Bug with Transfer-Encoding and zero-byte chunks (and keep-alive)
----------------------+--------------------
 Reporter:  zviratko  |       Owner:
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.1
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by daghf):

 I'm able to reproduce this, when

 a. The request is handled as a pass, and
 b. the backend responds with an empty chunked response (just the 0 chunk),

 Varnish fails to specify a content-length or a transfer encoding in the
 response, thus breaking keep-alive.

 vtc test case attached.

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



From varnish-bugs at varnish-cache.org  Mon Oct 20 22:38:29 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 20 Oct 2014 22:38:29 -0000
Subject: [Varnish] #1614: Missing support for pcre in substitution string
Message-ID: <044.05bde7284f34eb92227666a9a0ee1aad@varnish-cache.org>

#1614: Missing support for pcre in substitution string
--------------------+----------------------
 Reporter:  anders  |       Type:  defect
   Status:  new     |   Priority:  normal
Milestone:          |  Component:  varnishd
  Version:  3.0.5   |   Severity:  normal
 Keywords:  pcre    |
--------------------+----------------------
 It seems Varnish fails to evaluate PCRE escapes in the substitution
 string. For example if I want to insert odd characters using a hex escape.
 Using Perl from CLI it works (but is displayed oddly as I have a UTF-8
 terminal):

 anders at noname:~$ echo hei | perl -p -e "s@^@\x{e5}@"
 ?hei

 Consider the following VCL:

                 std.log("DEBUG: url is: " + req.url);
                 set req.url = regsub(req.url, "^", "/f\x{e5}");
                 std.log("DEBUG: url is now: " + req.url);

 Then I get:

   854 VCL_Log      c DEBUG: url is: /
   854 VCL_Log      c DEBUG: url is now: /fx{e5}/

 According to http://www.pcre.org/pcre.txt it should work:

 \x{hhh..} character with hex code hhh.. (non-JavaScript mode)

 This is what I need to do when the backend has an odd character in its
 urls. :-)

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1614>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 20 22:42:30 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 20 Oct 2014 22:42:30 -0000
Subject: [Varnish] #1614: Missing support for pcre in substitution string
In-Reply-To: <044.05bde7284f34eb92227666a9a0ee1aad@varnish-cache.org>
References: <044.05bde7284f34eb92227666a9a0ee1aad@varnish-cache.org>
Message-ID: <059.736ce4b7b052300bc11795d419e67910@varnish-cache.org>

#1614: Missing support for pcre in substitution string
----------------------+--------------------
 Reporter:  anders    |       Owner:
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  3.0.5
 Severity:  normal    |  Resolution:
 Keywords:  pcre      |
----------------------+--------------------

Comment (by anders):

 Repeating VCL again with code block.

 {{{
 std.log("DEBUG: url is: " + req.url);
 set req.url = regsub(req.url, "^", "/f\x{e5}");
 std.log("DEBUG: url is now: " + req.url);
 }}}

 And command line example:

 {{{
 anders at noname:~$ echo hei | perl -p -e "s@^@\x{e5}@"
 ?hei
 }}}

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



From varnish-bugs at varnish-cache.org  Tue Oct 21 07:50:42 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 21 Oct 2014 07:50:42 -0000
Subject: [Varnish] #1615: Panic message:#012Assert error in
 vbf_fetch_thread(), cache/cache_fetch.c line 842
Message-ID: <046.8e53f7b24c5434e7c650d99fba08bbe3@varnish-cache.org>

#1615: Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c
line 842
------------------------------+--------------------
 Reporter:  xieyugui          |       Type:  defect
   Status:  new               |   Priority:  normal
Milestone:  Varnish 4.0-TP2   |  Component:  build
  Version:  unknown           |   Severity:  normal
 Keywords:  vbf_fetch_thread  |
------------------------------+--------------------
 Oct 19 10:07:03 localhost /xxx/varnish/var/varnish/cache[19719]: Child
 (26298) not responding to CLI, killing it.
 Oct 19 10:07:04 localhost /xxx/varnish/var/varnish/cache[19719]: Child
 (26298) died signal=6
 Oct 19 10:07:04 localhost /xxx/varnish/var/varnish/cache[19719]: Child
 (26298) Panic message:#012Assert error in vbf_fetch_thread(),
 cache/cache_fetch.c line 842:#012  Condition(uu == bo->fetch_obj->len) not
 true.#012thread = (cache-worker)#012ident =
 Linux,2.6.32-358.el6.x86_64,x86_64,-smalloc,-sfile,-sfile,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x4310e5: pan_ic+0xc5#012  0x41fac4: vbf_fetch_thread+0xbf4#012  0x433b87:
 Pool_Work_Thread+0x357#012  0x4467d9: wrk_thread_real+0xb9#012
 0x7ff3472959d1: /lib64/libpthread.so.0(+0x79d1) [0x7ff3472959d1]#012
 0x7ff346fe286d: /lib64/libc.so.6(clone+0x6d) [0x7ff346fe286d]#012  busyobj
 = 0x7f9b4fe8f970 {#012    ws = 0x7f9b4fe8fa30 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f9b4fe93f98,+480,(nil),+113112},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_pass#012
 is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 3 (length),#012    },#012    ws =
 0x7f9b4fe8fbc0 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f9aae9d30a0,+232,(nil),+232},#012    },#012  objcore (FETCH) =
 0x7feb12d649f0 {#012    refcnt = 1#012    flags = 0x104#012    objhead =
 0x11d8ea0#012  }#012  obj (FETCH) = 0x7f9aae9d2ee0 {#012    vxid =
 2200159394,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "400",#012        "Bad Request",#012
 "Server: nginx",#012        "Date: Sun, 19 Oct 2014 02:07:00 GMT",#012
 "Content-Type: text/html; charset=utf-8",#012        "Content-Length:
 166",#012        "Domain-Id: 061fa35c95a8cc19b782c6",#012        "X-TAN14:
 ORIGIN",#012        "x-storage: mem",#012    },#012    len = 166,#012
 store = {#012    },#012  },#012  }#012

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1615>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Oct 21 07:55:51 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 21 Oct 2014 07:55:51 -0000
Subject: [Varnish] #1615: Panic message:#012Assert error in
 vbf_fetch_thread(), cache/cache_fetch.c line 842
In-Reply-To: <046.8e53f7b24c5434e7c650d99fba08bbe3@varnish-cache.org>
References: <046.8e53f7b24c5434e7c650d99fba08bbe3@varnish-cache.org>
Message-ID: <061.8bce28d5eac493558a101eb1dd1bb7be@varnish-cache.org>

#1615: Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c
line 842
------------------------------+------------------------------
 Reporter:  xieyugui          |       Owner:
     Type:  defect            |      Status:  new
 Priority:  normal            |   Milestone:  Varnish 4.0-TP2
Component:  build             |     Version:  unknown
 Severity:  normal            |  Resolution:
 Keywords:  vbf_fetch_thread  |
------------------------------+------------------------------

Comment (by xieyugui):

 my varnish version:
 Varnish Cache 4.0.2
 Release date:
 8 October, 2014

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



From varnish-bugs at varnish-cache.org  Tue Oct 21 08:10:18 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 21 Oct 2014 08:10:18 -0000
Subject: [Varnish] #1615: Panic message:#012Assert error in
 vbf_fetch_thread(), cache/cache_fetch.c line 842
In-Reply-To: <046.8e53f7b24c5434e7c650d99fba08bbe3@varnish-cache.org>
References: <046.8e53f7b24c5434e7c650d99fba08bbe3@varnish-cache.org>
Message-ID: <061.3ff7e7ff4cf71db0a5f6a03cb34a3f85@varnish-cache.org>

#1615: Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c
line 842
------------------------------+--------------------
 Reporter:  xieyugui          |       Owner:
     Type:  defect            |      Status:  new
 Priority:  normal            |   Milestone:  Later
Component:  build             |     Version:  4.0.2
 Severity:  normal            |  Resolution:
 Keywords:  vbf_fetch_thread  |
------------------------------+--------------------
Changes (by fgsch):

 * version:  unknown => 4.0.2
 * milestone:  Varnish 4.0-TP2 => Later


Old description:

> Oct 19 10:07:03 localhost /xxx/varnish/var/varnish/cache[19719]: Child
> (26298) not responding to CLI, killing it.
> Oct 19 10:07:04 localhost /xxx/varnish/var/varnish/cache[19719]: Child
> (26298) died signal=6
> Oct 19 10:07:04 localhost /xxx/varnish/var/varnish/cache[19719]: Child
> (26298) Panic message:#012Assert error in vbf_fetch_thread(),
> cache/cache_fetch.c line 842:#012  Condition(uu == bo->fetch_obj->len)
> not true.#012thread = (cache-worker)#012ident =
> Linux,2.6.32-358.el6.x86_64,x86_64,-smalloc,-sfile,-sfile,-smalloc,-hcritbit,epoll#012Backtrace:#012
> 0x4310e5: pan_ic+0xc5#012  0x41fac4: vbf_fetch_thread+0xbf4#012
> 0x433b87: Pool_Work_Thread+0x357#012  0x4467d9: wrk_thread_real+0xb9#012
> 0x7ff3472959d1: /lib64/libpthread.so.0(+0x79d1) [0x7ff3472959d1]#012
> 0x7ff346fe286d: /lib64/libc.so.6(clone+0x6d) [0x7ff346fe286d]#012
> busyobj = 0x7f9b4fe8f970 {#012    ws = 0x7f9b4fe8fa30 {#012      id =
> "bo",#012      {s,f,r,e} = {0x7f9b4fe93f98,+480,(nil),+113112},#012
> },#012  refcnt = 1#012  retries = 0#012  failed = 0#012  state = 3#012
> is_do_pass#012    is_uncacheable#012    is_abandon#012
> is_is_gunzip#012    is_should_close#012    bodystatus = 3 (length),#012
> },#012    ws = 0x7f9b4fe8fbc0 {#012      id = "obj",#012      {s,f,r,e} =
> {0x7f9aae9d30a0,+232,(nil),+232},#012    },#012  objcore (FETCH) =
> 0x7feb12d649f0 {#012    refcnt = 1#012    flags = 0x104#012    objhead =
> 0x11d8ea0#012  }#012  obj (FETCH) = 0x7f9aae9d2ee0 {#012    vxid =
> 2200159394,#012    http[obj] = {#012      ws = (nil)[]#012
> "HTTP/1.1",#012        "400",#012        "Bad Request",#012
> "Server: nginx",#012        "Date: Sun, 19 Oct 2014 02:07:00 GMT",#012
> "Content-Type: text/html; charset=utf-8",#012        "Content-Length:
> 166",#012        "Domain-Id: 061fa35c95a8cc19b782c6",#012
> "X-TAN14: ORIGIN",#012        "x-storage: mem",#012    },#012    len =
> 166,#012    store = {#012    },#012  },#012  }#012

New description:

 {{{
 Oct 19 10:07:03 localhost /xxx/varnish/var/varnish/cache[19719]: Child
 (26298) not responding to CLI, killing it.
 Oct 19 10:07:04 localhost /xxx/varnish/var/varnish/cache[19719]: Child
 (26298) died signal=6
 Oct 19 10:07:04 localhost /xxx/varnish/var/varnish/cache[19719]: Child
 (26298) Panic message:#012Assert error in vbf_fetch_thread(),
 cache/cache_fetch.c line 842:#012  Condition(uu == bo->fetch_obj->len) not
 true.#012thread = (cache-worker)#012ident =
 Linux,2.6.32-358.el6.x86_64,x86_64,-smalloc,-sfile,-sfile,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x4310e5: pan_ic+0xc5#012  0x41fac4: vbf_fetch_thread+0xbf4#012  0x433b87:
 Pool_Work_Thread+0x357#012  0x4467d9: wrk_thread_real+0xb9#012
 0x7ff3472959d1: /lib64/libpthread.so.0(+0x79d1) [0x7ff3472959d1]#012
 0x7ff346fe286d: /lib64/libc.so.6(clone+0x6d) [0x7ff346fe286d]#012  busyobj
 = 0x7f9b4fe8f970 {#012    ws = 0x7f9b4fe8fa30 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f9b4fe93f98,+480,(nil),+113112},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_pass#012
 is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 3 (length),#012    },#012    ws =
 0x7f9b4fe8fbc0 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f9aae9d30a0,+232,(nil),+232},#012    },#012  objcore (FETCH) =
 0x7feb12d649f0 {#012    refcnt = 1#012    flags = 0x104#012    objhead =
 0x11d8ea0#012  }#012  obj (FETCH) = 0x7f9aae9d2ee0 {#012    vxid =
 2200159394,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "400",#012        "Bad Request",#012
 "Server: nginx",#012        "Date: Sun, 19 Oct 2014 02:07:00 GMT",#012
 "Content-Type: text/html; charset=utf-8",#012        "Content-Length:
 166",#012        "Domain-Id: 061fa35c95a8cc19b782c6",#012        "X-TAN14:
 ORIGIN",#012        "x-storage: mem",#012    },#012    len = 166,#012
 store = {#012    },#012  },#012  }#012
 }}}

--

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



From varnish-bugs at varnish-cache.org  Tue Oct 21 08:15:31 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 21 Oct 2014 08:15:31 -0000
Subject: [Varnish] #1615: Panic message:#012Assert error in
 vbf_fetch_thread(), cache/cache_fetch.c line 842
In-Reply-To: <046.8e53f7b24c5434e7c650d99fba08bbe3@varnish-cache.org>
References: <046.8e53f7b24c5434e7c650d99fba08bbe3@varnish-cache.org>
Message-ID: <061.2ccacef9942b79f8ab22d1f32f0b0444@varnish-cache.org>

#1615: Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c
line 842
------------------------------+--------------------
 Reporter:  xieyugui          |       Owner:
     Type:  defect            |      Status:  new
 Priority:  normal            |   Milestone:  Later
Component:  build             |     Version:  4.0.2
 Severity:  normal            |  Resolution:
 Keywords:  vbf_fetch_thread  |
------------------------------+--------------------
Description changed by fgsch:

Old description:

> {{{
> Oct 19 10:07:03 localhost /xxx/varnish/var/varnish/cache[19719]: Child
> (26298) not responding to CLI, killing it.
> Oct 19 10:07:04 localhost /xxx/varnish/var/varnish/cache[19719]: Child
> (26298) died signal=6
> Oct 19 10:07:04 localhost /xxx/varnish/var/varnish/cache[19719]: Child
> (26298) Panic message:#012Assert error in vbf_fetch_thread(),
> cache/cache_fetch.c line 842:#012  Condition(uu == bo->fetch_obj->len)
> not true.#012thread = (cache-worker)#012ident =
> Linux,2.6.32-358.el6.x86_64,x86_64,-smalloc,-sfile,-sfile,-smalloc,-hcritbit,epoll#012Backtrace:#012
> 0x4310e5: pan_ic+0xc5#012  0x41fac4: vbf_fetch_thread+0xbf4#012
> 0x433b87: Pool_Work_Thread+0x357#012  0x4467d9: wrk_thread_real+0xb9#012
> 0x7ff3472959d1: /lib64/libpthread.so.0(+0x79d1) [0x7ff3472959d1]#012
> 0x7ff346fe286d: /lib64/libc.so.6(clone+0x6d) [0x7ff346fe286d]#012
> busyobj = 0x7f9b4fe8f970 {#012    ws = 0x7f9b4fe8fa30 {#012      id =
> "bo",#012      {s,f,r,e} = {0x7f9b4fe93f98,+480,(nil),+113112},#012
> },#012  refcnt = 1#012  retries = 0#012  failed = 0#012  state = 3#012
> is_do_pass#012    is_uncacheable#012    is_abandon#012
> is_is_gunzip#012    is_should_close#012    bodystatus = 3 (length),#012
> },#012    ws = 0x7f9b4fe8fbc0 {#012      id = "obj",#012      {s,f,r,e} =
> {0x7f9aae9d30a0,+232,(nil),+232},#012    },#012  objcore (FETCH) =
> 0x7feb12d649f0 {#012    refcnt = 1#012    flags = 0x104#012    objhead =
> 0x11d8ea0#012  }#012  obj (FETCH) = 0x7f9aae9d2ee0 {#012    vxid =
> 2200159394,#012    http[obj] = {#012      ws = (nil)[]#012
> "HTTP/1.1",#012        "400",#012        "Bad Request",#012
> "Server: nginx",#012        "Date: Sun, 19 Oct 2014 02:07:00 GMT",#012
> "Content-Type: text/html; charset=utf-8",#012        "Content-Length:
> 166",#012        "Domain-Id: 061fa35c95a8cc19b782c6",#012
> "X-TAN14: ORIGIN",#012        "x-storage: mem",#012    },#012    len =
> 166,#012    store = {#012    },#012  },#012  }#012
> }}}

New description:

 {{{
 Oct 19 10:07:03 localhost /xxx/varnish/var/varnish/cache[19719]: Child
 (26298) not responding to CLI, killing it.
 Oct 19 10:07:04 localhost /xxx/varnish/var/varnish/cache[19719]: Child
 (26298) died signal=6
 Oct 19 10:07:04 localhost /xxx/varnish/var/varnish/cache[19719]: Child
 (26298) Panic message:
 Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 842:
   Condition(uu == bo->fetch_obj->len) not true.
 thread = (cache-worker)
   ident =
 Linux,2.6.32-358.el6.x86_64,x86_64,-smalloc,-sfile,-sfile,-smalloc,-hcritbit,epoll
 Backtrace:
   0x4310e5: pan_ic+0xc5
   0x41fac4: vbf_fetch_thread+0xbf4
   0x433b87: Pool_Work_Thread+0x357
   0x4467d9: wrk_thread_real+0xb9
   0x7ff3472959d1: /lib64/libpthread.so.0(+0x79d1) [0x7ff3472959d1]
   0x7ff346fe286d: /lib64/libc.so.6(clone+0x6d) [0x7ff346fe286d]
   busyobj = 0x7f9b4fe8f970 {
     ws = 0x7f9b4fe8fa30 {
     id = "bo",
       {s,f,r,e} = {0x7f9b4fe93f98,+480,(nil),+113112},
     },
   refcnt = 1
   retries = 0
   failed = 0
   state = 3
     is_do_pass
     is_uncacheable
     is_abandon
     is_is_gunzip
     is_should_close
     bodystatus = 3 (length),
     },
     ws = 0x7f9b4fe8fbc0 {
       id = "obj",
       {s,f,r,e} = {0x7f9aae9d30a0,+232,(nil),+232},
     },
   objcore (FETCH) = 0x7feb12d649f0 {
     refcnt = 1
     flags = 0x104
     objhead = 0x11d8ea0
   }
   obj (FETCH) = 0x7f9aae9d2ee0 {
     vxid = 2200159394,
     http[obj] = {
       ws = (nil)[]
         "HTTP/1.1",
         "400",
         "Bad Request",
         "Server: nginx",
         "Date: Sun, 19 Oct 2014 02:07:00 GMT",
         "Content-Type: text/html; charset=utf-8",
         "Content-Length: 166",
         "Domain-Id: 061fa35c95a8cc19b782c6",
         "X-TAN14: ORIGIN",
         "x-storage: mem",
     },
     len = 166,
     store = {
     },
   },
   }
 }}}

--

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



From varnish-bugs at varnish-cache.org  Tue Oct 21 09:01:33 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 21 Oct 2014 09:01:33 -0000
Subject: [Varnish] #1612: Bug with Transfer-Encoding and zero-byte
 chunks (and keep-alive)
In-Reply-To: <046.d77b4e9b9c077f0f582e94e48b4803b2@varnish-cache.org>
References: <046.d77b4e9b9c077f0f582e94e48b4803b2@varnish-cache.org>
Message-ID: <061.59285abffeaa0ddb16ed7e5f99637756@varnish-cache.org>

#1612: Bug with Transfer-Encoding and zero-byte chunks (and keep-alive)
----------------------+----------------------------------------
 Reporter:  zviratko  |       Owner:  Poul-Henning Kamp <phk@?>
     Type:  defect    |      Status:  closed
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.1
 Severity:  normal    |  Resolution:  fixed
 Keywords:            |
----------------------+----------------------------------------
Changes (by Poul-Henning Kamp <phk@?>):

 * owner:   => Poul-Henning Kamp <phk@?>
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [44a996f4c15c59eda38b263af5de81af5e8cd2fd]:
 {{{
 #!CommitTicketReference repository=""
 revision="44a996f4c15c59eda38b263af5de81af5e8cd2fd"
 Fix a cornercase related to empty pass objects.

 Fixes #1612
 Testcase by:    daghf
 }}}

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



From varnish-bugs at varnish-cache.org  Tue Oct 21 10:25:44 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 21 Oct 2014 10:25:44 -0000
Subject: [Varnish] #1343: Storage file handling is confused if file exists
In-Reply-To: <046.7e806953bab79cec3b63fad3eb7638f4@varnish-cache.org>
References: <046.7e806953bab79cec3b63fad3eb7638f4@varnish-cache.org>
Message-ID: <061.4ef07d483fe99fbe8f31335a8dd62d79@varnish-cache.org>

#1343: Storage file handling is confused if file exists
----------------------+-----------------------------------------------
 Reporter:  lkarsten  |       Owner:  Martin Blix Grydeland <martin@?>
     Type:  defect    |      Status:  closed
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  trunk
 Severity:  minor     |  Resolution:  fixed
 Keywords:            |
----------------------+-----------------------------------------------
Changes (by Martin Blix Grydeland <martin@?>):

 * status:  new => closed
 * owner:   => Martin Blix Grydeland <martin@?>
 * resolution:   => fixed


Comment:

 In [29097215caf53e30e77ccdee17b9fe9317e722f8]:
 {{{
 #!CommitTicketReference repository=""
 revision="29097215caf53e30e77ccdee17b9fe9317e722f8"
 Remove the 80% file system free space check

 This check never worked as intended for several reasons:

 - Didn't take the existing file size into account, causing it to
   succeed on first startup but fail on next

 - Sparse files were not handled, and can't be handled as we don't know
   where in the file a hole could be and whether truncation actually
   would change the number of blocks used at all

 Fixes: #1343
 }}}

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



From varnish-bugs at varnish-cache.org  Tue Oct 21 14:13:43 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 21 Oct 2014 14:13:43 -0000
Subject: [Varnish] #1616: RH packages for varnish4 installs headers at the
 wrong place
Message-ID: <047.10a5b7a71076bf8edeedc8500ef75678@varnish-cache.org>

#1616: RH packages for varnish4 installs headers at the wrong place
------------------------+-----------------------
 Reporter:  mfournier   |       Type:  defect
   Status:  new         |   Priority:  normal
Milestone:              |  Component:  packaging
  Version:  4.0.2       |   Severity:  normal
 Keywords:  rpm redhat  |
------------------------+-----------------------
 Following https://www.varnish-cache.org/installation/redhat on centos 6.

 These files should IMHO go in /usr/include/varnish:

 {{{
 /usr/share/varnish
 /usr/share/varnish/include
 /usr/share/varnish/include/cache
 /usr/share/varnish/include/cache/cache.h
 /usr/share/varnish/include/cache/cache_backend.h
 /usr/share/varnish/include/common
 /usr/share/varnish/include/common/common.h
 /usr/share/varnish/include/common/params.h
 /usr/share/varnish/include/miniobj.h
 /usr/share/varnish/include/vas.h
 /usr/share/varnish/include/vav.h
 /usr/share/varnish/include/vbm.h
 /usr/share/varnish/include/vcl.h
 /usr/share/varnish/include/vcs.h
 /usr/share/varnish/include/vdef.h
 /usr/share/varnish/include/vmod_abi.h
 /usr/share/varnish/include/vqueue.h
 /usr/share/varnish/include/vre.h
 /usr/share/varnish/include/vrt.h
 /usr/share/varnish/include/vrt_obj.h
 /usr/share/varnish/include/vsa.h
 /usr/share/varnish/include/vsb.h
 /usr/share/varnish/include/vsha256.h
 }}}

 This is basically the same issue reported & fixed for debian here:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745902

 Thanks !

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1616>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Oct 22 03:59:18 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 22 Oct 2014 03:59:18 -0000
Subject: [Varnish] #1596: Panic message:#012Assert error in
 vbf_fetch_thread()
In-Reply-To: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org>
References: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org>
Message-ID: <057.96a1f2928a2a713d4591b83e3b473e9b@varnish-cache.org>

#1596: Panic message:#012Assert error in vbf_fetch_thread()
--------------------+----------------------------------
 Reporter:  webi    |       Owner:
     Type:  defect  |      Status:  new
 Priority:  normal  |   Milestone:  Varnish 4.0 release
Component:  build   |     Version:  4.0.1
 Severity:  normal  |  Resolution:
 Keywords:          |
--------------------+----------------------------------

Comment (by xcir):

 Hi,
 I encountered a similar errors.

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



From varnish-bugs at varnish-cache.org  Thu Oct 23 08:41:08 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 23 Oct 2014 08:41:08 -0000
Subject: [Varnish] #1596: Panic message:#012Assert error in
 vbf_fetch_thread()
In-Reply-To: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org>
References: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org>
Message-ID: <057.608fcd6750b4d77a28e632ad88bd6fa8@varnish-cache.org>

#1596: Panic message:#012Assert error in vbf_fetch_thread()
--------------------+----------------------------------
 Reporter:  webi    |       Owner:
     Type:  defect  |      Status:  new
 Priority:  normal  |   Milestone:  Varnish 4.0 release
Component:  build   |     Version:  4.0.1
 Severity:  normal  |  Resolution:
 Keywords:          |
--------------------+----------------------------------

Comment (by Youri_13):

 Hello,
 I have the same problem. Since I turn on esi, the child process has
 crashed several times.
 We are using Varnish 4.0.2 and it seems to occur randomly.

 This are a few of the Panic messages:
 {{{
 Oct 23 04:12:42 wwwbe varnishd[4933]: Child (20828) died signal=6
 Oct 23 04:12:42 wwwbe varnishd[4933]: Child (20828) Panic
 message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line
 842:#012  Condition(uu == bo->fetch_obj->len) not true.#012thread =
 (cache-worker)#012ident =
 Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]#012  0x43b7fd:
 /usr/sbin/varnishd() [0x43b7fd]#012  0x425a9d: /usr/sbin/varnishd()
 [0x425a9d]#012  0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce)
 [0x43e44f]#012  0x456f84: /usr/sbin/varnishd() [0x456f84]#012  0x4570ad:
 /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]#012  0x7f44307ba9d1:
 /lib64/libpthread.so.0(+0x79d1) [0x7f44307ba9d1]#012  0x7f443050786d:
 /lib64/libc.so.6(clone+0x6d) [0x7f443050786d]#012  busyobj =
 0x7f441d08e020 {#012    ws = 0x7f441d08e0e0 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f441d090008,+15504,(nil),+57368},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_esi#012
 is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 3 (length),#012    },#012    ws =
 0x7f441d08e270 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f441b498cb0,+248,(nil),+248},#012    },#012  objcore (FETCH) =
 0x7f441dc2b880 {#012    refcnt = 2#012    flags = 0x4#012    objhead =
 0x7f441dc1a400#012  }#012  obj (FETCH) = 0x7f441b498b00 {#012    vxid =
 2147484163,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "414",#012        "Request-URI Too Large",#012
 "Date: Thu, 23 Oct 2014 02:12:41 GMT",#012        "Server: Apache",#012
 "Content-Length: 250",#012        "Content-Type: text/html;
 charset=iso-8859-1",#012        "Vary: X-UA-Device",#012        "X-Cache-
 ttl: 0.000",#012    },#012    len = 250,#012    store = {#012    },#012
 },#012  }#012
 Oct 23 04:12:42 wwwbe varnishd[4933]: child (21181) Started
 Oct 23 04:12:42 wwwbe varnishd[4933]: Child (21181) said Child starts
 Oct 23 04:13:26 wwwbe varnishd[4933]: Child (21181) died signal=6
 Oct 23 04:13:26 wwwbe varnishd[4933]: Child (21181) Panic
 message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line
 842:#012  Condition(uu == bo->fetch_obj->len) not true.#012thread =
 (cache-worker)#012ident =
 Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]#012  0x43b7fd:
 /usr/sbin/varnishd() [0x43b7fd]#012  0x425a9d: /usr/sbin/varnishd()
 [0x425a9d]#012  0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce)
 [0x43e44f]#012  0x456f84: /usr/sbin/varnishd() [0x456f84]#012  0x4570ad:
 /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]#012  0x7f44307ba9d1:
 /lib64/libpthread.so.0(+0x79d1) [0x7f44307ba9d1]#012  0x7f443050786d:
 /lib64/libc.so.6(clone+0x6d) [0x7f443050786d]#012  busyobj =
 0x7f441d08e020 {#012    ws = 0x7f441d08e0e0 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f441d090008,+16032,(nil),+57368},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_esi#012
 is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 3 (length),#012    },#012    ws =
 0x7f441d08e270 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f441d4167b0,+248,(nil),+248},#012    },#012  objcore (FETCH) =
 0x7f441dc2a700 {#012    refcnt = 2#012    flags = 0x4#012    objhead =
 0x7f441dc2c630#012  }#012  obj (FETCH) = 0x7f441d416600 {#012    vxid =
 2147483693,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "414",#012        "Request-URI Too Large",#012
 "Date: Thu, 23 Oct 2014 02:13:25 GMT",#012        "Server: Apache",#012
 "Content-Length: 250",#012        "Content-Type: text/html;
 charset=iso-8859-1",#012        "Vary: X-UA-Device",#012        "X-Cache-
 ttl: 0.000",#012    },#012    len = 250,#012    store = {#012    },#012
 },#012  }#012
 Oct 23 04:13:26 wwwbe varnishd[4933]: child (21597) Started
 Oct 23 04:13:26 wwwbe varnishd[4933]: Child (21597) said Child starts
 Oct 23 04:14:09 wwwbe varnishd[4933]: Child (21597) died signal=6
 Oct 23 04:14:09 wwwbe varnishd[4933]: Child (21597) Panic
 message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line
 842:#012  Condition(uu == bo->fetch_obj->len) not true.#012thread =
 (cache-worker)#012ident =
 Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]#012  0x43b7fd:
 /usr/sbin/varnishd() [0x43b7fd]#012  0x425a9d: /usr/sbin/varnishd()
 [0x425a9d]#012  0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce)
 [0x43e44f]#012  0x456f84: /usr/sbin/varnishd() [0x456f84]#012  0x4570ad:
 /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]#012  0x7f44307ba9d1:
 /lib64/libpthread.so.0(+0x79d1) [0x7f44307ba9d1]#012  0x7f443050786d:
 /lib64/libc.so.6(clone+0x6d) [0x7f443050786d]#012  busyobj =
 0x7f441d039020 {#012    ws = 0x7f441d0390e0 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f441d03b008,+16552,(nil),+57368},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_esi#012
 is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 3 (length),#012    },#012    ws =
 0x7f441d039270 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f441d8149b0,+248,(nil),+248},#012    },#012  objcore (FETCH) =
 0x7f441a83c180 {#012    refcnt = 2#012    flags = 0x4#012    objhead =
 0x7f441a83df60#012  }#012  obj (FETCH) = 0x7f441d814800 {#012    vxid =
 2147647591,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "414",#012        "Request-URI Too Large",#012
 "Date: Thu, 23 Oct 2014 02:14:08 GMT",#012        "Server: Apache",#012
 "Content-Length: 250",#012        "Content-Type: text/html;
 charset=iso-8859-1",#012        "Vary: X-UA-Device",#012        "X-Cache-
 ttl: 0.000",#012    },#012    len = 250,#012    store = {#012    },#012
 },#012  }#012
 Oct 23 04:14:09 wwwbe varnishd[4933]: child (21913) Started
 Oct 23 04:14:09 wwwbe varnishd[4933]: Child (21913) said Child starts
 Oct 23 04:15:28 wwwbe varnishd[4933]: Child (21913) died signal=6
 Oct 23 04:15:28 wwwbe varnishd[4933]: Child (21913) Panic
 message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line
 842:#012  Condition(uu == bo->fetch_obj->len) not true.#012thread =
 (cache-worker)#012ident =
 Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]#012  0x43b7fd:
 /usr/sbin/varnishd() [0x43b7fd]#012  0x425a9d: /usr/sbin/varnishd()
 [0x425a9d]#012  0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce)
 [0x43e44f]#012  0x456f84: /usr/sbin/varnishd() [0x456f84]#012  0x4570ad:
 /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]#012  0x7f44307ba9d1:
 /lib64/libpthread.so.0(+0x79d1) [0x7f44307ba9d1]#012  0x7f443050786d:
 /lib64/libc.so.6(clone+0x6d) [0x7f443050786d]#012  busyobj =
 0x7f441cc8e020 {#012    ws = 0x7f441cc8e0e0 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f441cc90008,+17488,(nil),+57368},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_esi#012
 is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 3 (length),#012    },#012    ws =
 0x7f441cc8e270 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f441b862db0,+248,(nil),+248},#012    },#012  objcore (FETCH) =
 0x7f441b010800 {#012    refcnt = 2#012    flags = 0x4#012    objhead =
 0x7f441b012710#012  }#012  obj (FETCH) = 0x7f441b862c00 {#012    vxid =
 2147549232,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "414",#012        "Request-URI Too Large",#012
 "Date: Thu, 23 Oct 2014 02:15:27 GMT",#012        "Server: Apache",#012
 "Content-Length: 250",#012        "Content-Type: text/html;
 charset=iso-8859-1",#012        "Vary: X-UA-Device",#012        "X-Cache-
 ttl: 0.000",#012    },#012    len = 250,#012    store = {#012    },#012
 },#012  }#012
 Oct 23 04:15:28 wwwbe varnishd[4933]: child (22251) Started
 Oct 23 04:15:28 wwwbe varnishd[4933]: Child (22251) said Child starts

 Oct 23 04:15:38 wwwbe varnishd[4933]: Child (22251) died signal=6
 Oct 23 04:15:38 wwwbe varnishd[4933]: Child (22251) Panic
 message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line
 842:#012  Condition(uu == bo->fetch_obj->len) not true.#012thread =
 (cache-worker)#012ident =
 Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]#012  0x43b7fd:
 /usr/sbin/varnishd() [0x43b7fd]#012  0x425a9d: /usr/sbin/varnishd()
 [0x425a9d]#012  0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce)
 [0x43e44f]#012  0x456f84: /usr/sbin/varnishd() [0x456f84]#012  0x4570ad:
 /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]#012  0x7f44307ba9d1:
 /lib64/libpthread.so.0(+0x79d1) [0x7f44307ba9d1]#012  0x7f443050786d:
 /lib64/libc.so.6(clone+0x6d) [0x7f443050786d]#012  busyobj =
 0x7f441c88e020 {#012    ws = 0x7f441c88e0e0 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f441c890008,+17608,(nil),+57368},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_esi#012
 is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 3 (length),#012    },#012    ws =
 0x7f441c88e270 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f441d425db0,+248,(nil),+248},#012    },#012  objcore (FETCH) =
 0x7f441dc1b200 {#012    refcnt = 2#012    flags = 0x4#012    objhead =
 0x7f441dc2dd60#012  }#012  obj (FETCH) = 0x7f441d425c00 {#012    vxid =
 2147483800,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "414",#012        "Request-URI Too Large",#012
 "Date: Thu, 23 Oct 2014 02:15:37 GMT",#012        "Server: Apache",#012
 "Content-Length: 250",#012        "Content-Type: text/html;
 charset=iso-8859-1",#012        "Vary: X-UA-Device",#012        "X-Cache-
 ttl: 0.000",#012    },#012    len = 250,#012    store = {#012    },#012
 },#012  }#012
 Oct 23 04:15:38 wwwbe varnishd[4933]: child (22407) Started
 Oct 23 04:15:38 wwwbe varnishd[4933]: Child (22407) said Child starts


 Oct 23 04:57:30 wwwbe varnishd[4933]: Child (22407) died signal=6
 Oct 23 04:57:30 wwwbe varnishd[4933]: Child (22407) Panic
 message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line
 842:#012  Condition(uu == bo->fetch_obj->len) not true.#012thread =
 (cache-worker)#012ident =
 Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]#012  0x43b7fd:
 /usr/sbin/varnishd() [0x43b7fd]#012  0x425a9d: /usr/sbin/varnishd()
 [0x425a9d]#012  0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce)
 [0x43e44f]#012  0x456f84: /usr/sbin/varnishd() [0x456f84]#012  0x4570ad:
 /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]#012  0x7f44307ba9d1:
 /lib64/libpthread.so.0(+0x79d1) [0x7f44307ba9d1]#012  0x7f443050786d:
 /lib64/libc.so.6(clone+0x6d) [0x7f443050786d]#012  busyobj =
 0x7f441d08e020 {#012    ws = 0x7f441d08e0e0 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f441d090008,+576,(nil),+57368},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_esi#012
 is_do_pass#012    is_uncacheable#012    is_abandon#012    is_is_gzip#012
 is_should_close#012    bodystatus = 3 (length),#012    },#012    ws =
 0x7f441d08e270 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f441bc1b9c0,+232,(nil),+232},#012    },#012  objcore (FETCH) =
 0x7f441c498300 {#012    refcnt = 1#012    flags = 0x104#012    objhead =
 0x7f442f84d320#012  }#012  obj (FETCH) = 0x7f441bc1b800 {#012    vxid =
 2147517676,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "200",#012        "OK",#012        "Date: Thu, 23
 Oct 2014 02:57:29 GMT",#012        "Server: Apache",#012        "Vary:
 Accept-Encoding",#012        "Content-Encoding: gzip",#012
 "Content-Length: 20",#012        "Content-Type: text/html;
 charset=iso-8859-1",#012        "X-Cache-ttl: 0.000",#012    },#012    len
 = 25,#012    store = {#012    },#012  },#012  }#012
 Oct 23 04:57:31 wwwbe varnishd[4933]: child (31654) Started
 Oct 23 04:57:31 wwwbe varnishd[4933]: Child (31654) said Child starts


 Oct 23 08:56:56 wwwbe varnishd[19016]: Child (19018) Panic
 message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line
 842:#012  Condition(uu == bo->fetch_obj->len) not true.#012thread =
 (cache-worker)#012ident =
 Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]#012  0x43b7fd:
 /usr/sbin/varnishd() [0x43b7fd]#012  0x425a9d: /usr/sbin/varnishd()
 [0x425a9d]#012  0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce)
 [0x43e44f]#012  0x456f84: /usr/sbin/varnishd() [0x456f84]#012  0x4570ad:
 /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]#012  0x7f97fefad9d1:
 /lib64/libpthread.so.0(+0x79d1) [0x7f97fefad9d1]#012  0x7f97fecfa86d:
 /lib64/libc.so.6(clone+0x6d) [0x7f97fecfa86d]#012  busyobj =
 0x7f97ec406020 {#012    ws = 0x7f97ec4060e0 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f97ec408008,+2168,(nil),+57368},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_esi#012
 is_do_pass#012    is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 3 (length),#012    },#012    ws =
 0x7f97ec406270 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f97ea07d5f8,+352,(nil),+352},#012    },#012  objcore (FETCH) =
 0x7f97eb012d00 {#012    refcnt = 1#012    flags = 0x104#012    objhead =
 0x7f97fe04d320#012  }#012  obj (FETCH) = 0x7f97ea07d400 {#012    vxid =
 2147483776,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "200",#012        "OK",#012        "Date: Thu, 23
 Oct 2014 06:56:55 GMT",#012        "Server: Apache",#012        "Last-
 Modified: Tue, 17 Jun 2014 09:32:52 GMT",#012        "ETag: "30a5038-5de-
 4fc04d3efe11c"",#012        "Accept-Ranges: bytes",#012        "Content-
 Length: 1502",#012        "Cache-Control: max-age=1209600, public, must-
 revalidate",#012        "Content-Type: image/png",#012        "Vary: X-UA-
 Device",#012        "X-Cache-ttl: 0.000",#012    },#012    len = 1502,#012
 store = {#012    },#012  },#012  }#012
 Oct 23 08:56:57 wwwbe varnishd[19016]: child (20429) Started
 Oct 23 08:56:57 wwwbe varnishd[19016]: Child (20429) said Child starts
 Oct 23 08:58:44 wwwbe varnishd[19016]: Child (20429) died signal=6
 Oct 23 08:58:44 wwwbe varnishd[19016]: Child (20429) Panic
 message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line
 842:#012  Condition(uu == bo->fetch_obj->len) not true.#012thread =
 (cache-worker)#012ident =
 Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]#012  0x43b7fd:
 /usr/sbin/varnishd() [0x43b7fd]#012  0x425a9d: /usr/sbin/varnishd()
 [0x425a9d]#012  0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce)
 [0x43e44f]#012  0x456f84: /usr/sbin/varnishd() [0x456f84]#012  0x4570ad:
 /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]#012  0x7f97fefad9d1:
 /lib64/libpthread.so.0(+0x79d1) [0x7f97fefad9d1]#012  0x7f97fecfa86d:
 /lib64/libc.so.6(clone+0x6d) [0x7f97fecfa86d]#012  busyobj =
 0x7f97ea07d020 {#012    ws = 0x7f97ea07d0e0 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f97ea07f008,+2176,(nil),+57368},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_esi#012
 is_do_pass#012    is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 3 (length),#012    },#012    ws =
 0x7f97ea07d270 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f97e680e478,+352,(nil),+352},#012    },#012  objcore (FETCH) =
 0x7f97eb428480 {#012    refcnt = 1#012    flags = 0x104#012    objhead =
 0x7f97fe04d390#012  }#012  obj (FETCH) = 0x7f97e680e280 {#012    vxid =
 2147549239,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "200",#012        "OK",#012        "Date: Thu, 23
 Oct 2014 06:58:43 GMT",#012        "Server: Apache",#012        "Last-
 Modified: Tue, 17 Jun 2014 09:32:52 GMT",#012        "ETag: "30a5038-5de-
 4fc04d3efe11c"",#012        "Accept-Ranges: bytes",#012        "Content-
 Length: 1502",#012        "Cache-Control: max-age=1209600, public, must-
 revalidate",#012        "Content-Type: image/png",#012        "Vary: X-UA-
 Device",#012        "X-Cache-ttl: 0.000",#012    },#012    len = 1502,#012
 store = {#012    },#012  },#012  }#012
 Oct 23 08:58:44 wwwbe varnishd[19016]: child (20814) Started
 Oct 23 08:58:44 wwwbe varnishd[19016]: Child (20814) said Child starts


 Oct 23 09:03:40 wwwbe varnishd[19016]: Child (20814) died signal=6
 Oct 23 09:03:40 wwwbe varnishd[19016]: Child (20814) Panic
 message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line
 842:#012  Condition(uu == bo->fetch_obj->len) not true.#012thread =
 (cache-worker)#012ident =
 Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]#012  0x43b7fd:
 /usr/sbin/varnishd() [0x43b7fd]#012  0x425a9d: /usr/sbin/varnishd()
 [0x425a9d]#012  0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce)
 [0x43e44f]#012  0x456f84: /usr/sbin/varnishd() [0x456f84]#012  0x4570ad:
 /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]#012  0x7f97fefad9d1:
 /lib64/libpthread.so.0(+0x79d1) [0x7f97fefad9d1]#012  0x7f97fecfa86d:
 /lib64/libc.so.6(clone+0x6d) [0x7f97fecfa86d]#012  busyobj =
 0x7f97e986c020 {#012    ws = 0x7f97e986c0e0 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f97e986e008,+2728,(nil),+57368},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_esi#012
 is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 2 (chunked),#012    },#012    ws =
 0x7f97e986c270 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f97e749ded0,+352,(nil),+352},#012    },#012  objcore (FETCH) =
 0x7f97e7428700 {#012    refcnt = 2#012    flags = 0x4#012    objhead =
 0x7f97e742a4e0#012  }#012  obj (FETCH) = 0x7f97e749dd00 {#012    vxid =
 2147844173,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "200",#012        "OK",#012        "Date: Thu, 23
 Oct 2014 07:03:38 GMT",#012        "Server: Apache",#012        "Expires:
 Thu, 19 Nov 1981 08:52:00 GMT",#012        "Cache-Control: no-store, no-
 cache, must-revalidate, post-check=0, pre-check=0",#012        "Pragma:
 no-cache",#012        "Content-Type: application/json;
 charset=UTF-8;",#012        "Vary: X-UA-Device",#012        "X-Cache-ttl:
 0.000",#012    },#012    len = 1315,#012    store = {#012    },#012
 },#012  }#012
 Oct 23 09:03:40 wwwbe varnishd[19016]: child (22339) Started
 Oct 23 09:03:40 wwwbe varnishd[19016]: Child (22339) said Child starts


 Oct 23 07:55:15 wwwbe varnishd[4933]: Child (31654) died signal=6
 Oct 23 07:55:15 wwwbe varnishd[4933]: Child (31654) Panic
 message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line
 842:#012  Condition(uu == bo->fetch_obj->len) not true.#012thread =
 (cache-worker)#012ident =
 Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]#012  0x43b7fd:
 /usr/sbin/varnishd() [0x43b7fd]#012  0x425a9d: /usr/sbin/varnishd()
 [0x425a9d]#012  0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce)
 [0x43e44f]#012  0x456f84: /usr/sbin/varnishd() [0x456f84]#012  0x4570ad:
 /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]#012  0x7f44307ba9d1:
 /lib64/libpthread.so.0(+0x79d1) [0x7f44307ba9d1]#012  0x7f443050786d:
 /lib64/libc.so.6(clone+0x6d) [0x7f443050786d]#012  busyobj =
 0x7f441d45b020 {#012    ws = 0x7f441d45b0e0 {#012      id = "bo",#012
 {s,f,r,e} = {0x7f441d45d008,+864,(nil),+57368},#012    },#012  refcnt =
 1#012  retries = 0#012  failed = 0#012  state = 3#012    is_do_esi#012
 is_do_pass#012    is_uncacheable#012    is_abandon#012    is_is_gunzip#012
 is_should_close#012    bodystatus = 2 (chunked),#012    },#012    ws =
 0x7f441d45b270 {#012      id = "obj",#012      {s,f,r,e} =
 {0x7f4411985de8,+464,(nil),+464},#012    },#012  objcore (FETCH) =
 0x7f441747ff00 {#012    refcnt = 1#012    flags = 0x104#012    objhead =
 0x7f442f84d390#012  }#012  obj (FETCH) = 0x7f4411985c00 {#012    vxid =
 2148008215,#012    http[obj] = {#012      ws = (nil)[]#012
 "HTTP/1.1",#012        "200",#012        "OK",#012        "Date: Thu, 23
 Oct 2014 05:55:14 GMT",#012        "Server: Apache",#012        "Expires:
 Thu, 19 Nov 1981 08:52:00 GMT",#012        "Cache-Control: no-store, no-
 cache, must-revalidate, post-check=0, pre-check=0",#012        "Pragma:
 no-cache",#012        "Set-Cookie:
 PHPSESSID=20b718b8a719c9ced1989646f4eac49f; expires=Thu, 30-Oct-2014
 05:55:14 GMT; Max-Age=604800; path=/",#012        "Content-Type:
 text/html; charset=iso-8859-1",#012        "Vary: Accept-Encoding, X-UA-
 Device",#012        "X-Cache-t
 Oct 23 07:55:15 wwwbe varnishd[4933]: child (6519) Started
 Oct 23 07:55:15 wwwbe varnishd[4933]: Child (6519) said Child starts

 }}}

 Does anyone have any idea how to solve this problem?

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



From varnish-bugs at varnish-cache.org  Thu Oct 23 11:21:17 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 23 Oct 2014 11:21:17 -0000
Subject: [Varnish] #1596: Panic message:#012Assert error in
 vbf_fetch_thread()
In-Reply-To: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org>
References: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org>
Message-ID: <057.5fb0667003af858c6fc89553ab598eed@varnish-cache.org>

#1596: Panic message:#012Assert error in vbf_fetch_thread()
--------------------+----------------------------------
 Reporter:  webi    |       Owner:
     Type:  defect  |      Status:  new
 Priority:  normal  |   Milestone:  Varnish 4.0 release
Component:  build   |     Version:  4.0.1
 Severity:  normal  |  Resolution:
 Keywords:          |
--------------------+----------------------------------

Comment (by lkarsten):

 Reformatting the top backtrace in comment #5:

 {{{
 Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 842:
   Condition(uu == bo->fetch_obj->len) not true.
 thread = (cache-worker)
 ident = Linux,2.6.32-042stab092.1,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
   0x43b4ed: /usr/sbin/varnishd() [0x43b4ed]
   0x43b7fd: /usr/sbin/varnishd() [0x43b7fd]
   0x425a9d: /usr/sbin/varnishd() [0x425a9d]
   0x43e44f: /usr/sbin/varnishd(Pool_Work_Thread+0x4ce) [0x43e44f]
   0x456f84: /usr/sbin/varnishd() [0x456f84]
   0x4570ad: /usr/sbin/varnishd(WRK_thread+0x27) [0x4570ad]
   0x7f44307ba9d1: /lib64/libpthread.so.0(+0x79d1) [0x7f44307ba9d1]
   0x7f443050786d: /lib64/libc.so.6(clone+0x6d) [0x7f443050786d]
   busyobj = 0x7f441d08e020 {
     ws = 0x7f441d08e0e0 {
       id = "bo",
       {s,f,r,e} = {0x7f441d090008,+15504,(nil),+57368},
     },
   refcnt = 1
   retries = 0
   failed = 0
   state = 3
     is_do_esi
     is_uncacheable
     is_abandon
     is_is_gunzip
     is_should_close
     bodystatus = 3 (length),
     },
     ws = 0x7f441d08e270 {
       id = "obj",
       {s,f,r,e} = {0x7f441b498cb0,+248,(nil),+248},
     },
   objcore (FETCH) = 0x7f441dc2b880 {
     refcnt = 2
     flags = 0x4
     objhead = 0x7f441dc1a400
   }
   obj (FETCH) = 0x7f441b498b00 {
     vxid = 2147484163,
     http[obj] = {
       ws = (nil)[]
         "HTTP/1.1",
         "414",
         "Request-URI Too Large",
         "Date: Thu, 23 Oct 2014 02:12:41 GMT",
         "Server: Apache",
         "Content-Length: 250",
         "Content-Type: text/html; charset=iso-8859-1",
         "Vary: X-UA-Device",
         "X-Cache-ttl: 0.000",
     },
     len = 250,
     store = {
     },
   },
   }

 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1596#comment:6>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Oct 24 07:27:29 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 24 Oct 2014 07:27:29 -0000
Subject: [Varnish] #1617: Varnish 4 weird memory consumption / calculation
Message-ID: <046.253c419c4f87de3d220969908bfcf866@varnish-cache.org>

#1617: Varnish 4 weird memory consumption / calculation
----------------------+----------------------
 Reporter:  whocares  |       Type:  defect
   Status:  new       |   Priority:  normal
Milestone:            |  Component:  varnishd
  Version:  4.0.2     |   Severity:  normal
 Keywords:            |
----------------------+----------------------
 Since switching to Varnish 4 (4.0.2 currently) we're seeing some weirdness
 in how Varnish consumes and calculates memory usage. In short, we're
 seeing that memory requirements seem to have quadrupled compared to
 Varnish 3.0.5. Or at least that's what Varnish thinks for in reality it
 doesn't even use the memory it is given. This is best shown in an example:

 Here's an excerpt of the output from "top" on one of the machines:

 {{{
 top - 08:18:52 up 22 days,  1:16,  3 users,  load average: 0.06, 0.07,
 0.05
 Tasks:  80 total,   1 running,  79 sleeping,   0 stopped,   0 zombie
 %Cpu(s):  1.5 us,  0.5 sy,  0.0 ni, 97.8 id,  0.0 wa,  0.0 hi,  0.2 si,
 0.0 st
 KiB Mem:   8716524 total,  3599224 used,  5117300 free,   163632 buffers
 KiB Swap:   265212 total,        0 used,   265212 free,  1038644 cached

   PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 13716 nobody    20   0 8457m 2.2g  81m S   4.0 26.1  44:26.34 varnishd
 }}}

 As one can see, Varnish only uses 2.2G of RAM and there's plenty of free
 RAM available on the host. However, as shown in the VIRT row, Varnish
 somehow manages to virtually allocate 8.4G of RAM. This is also reflected
 by varnishstats:

 {{{
 ~# varnishstat -1 | grep SMA
 SMA.s0.c_req                            741182        13.15 Allocator
 requests
 SMA.s0.c_fail                                0         0.00 Allocator
 failures
 SMA.s0.c_bytes                     24589352765    436360.54 Bytes
 allocated
 SMA.s0.c_freed                     16205023965    287572.96 Bytes freed
 SMA.s0.g_alloc                          132231          .   Allocations
 outstanding
 SMA.s0.g_bytes                      8384328800          .   Bytes
 outstanding
 SMA.s0.g_space                       205605792          .   Bytes
 available
 SMA.Transient.c_req                     149507         2.65 Allocator
 requests
 SMA.Transient.c_fail                         0         0.00 Allocator
 failures
 SMA.Transient.c_bytes               8960312066    159008.93 Bytes
 allocated
 SMA.Transient.c_freed               8960162698    159006.28 Bytes freed
 SMA.Transient.g_alloc                       90          .   Allocations
 outstanding
 SMA.Transient.g_bytes                   149368          .   Bytes
 outstanding
 SMA.Transient.g_space                        0          .   Bytes
 available
 }}}

 The SMA.s0.g_bytes seems to be in line with the memory usage reported by
 top's VIRT row. And this also seems to be what varnish thinks it is using.
 Which can't be the case since in reality it uses a lot less memory.

 At the same time we're also seeing a lot less objects being stored in
 Varnish's cache. When still on 3.0.5 we were able to keep ~140k objects in
 a 4GB sized memory cache. With Varnish 4.0.2 we now need to give Varnish
 8GB of cache to be able to hold ~70k objects.

 I found that when disabling jemalloc the number get slightly better.
 Especially the RAM usage reported be the RES row goes down dramatically,
 not so much for the VIRT part. The examples above are from Varnish
 compiled with `--disable-jemalloc`. Using an identical twin with jemalloc
 enabled I get this:

 {{{
 top - 08:20:37 up 16 days, 20:34,  2 users,  load average: 0.15, 0.14,
 0.09
 Tasks:  78 total,   1 running,  77 sleeping,   0 stopped,   0 zombie
 %Cpu(s):  1.2 us,  0.3 sy,  0.0 ni, 98.2 id,  0.0 wa,  0.0 hi,  0.2 si,
 0.2 st
 KiB Mem:   8713744 total,  6227532 used,  2486212 free,   155360 buffers
 KiB Swap:   265212 total,        0 used,   265212 free,   419784 cached

   PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 18182 nobody    20   0 10.0g 5.3g  83m S   4.3 64.0 461:00.62 varnishd
 }}}

 As one can see, more than twice RES usage. That's with jemalloc 3.6.0
 (backported from Jessie), I also tried with 3.0.0 (as shipping with Debian
 Wheezy) and 3.4.0. And here's the object count:

 Varnish with standard malloc:
 {{{
 root at bus-cw-vrn-02:~# varnishstat -1 | grep obje
 MAIN.n_object                  67877          .   N struct object
 MAIN.n_vampireobject               0          .   N unresurrected objects
 MAIN.n_objectcore              67941          .   N struct objectcore
 MAIN.n_objecthead              68241          .   N struct objecthead
 }}}

 Varnish with jemalloc:
 {{{
 root at bus-cw-vrn-01:~# varnishstat -1 | grep obje
 MAIN.n_object                  68456          .   N struct object
 MAIN.n_vampireobject               0          .   N unresurrected objects
 MAIN.n_objectcore              65987          .   N struct objectcore
 MAIN.n_objecthead              67722          .   N struct objecthead
 }}}

 Both machines are sitting behind the same load balancer and as would be
 expected they show roughly the same amount of elements. Just heavily
 differing memory usage values.

 We have other machines where we had to tell Varnish to "use" 19G of RAM to
 stop it from LRU nuking objects while at the same time it only uses around
 6-7 GB in reality, like this one for example:

 {{{
 top - 09:25:18 up 7 days, 23:12,  2 users,  load average: 0.00, 0.04, 0.05
 Tasks:  86 total,   1 running,  85 sleeping,   0 stopped,   0 zombie
 %Cpu(s):  1.5 us,  1.2 sy,  0.0 ni, 96.5 id,  0.0 wa,  0.0 hi,  0.8 si,
 0.0 st
 KiB Mem:  20608476 total,  6223084 used, 14385392 free,   161092 buffers
 KiB Swap:   265212 total,        0 used,   265212 free,   298496 cached

   PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 18138 nobody    20   0 21.7g 5.4g  83m S   6.6 27.4 734:59.64 varnishd
 }}}

 Now I generally assume that it's me who is doing something wrong, so I'd
 be really thankful to get some pointers as to what the source of our
 problems could be.

 Here's the system and Varnish config:

 OS: Debian Wheezy with all updates included
 Varnish: 4.0.2 from the official repository and also manually built to
 disable jemalloc

 Varnish runtime parameters:
 `/usr/sbin/varnishd -P /var/run/varnishd.pid -a 0.0.0.0:80 -f
 /etc/varnish/default.vcl -T 0.0.0.0:6082 -t 120 -S /etc/varnish/secret -s
 malloc,8G`

 If there's anything else you need to know just let me know.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1617>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Oct 24 14:02:16 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 24 Oct 2014 14:02:16 -0000
Subject: [Varnish] #1506: Make better use of Content-Length information:
 Avoid chunked responses, more control over Range handling
In-Reply-To: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org>
References: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org>
Message-ID: <065.e45cadc7f8a0e45374f0a52e8df7316c@varnish-cache.org>

#1506: Make better use of Content-Length information: Avoid chunked responses,
more control over Range handling
--------------------------+----------------------------------
 Reporter:  DonMacAskill  |       Owner:  phk
     Type:  defect        |      Status:  new
 Priority:  normal        |   Milestone:  Varnish 4.0 release
Component:  varnishd      |     Version:  4.0.0
 Severity:  critical      |  Resolution:
 Keywords:                |
--------------------------+----------------------------------

Comment (by r):

 It is, thanks.

 FYI: Added cache_req_fsm-1506-fix.patch for the 4.0.x branch.

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1506#comment:10>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Oct 24 14:03:10 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 24 Oct 2014 14:03:10 -0000
Subject: [Varnish] #1596: Panic message:#012Assert error in
 vbf_fetch_thread()
In-Reply-To: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org>
References: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org>
Message-ID: <057.748884860689d0c28ec63dd1dc1ef451@varnish-cache.org>

#1596: Panic message:#012Assert error in vbf_fetch_thread()
--------------------+----------------------------------
 Reporter:  webi    |       Owner:
     Type:  defect  |      Status:  new
 Priority:  normal  |   Milestone:  Varnish 4.0 release
Component:  build   |     Version:  4.0.1
 Severity:  normal  |  Resolution:
 Keywords:          |
--------------------+----------------------------------

Comment (by r):

 The assert failure is related to the race condition described in the
 #1506 ticket.  It seems that the invalid diagnostic checks were removed
 as part of the following change:

 https://www.varnish-
 cache.org/trac/changeset/be938d34eea6dfb9ef8c63b41838236b1cf72367/bin/varnishd/cache/cache_fetch.c

 Is there any reason why the removal of these checks cannot be backported
 to 4.0.x branch (see cache_fetch-1596-fix.patch)?

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1596#comment:7>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Oct 24 14:40:34 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 24 Oct 2014 14:40:34 -0000
Subject: [Varnish] #1617: Varnish 4 weird memory consumption / calculation
In-Reply-To: <046.253c419c4f87de3d220969908bfcf866@varnish-cache.org>
References: <046.253c419c4f87de3d220969908bfcf866@varnish-cache.org>
Message-ID: <061.8c5e8af9c32b80f75091cc34f5900881@varnish-cache.org>

#1617: Varnish 4 weird memory consumption / calculation
----------------------+--------------------
 Reporter:  whocares  |       Owner:
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by lkarsten):

 Does your backend send chunked responses? Try reducing fetch_chunksize to
 8k and see if that improves the memory usage.

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



From varnish-bugs at varnish-cache.org  Fri Oct 24 17:11:51 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 24 Oct 2014 17:11:51 -0000
Subject: [Varnish] #1617: Varnish 4 weird memory consumption / calculation
In-Reply-To: <046.253c419c4f87de3d220969908bfcf866@varnish-cache.org>
References: <046.253c419c4f87de3d220969908bfcf866@varnish-cache.org>
Message-ID: <061.91dc2e8c42c653b0a6c08ff2a260becf@varnish-cache.org>

#1617: Varnish 4 weird memory consumption / calculation
----------------------+--------------------
 Reporter:  whocares  |       Owner:
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by whocares):

 Followed your suggestion and the numbers indeed look much nicer now. I'll
 let it run for a while an report back when I have better data.
 That said, I have to admit I'm curious: I've read the parameter list from
 top to bottom and back but never figured that fetch_chunksize would have
 such an influence on memory usage. Care to explain what happens there? For
 even if there'd be, say 1000 threads active at the same time I imagined
 that with a buffer size of 128k I'd "just" spend 128M of RAM for the
 different chunk buffers but not something in the GB ranges.

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



From varnish-bugs at varnish-cache.org  Fri Oct 24 22:48:58 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 24 Oct 2014 22:48:58 -0000
Subject: [Varnish] #1618: The "Range" header is not honored for a cache miss.
Message-ID: <047.7e50d570f16c3170f5bb0bb63e9ff04d@varnish-cache.org>

#1618: The "Range" header is not honored for a cache miss.
-------------------------------+--------------------
 Reporter:  jeffawang          |       Type:  defect
   Status:  new                |   Priority:  high
Milestone:                     |  Component:  build
  Version:  4.0.2              |   Severity:  normal
 Keywords:  range header miss  |
-------------------------------+--------------------
 Context: I'm sending a request to the varnish cache (v4.0.2), which sits
 on top of a tomcat server that does not support the Range http header.

 When I submit a request with "Range: bytes=0-0" to Varnish for a not-yet-
 cached object, I get a non-ranged response (more than one byte) and a HTTP
 code 200.

 When I submit precisely the same request again with the same headers, I
 get the ranged response (only the first byte) and a HTTP code 206.
 Subsequent requests return ranged 206s, until it's purged from cache.

 The expected behavior should be a ranged 206 in each case (cache miss or
 cache hit), rather than different responses for the same request.

 Specifying the following in VCL makes the cache miss return a ranged 206,
 as expected:

 {{{
 sub vcl_backend_response {
     # Workaround for ranged cache-miss 200
     set beresp.do_stream = false;
 }
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1618>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 27 09:17:32 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 27 Oct 2014 09:17:32 -0000
Subject: [Varnish] #1596: Panic message:#012Assert error in
 vbf_fetch_thread()
In-Reply-To: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org>
References: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org>
Message-ID: <057.6d2d627ed7046859e4595cc56116a726@varnish-cache.org>

#1596: Panic message:#012Assert error in vbf_fetch_thread()
--------------------+----------------------------------
 Reporter:  webi    |       Owner:
     Type:  defect  |      Status:  new
 Priority:  normal  |   Milestone:  Varnish 4.0 release
Component:  build   |     Version:  4.0.1
 Severity:  normal  |  Resolution:
 Keywords:          |
--------------------+----------------------------------

Comment (by Youri_13):

 How do i apply the patch to Varnish?

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1596#comment:8>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 27 12:30:31 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 27 Oct 2014 12:30:31 -0000
Subject: [Varnish] #1616: RH packages for varnish4 installs headers at
 the wrong place
In-Reply-To: <047.10a5b7a71076bf8edeedc8500ef75678@varnish-cache.org>
References: <047.10a5b7a71076bf8edeedc8500ef75678@varnish-cache.org>
Message-ID: <062.a61bbe935654b2ec0759a813962b63d6@varnish-cache.org>

#1616: RH packages for varnish4 installs headers at the wrong place
------------------------+-----------------------
 Reporter:  mfournier   |       Owner:  lkarsten
     Type:  defect      |      Status:  new
 Priority:  normal      |   Milestone:
Component:  packaging   |     Version:  4.0.2
 Severity:  normal      |  Resolution:
 Keywords:  rpm redhat  |
------------------------+-----------------------
Changes (by lkarsten):

 * owner:   => lkarsten


Comment:

 [13:27:53] < fgs> This is the vmod includes IIRC
 [13:27:57] < fgs> we should move them to /usr/include
 [13:28:03] < fgs> Debian packages already doing this
 [13:28:41] < fgs> and I don't think they should live in /usr/share,
 specially now that we have a more or less agreed API

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



From varnish-bugs at varnish-cache.org  Mon Oct 27 12:40:53 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 27 Oct 2014 12:40:53 -0000
Subject: [Varnish] #1615: Panic message:#012Assert error in
 vbf_fetch_thread(), cache/cache_fetch.c line 842
In-Reply-To: <046.8e53f7b24c5434e7c650d99fba08bbe3@varnish-cache.org>
References: <046.8e53f7b24c5434e7c650d99fba08bbe3@varnish-cache.org>
Message-ID: <061.d4da3f2f2638f522652ec1849a36ad8e@varnish-cache.org>

#1615: Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c
line 842
------------------------------+------------------------
 Reporter:  xieyugui          |       Owner:
     Type:  defect            |      Status:  closed
 Priority:  normal            |   Milestone:  Later
Component:  build             |     Version:  4.0.2
 Severity:  normal            |  Resolution:  duplicate
 Keywords:  vbf_fetch_thread  |
------------------------------+------------------------
Changes (by daghf):

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


Comment:

 This issue is currently being tracked in ticket #1596. Please use that for
 further followup.

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



From varnish-bugs at varnish-cache.org  Mon Oct 27 12:52:46 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 27 Oct 2014 12:52:46 -0000
Subject: [Varnish] #1618: The "Range" header is not honored for a cache
 miss.
In-Reply-To: <047.7e50d570f16c3170f5bb0bb63e9ff04d@varnish-cache.org>
References: <047.7e50d570f16c3170f5bb0bb63e9ff04d@varnish-cache.org>
Message-ID: <062.eea578cdd5c5911a3bb3c21a1c2fd6b8@varnish-cache.org>

#1618: The "Range" header is not honored for a cache miss.
-------------------------------+--------------------
 Reporter:  jeffawang          |       Owner:
     Type:  defect             |      Status:  new
 Priority:  high               |   Milestone:
Component:  build              |     Version:  4.0.2
 Severity:  normal             |  Resolution:
 Keywords:  range header miss  |
-------------------------------+--------------------

Comment (by lkarsten):

 Discussed during bugwash today.

 This ties in with #1506. Needs further study.

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



From varnish-bugs at varnish-cache.org  Mon Oct 27 15:41:18 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 27 Oct 2014 15:41:18 -0000
Subject: [Varnish] #1619: Varnishncsa does not log 304
Message-ID: <045.aabbcac6807a00c38546c6a94fb5c2b2@varnish-cache.org>

#1619: Varnishncsa does not log 304
---------------------------------+-------------------------
 Reporter:  vrobert              |       Type:  defect
   Status:  new                  |   Priority:  high
Milestone:  Varnish 4.0 release  |  Component:  varnishncsa
  Version:  4.0.2                |   Severity:  major
 Keywords:  varnishncsa 304      |
---------------------------------+-------------------------
 Hi,

 since that we migrated to varnish 4 (0.1 or 0.2), we had not 304 in log.

 If a conditional request arrives, a 304 code could be send by Varnish, but
 it's never logged by varnishncsa.

 Instead of 304, a 200 with Content-Lenght at 0 byte is logged.

 ex:
 {{{
 93.17.51.134 - - [27/Oct/2014:16:05:24 +0100] "GET http://www.ouestfrance-
 auto.com/voiture-occasion/passat-cc-2-0-tdi-140-dsg-carat/ HTTP/1.1" 200 0
 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
 +http://www.google.com/bot.html)" hit 0.000162
 }}}

 for the request :

 {{{
 curl -v --header 'If-Modified-Since: Mon, 27 Oct 2014 14:58:36 GMT' -A
 "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
 "http://www.ouestfrance-auto.com/voiture-occasion/passat-cc-2-0-tdi-140
 -dsg-carat/"
 * About to connect() to www.ouestfrance-auto.com port 80 (#0)
 *   Trying 212.95.70.231... connected
 * Connected to www.ouestfrance-auto.com (212.95.70.231) port 80 (#0)
 > GET /voiture-occasion/passat-cc-2-0-tdi-140-dsg-carat/ HTTP/1.1
 > User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1;
 +http://www.google.com/bot.html)
 > Host: www.ouestfrance-auto.com
 > Accept: */*
 > If-Modified-Since: Mon, 27 Oct 2014 14:58:36 GMT
 >
 < HTTP/1.1 304 Not Modified
 < Date: Mon, 27 Oct 2014 09:45:49 GMT
 < Content-Type: text/html
 < Vary: Accept-Encoding
 < X-Powered-By: PHP/5.5.12
 < Expires:
 < Cache-Control: public, max-age=1800
 < Pragma:
 < Access-Control-Allow-Origin: *
 < Access-Control-Allow-Methods: GET, POST
 < Access-Control-Allow-Headers: X_OFA
 < x-url: www.ouestfrance-auto.com/voiture-occasion/passat-cc-2-0-tdi-140
 -dsg-carat/
 < h-url: /voiture-occasion/passat-cc-2-0-tdi-140-dsg-carat/
 < X-Varnish: 674201926 491946724
 < Via: 1.1 varnish-v4
 < X-Age: 19175
 < grace: full(bot)
 < X-Served-By: ofm-proxy01.sdv.fr
 < Connection: keep-alive
 <
 * Connection #0 to host www.ouestfrance-auto.com left intact
 * Closing connection #0
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1619>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Oct 27 16:24:49 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 27 Oct 2014 16:24:49 -0000
Subject: [Varnish] #1619: Varnishncsa does not log 304
In-Reply-To: <045.aabbcac6807a00c38546c6a94fb5c2b2@varnish-cache.org>
References: <045.aabbcac6807a00c38546c6a94fb5c2b2@varnish-cache.org>
Message-ID: <060.94ccdbd4f6f1f8697609a6673570d734@varnish-cache.org>

#1619: Varnishncsa does not log 304
-----------------------------+----------------------------------
 Reporter:  vrobert          |       Owner:
     Type:  defect           |      Status:  closed
 Priority:  high             |   Milestone:  Varnish 4.0 release
Component:  varnishncsa      |     Version:  4.0.2
 Severity:  major            |  Resolution:  duplicate
 Keywords:  varnishncsa 304  |
-----------------------------+----------------------------------
Changes (by daghf):

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


Comment:

 This happens due to the same issue we run into in #1462. Closing.

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



From varnish-bugs at varnish-cache.org  Mon Oct 27 18:39:58 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 27 Oct 2014 18:39:58 -0000
Subject: [Varnish] #1614: Missing support for pcre in substitution string
In-Reply-To: <044.05bde7284f34eb92227666a9a0ee1aad@varnish-cache.org>
References: <044.05bde7284f34eb92227666a9a0ee1aad@varnish-cache.org>
Message-ID: <059.137552e52c044f467f3a79f942786044@varnish-cache.org>

#1614: Missing support for pcre in substitution string
----------------------+----------------------
 Reporter:  anders    |       Owner:
     Type:  defect    |      Status:  closed
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  3.0.5
 Severity:  normal    |  Resolution:  wontfix
 Keywords:  pcre      |
----------------------+----------------------
Changes (by fgsch):

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


Comment:

 As discussed today on irc VCL doesn't have any escape syntax but you can
 achieve this already using literals.
 Attached are 2 tests that demonstrate this.

 It's worth noting that the replacement in regsub() is done in Varnish and
 not via pcre.

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



From varnish-bugs at varnish-cache.org  Tue Oct 28 11:57:16 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 28 Oct 2014 11:57:16 -0000
Subject: [Varnish] #1613: keep-alive is enabled even if
 req.http.Connection is set to "close"
In-Reply-To: <046.7db229749aec5a5a59468cb8dc65960a@varnish-cache.org>
References: <046.7db229749aec5a5a59468cb8dc65960a@varnish-cache.org>
Message-ID: <061.7fc3f35d9d4430d714eaba3b0dca3dc2@varnish-cache.org>

#1613: keep-alive is enabled even if req.http.Connection is set to "close"
----------------------+--------------------
 Reporter:  zviratko  |       Owner:
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.1
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by daghf):

 This was discussed during yesterdays bugwash meeting, and the consensus is
 that the way to do this in Varnish is to set Connection: close in the
 response.

 Relating to this, there is a bug in that {{{sub vcl_deliver { set
 resp.http.Connection = "close"; } }}} currently leaves us with two
 Connection headers in the response (both "close" and "keep-alive"), which
 might confuse a few clients.

 I've attached a test case that demonstrates this behavior.

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



From varnish-bugs at varnish-cache.org  Tue Oct 28 12:39:58 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 28 Oct 2014 12:39:58 -0000
Subject: [Varnish] #1349: No exact match on varnishadm backend.set_health
In-Reply-To: <046.8a05e196ff21820ddf1411b60bf8db31@varnish-cache.org>
References: <046.8a05e196ff21820ddf1411b60bf8db31@varnish-cache.org>
Message-ID: <061.c3105538d7801eae69b5f0883f1768b7@varnish-cache.org>

#1349: No exact match on varnishadm backend.set_health
--------------------------------------------+---------------------
 Reporter:  tmagnien                        |       Owner:  daghf
     Type:  defect                          |      Status:  closed
 Priority:  normal                          |   Milestone:
Component:  varnishd                        |     Version:  trunk
 Severity:  normal                          |  Resolution:  fixed
 Keywords:  exact match backend.set_health  |
--------------------------------------------+---------------------
Changes (by Dag Haavi Finstad <daghf@?>):

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


Comment:

 In [606906c8d52dd2cc262e1ea0adb11f507d66609f]:
 {{{
 #!CommitTicketReference repository=""
 revision="606906c8d52dd2cc262e1ea0adb11f507d66609f"
 Prefer exact matches in varnishadm backend.set_health.

 Fixes: #1349
 }}}

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



From varnish-bugs at varnish-cache.org  Wed Oct 29 06:11:06 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 29 Oct 2014 06:11:06 -0000
Subject: [Varnish] #1613: keep-alive is enabled even if
 req.http.Connection is set to "close"
In-Reply-To: <046.7db229749aec5a5a59468cb8dc65960a@varnish-cache.org>
References: <046.7db229749aec5a5a59468cb8dc65960a@varnish-cache.org>
Message-ID: <061.148e4c0df39fea24c6cd3ab07471acad@varnish-cache.org>

#1613: keep-alive is enabled even if req.http.Connection is set to "close"
----------------------+--------------------
 Reporter:  zviratko  |       Owner:
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.1
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by zviratko):

 Sorry in advance for polluting trac with discussion, but I feel very
 strongly about VCL being blackboxed like this.

 Varnish should either respect the *.http.Connection header at every step,
 or it should use flag like *.use_keepalive to make them independent (to a
 limit!). The latter is more flexible.
 In any way, it must be possible to set it at every step of the workflow,
 because you can not foresee what silly and unexpected things a user will
 do with a things as flexible as VCL (and I consider this a plus!).
 But it should also be transparent and behave in expected way.
 If I set Connection: close at any point, it should be used then next time
 a connection is finished. It should not reset back, it should not
 disregard my changes, it should however respect the response a backend
 sends (and it must allow me to set it back if I want to).
 Maybe I will need to disable keep-alive only for backend connections but
 keep it active for the client - would this even be possible?

 Maybe I will need to have Connection: keep-alive in the response, but
 close the connection in reality (because of proxy chaining, legacy broken
 apps - again, you can not foresee stuff like this).

 Maybe I'll need to use keep-alive for only some cases according to some
 existing VCL logic, most likely implemented in vcl_req and not in
 vcl_deliver.

 Maybe I just want to build crazy non-standard stuff.

 Maybe I just want to be ready for others' non-standard crazy stuff when it
 comes.


 If you want to maintain the level of flexibility that I think we should
 expect, then adding a separate header _and_ exposing how it works in the
 builtin.vcl is the only way to go.

 There might be a technical limitation behind your decision in which case
 this workaround is welcome for now, but it's just not how it should be. I
 love varnish because it is open, contrary to competing blackbox-ish
 solutions, so hiding logic away from me = away from VCL and out of reach
 puts you closer to the propritary crowd.

 It's great that I get calls like this from my former colleagues: "help us
 set up our varnish cache, we know you have the experience and we can pay"

 But when I set up my first production varnish cache years ago, it was
 exactly because I did _not_ need to call a consultant, it was all right
 there in plain sight, open, flexible, standard, yet I could dig into VCL
 and make it do something crazy when needed (and it _was_ needed!).

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



From varnish-bugs at varnish-cache.org  Wed Oct 29 09:19:05 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 29 Oct 2014 09:19:05 -0000
Subject: [Varnish] #1620: ESI asserts when no threads are available
Message-ID: <044.835601ea2e67939602ff155a91200ecb@varnish-cache.org>

#1620: ESI asserts when no threads are available
--------------------+---------------------
 Reporter:  martin  |      Owner:
     Type:  defect  |     Status:  new
 Priority:  normal  |  Milestone:
Component:  build   |    Version:  unknown
 Severity:  normal  |   Keywords:
--------------------+---------------------
 Creating a varnishtest case for this situation doesn't seem possible to
 me, because the thread min is 100 and the test case would need to occupy
 100 threads.

 To test this situation, one can apply the following patch to Varnish:

 {{{
 --- a/bin/varnishd/cache/cache_fetch.c
 +++ b/bin/varnishd/cache/cache_fetch.c
 @@ -956,7 +956,7 @@ VBF_Fetch(struct worker *wrk, struct req *req, struct
 objcore *oc,
         bo->fetch_task.priv = bo;
         bo->fetch_task.func = vbf_fetch_thread;

 -       if (Pool_Task(wrk->pool, &bo->fetch_task, POOL_QUEUE_FRONT))
 +       /* if (Pool_Task(wrk->pool, &bo->fetch_task, POOL_QUEUE_FRONT)) */
                 vbf_fetch_thread(wrk, bo);
         if (mode == VBF_BACKGROUND) {
                 VBO_waitstate(bo, BOS_REQ_DONE);
 }}}

 Then any of the ESI test cases will assert:

 {{{
 $ ./varnishtest -iv tests/e00003.vtc
 ...
 ***  v1    1.4 debug| Child (27306) died signal=6\n
 ***  v1    1.4 debug| Child (27306) Panic message:\n
 ***  v1    1.4 debug| Assert error in V1L_Reserve(),
 http1/cache_http1_line.c line 78:\n
 ***  v1    1.4 debug|   Condition((wrk->v1l) == 0) not true.\n
 ***  v1    1.4 debug| thread = (cache-worker)\n
 ***  v1    1.4 debug| version = varnish-trunk revision 389c050\n
 ***  v1    1.4 debug| ident =
 Linux,3.14-2-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll\n
 ***  v1    1.4 debug| Backtrace:\n
 ***  v1    1.4 debug|   0x44db69: pan_backtrace+0x19\n
 ***  v1    1.4 debug|   0x44da62: pan_ic+0x282\n
 ***  v1    1.4 debug|   0x47f2fa: V1L_Reserve+0x12a\n
 ***  v1    1.4 debug|   0x47c2ac: V1F_fetch_hdr+0x4cc\n
 ***  v1    1.4 debug|   0x4121e1: vbe_dir_gethdrs+0x2f1\n
 ***  v1    1.4 debug|   0x4212ef: VDI_GetHdr+0x22f\n
 ***  v1    1.4 debug|   0x42feb3: vbf_stp_startfetch+0x503\n
 ***  v1    1.4 debug|   0x42ebfc: vbf_fetch_thread+0x6dc\n
 ***  v1    1.4 debug|   0x42e391: VBF_Fetch+0x7b1\n
 ***  v1    1.4 debug|   0x4578ec: cnt_miss+0x39c\n
 ***  v1    1.4 debug| req = 0x7ff4f5c44020 {\n
 ***  v1    1.4 debug|   sp = 0x7ff4f5c0e1e0, vxid = 1003,  step =
 R_STP_MISS,\n
 ***  v1    1.4 debug|   req_body = R_BODY_NONE,\n
 ***  v1    1.4 debug|   restarts = 0, esi_level = 1\n
 ***  v1    1.4 debug|   sp = 0x7ff4f5c0e1e0 {\n
 ***  v1    1.4 debug|     fd = 11, vxid = 1000,\n
 ***  v1    1.4 debug|     client = 127.0.0.1 45867,\n
 ***  v1    1.4 debug|     step = S_STP_WORKING,\n
 ***  v1    1.4 debug|   },\n
 ***  v1    1.4 debug|   worker = 0x7ff5039f5c50 {\n
 ***  v1    1.4 debug|     stack = {0x7ff5039f6000 -> 0x7ff5039ea000}\n
 ***  v1    1.4 debug|     ws = 0x7ff5039f5e68 {\n
 ***  v1    1.4 debug|       id = "wrk",\n
 ***  v1    1.4 debug|       {s,f,r,e} =
 {0x7ff5039f5400,0x7ff5039f5400,(nil),+2040},\n
 ***  v1    1.4 debug|     },\n
 ***  v1    1.4 debug|   VCL::method = BACKEND_FETCH,\n
 ***  v1    1.4 debug|   VCL::return = fetch,\n
 ***  v1    1.4 debug|   VCL::methods = {RECV, HASH, MISS, DELIVER,
 BACKEND_FETCH, BACKEND_RESPONSE},\n
 ***  v1    1.4 debug|   },\n
 ***  v1    1.4 debug|   ws = 0x7ff4f5c441d0 {\n
 ***  v1    1.4 debug|     id = "req",\n
 ***  v1    1.4 debug|     {s,f,r,e} =
 {0x7ff4f5c45ff0,+104,(nil),+57384},\n
 ***  v1    1.4 debug|   },\n
 ***  v1    1.4 debug|   http[req] = {\n
 ***  v1    1.4 debug|     ws = 0x7ff4f5c441d0[req]\n
 ***  v1    1.4 debug|       "GET",\n
 ***  v1    1.4 debug|       "/body1",\n
 ***  v1    1.4 debug|       "HTTP/1.1",\n
 ***  v1    1.4 debug|       "X-Forwarded-For: 127.0.0.1",\n
 ***  v1    1.4 debug|   },\n
 ***  v1    1.4 debug|   vcl = {\n
 ***  v1    1.4 debug|     srcname = {\n
 ***  v1    1.4 debug|       "input",\n
 ***  v1    1.4 debug|       "Builtin",\n
 ***  v1    1.4 debug|     },\n
 ***  v1    1.4 debug|   },\n
 ***  v1    1.4 debug|   objcore (REQ) = 0x7ff4f5c2a240 {\n
 ***  v1    1.4 debug|     refcnt = 2\n
 ***  v1    1.4 debug|     flags = 0x2\n
 ***  v1    1.4 debug|     objhead = 0x7ff4f5c151a0\n
 ***  v1    1.4 debug|     stevedore = (nil)\n
 ***  v1    1.4 debug|   }\n
 ***  v1    1.4 debug|   busyobj = 0x7ff4f5c2e020 {\n
 ***  v1    1.4 debug|     ws = 0x7ff4f5c2e0e0 {\n
 ***  v1    1.4 debug|       id = "bo",\n
 ***  v1    1.4 debug|       {s,f,r,e} =
 {0x7ff4f5c2ff88,+280,(nil),+57488},\n
 ***  v1    1.4 debug|     },\n
 ***  v1    1.4 debug|   refcnt = 2\n
 ***  v1    1.4 debug|   retries = 0\n
 ***  v1    1.4 debug|   failed = 0\n
 ***  v1    1.4 debug|   state = 1\n
 ***  v1    1.4 debug|     is_do_stream\n
 ***  v1    1.4 debug|     bodystatus = 0 (none),\n
 ***  v1    1.4 debug|     },\n
 ***  v1    1.4 debug|     http[bereq] = {\n
 ***  v1    1.4 debug|       ws = 0x7ff4f5c2e0e0[bo]\n
 ***  v1    1.4 debug|         "GET",\n
 ***  v1    1.4 debug|         "/body1",\n
 ***  v1    1.4 debug|         "HTTP/1.1",\n
 ***  v1    1.4 debug|         "X-Forwarded-For: 127.0.0.1",\n
 ***  v1    1.4 debug|         "Accept-Encoding: gzip",\n
 ***  v1    1.4 debug|         "X-Varnish: 1004",\n
 ***  v1    1.4 debug|         "Host: 127.0.0.1",\n
 ***  v1    1.4 debug|     },\n
 ***  v1    1.4 debug|     http[beresp] = {\n
 ***  v1    1.4 debug|       ws = 0x7ff4f5c2e0e0[bo]\n
 ***  v1    1.4 debug|     },\n
 ***  v1    1.4 debug|   objcore (FETCH) = 0x7ff4f5c2a240 {\n
 ***  v1    1.4 debug|     refcnt = 2\n
 ***  v1    1.4 debug|     flags = 0x2\n
 ***  v1    1.4 debug|     objhead = 0x7ff4f5c151a0\n
 ***  v1    1.4 debug|     stevedore = (nil)\n
 ***  v1    1.4 debug|   }\n
 ***  v1    1.4 debug|   }\n
 ***  v1    1.4 debug| },\n
 ***  v1    1.4 debug|   busyobj = 0x7ff4f5c2e020 {\n
 ***  v1    1.4 debug|     ws = 0x7ff4f5c2e0e0 {\n
 ***  v1    1.4 debug|       id = "bo",\n
 ***  v1    1.4 debug|       {s,f,r,e} =
 {0x7ff4f5c2ff88,+280,(nil),+57488},\n
 ***  v1    1.4 debug|     },\n
 ***  v1    1.4 debug|   refcnt = 2\n
 ***  v1    1.4 debug|   retries = 0\n
 ***  v1    1.4 debug|   failed = 0\n
 ***  v1    1.4 debug|   state = 1\n
 ***  v1    1.4 debug|     is_do_stream\n
 ***  v1    1.4 debug|     bodystatus = 0 (none),\n
 ***  v1    1.4 debug|     },\n
 ***  v1    1.4 debug|     http[bereq] = {\n
 ***  v1    1.4 debug|       ws = 0x7ff4f5c2e0e0[bo]\n
 ***  v1    1.4 debug|         "GET",\n
 ***  v1    1.4 debug|         "/body1",\n
 ***  v1    1.4 debug|         "HTTP/1.1",\n
 ***  v1    1.4 debug|         "X-Forwarded-For: 127.0.0.1",\n
 ***  v1    1.4 debug|         "Accept-Encoding: gzip",\n
 ***  v1    1.4 debug|         "X-Varnish: 1004",\n
 ***  v1    1.4 debug|         "Host: 127.0.0.1",\n
 ***  v1    1.4 debug|     },\n
 ***  v1    1.4 debug|     http[beresp] = {\n
 ***  v1    1.4 debug|       ws = 0x7ff4f5c2e0e0[bo]\n
 ***  v1    1.4 debug|     },\n
 ***  v1    1.4 debug|   objcore (FETCH) = 0x7ff4f5c2a240 {\n
 ***  v1    1.4 debug|     refcnt = 2\n
 ***  v1    1.4 debug|     flags = 0x2\n
 ***  v1    1.4 debug|     objhead = 0x7ff4f5c151a0\n
 ***  v1    1.4 debug|     stevedore = (nil)\n
 ***  v1    1.4 debug|   }\n
 ***  v1    1.4 debug|   }\n
 ***  v1    1.4 debug| \n
 ***  v1    1.4 debug| \n
 ***  v1    1.4 debug| Child cleanup complete\n
 ***  v1    1.5 CLI RX  101
 **** v1    1.5 CLI RX| Unknown request in manager process (child not
 running).\n
 **** v1    1.5 CLI RX| Type 'help' for more info.
 **   v1    1.5 Wait
 **** v1    1.5 STDOUT poll 0x10
 **   v1    1.5 R 27283 Status: 0000 (u 0.048000 s 0.048000)
 **   l1    1.5 Waiting for logexp
 **   l2    1.5 Waiting for logexp
 **   l3    1.5 Waiting for logexp
 **   l4    1.5 Waiting for logexp
 **   l5    1.5 Waiting for logexp
 *    top   1.5 TEST tests/e00003.vtc FAILED

 #     top  TEST tests/e00003.vtc FAILED (1.523) exit=1
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1620>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Oct 29 09:27:51 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 29 Oct 2014 09:27:51 -0000
Subject: [Varnish] #1621: Synth code path fails when no backend threads are
 available
Message-ID: <044.d6b22920154b20eb08a93044b39fd41e@varnish-cache.org>

#1621: Synth code path fails when no backend threads are available
----------------------+---------------------
 Reporter:  martin    |      Owner:
     Type:  defect    |     Status:  new
 Priority:  normal    |  Milestone:
Component:  varnishd  |    Version:  unknown
 Severity:  normal    |   Keywords:
----------------------+---------------------
 To test this situation, one can apply the following patch to Varnish:

 {{{
 --- a/bin/varnishd/cache/cache_fetch.c
 +++ b/bin/varnishd/cache/cache_fetch.c
 @@ -956,7 +956,7 @@ VBF_Fetch(struct worker *wrk, struct req *req, struct
 objcore *oc,
         bo->fetch_task.priv = bo;
         bo->fetch_task.func = vbf_fetch_thread;

 -       if (Pool_Task(wrk->pool, &bo->fetch_task, POOL_QUEUE_FRONT))
 +       /* if (Pool_Task(wrk->pool, &bo->fetch_task, POOL_QUEUE_FRONT)) */
                 vbf_fetch_thread(wrk, bo);
         if (mode == VBF_BACKGROUND) {
                 VBO_waitstate(bo, BOS_REQ_DONE);
 }}}

 Then e.g. test case b00038.vtc will produce an assert during the synth
 generation:

 {{{
 $ ./varnishtest -iv tests/b00038.vtc
 ...
 ***  v1    0.4 debug| Child (7885) died signal=6\n
 ***  v1    0.4 debug| Child (7885) Panic message:\n
 ***  v1    0.4 debug| Assert error in vsl_sanity(), cache/cache_shmlog.c
 line 60:\n
 ***  v1    0.4 debug|   Condition((vsl) != 0) not true.\n
 ***  v1    0.4 debug| thread = (cache-worker)\n
 ***  v1    0.4 debug| version = varnish-trunk revision 389c050\n
 ***  v1    0.4 debug| ident =
 Linux,3.14-2-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll\n
 ***  v1    0.4 debug| Backtrace:\n
 ***  v1    0.4 debug|   0x44db69: pan_backtrace+0x19\n
 ***  v1    0.4 debug|   0x44da62: pan_ic+0x282\n
 ***  v1    0.4 debug|   0x45db3c: vsl_sanity+0x5c\n
 ***  v1    0.4 debug|   0x45eb97: VSLb+0x127\n
 ***  v1    0.4 debug|   0x49762d: STV_NewObject+0x46d\n
 ***  v1    0.4 debug|   0x458f73: cnt_synth+0x6a3\n
 ***  v1    0.4 debug|   0x4548c2: CNT_Request+0x752\n
 ***  v1    0.4 debug|   0x47d22a: HTTP1_Session+0x5aa\n
 ***  v1    0.4 debug|   0x45bcb0: ses_req_pool_task+0x210\n
 ***  v1    0.4 debug|   0x45b7b1: ses_sess_pool_task+0x261\n
 ***  v1    0.4 debug| req = 0x7f21f7c19020 {\n
 ***  v1    0.4 debug|   sp = 0x7f21f7c0e1e0, vxid = 1001,  step =
 R_STP_SYNTH,\n
 ***  v1    0.4 debug|   req_body = R_BODY_NONE,\n
 ***  v1    0.4 debug|   err_code = 503, err_reason = (null),\n
 ***  v1    0.4 debug|   restarts = 0, esi_level = 0\n
 ***  v1    0.4 debug|   sp = 0x7f21f7c0e1e0 {\n
 ***  v1    0.4 debug|     fd = 11, vxid = 1000,\n
 ***  v1    0.4 debug|     client = 127.0.0.1 60123,\n
 ***  v1    0.4 debug|     step = S_STP_WORKING,\n
 ***  v1    0.4 debug|   },\n
 ***  v1    0.4 debug|   worker = 0x7f22053dfc50 {\n
 ***  v1    0.4 debug|     stack = {0x7f22053e0000 -> 0x7f22053d4000}\n
 ***  v1    0.4 debug|     ws = 0x7f22053dfe68 {\n
 ***  v1    0.4 debug|       id = "wrk",\n
 ***  v1    0.4 debug|       {s,f,r,e} =
 {0x7f22053df400,0x7f22053df400,(nil),+2040},\n
 ***  v1    0.4 debug|     },\n
 ***  v1    0.4 debug|   VCL::method = SYNTH,\n
 ***  v1    0.4 debug|   VCL::return = deliver,\n
 ***  v1    0.4 debug|   VCL::methods = {RECV, HASH, MISS, SYNTH,
 BACKEND_FETCH},\n
 ***  v1    0.4 debug|   },\n
 ***  v1    0.4 debug|   ws = 0x7f21f7c191d0 {\n
 ***  v1    0.4 debug|     id = "req",\n
 ***  v1    0.4 debug|     {s,f,r,e} =
 {0x7f21f7c1aff0,+216,(nil),+57384},\n
 ***  v1    0.4 debug|   },\n
 ***  v1    0.4 debug|   http[req] = {\n
 ***  v1    0.4 debug|     ws = 0x7f21f7c191d0[req]\n
 ***  v1    0.4 debug|       "GET",\n
 ***  v1    0.4 debug|       "/",\n
 ***  v1    0.4 debug|       "HTTP/1.1",\n
 ***  v1    0.4 debug|       "X-Forwarded-For: 127.0.0.1",\n
 ***  v1    0.4 debug|   },\n
 ***  v1    0.4 debug|   http[resp] = {\n
 ***  v1    0.4 debug|     ws = 0x7f21f7c191d0[req]\n
 ***  v1    0.4 debug|       "HTTP/1.1",\n
 ***  v1    0.4 debug|       "503",\n
 ***  v1    0.4 debug|       "Service Unavailable",\n
 ***  v1    0.4 debug|       "Date: Wed, 29 Oct 2014 09:26:34 GMT",\n
 ***  v1    0.4 debug|       "Server: Varnish",\n
 ***  v1    0.4 debug|       "X-Varnish: 1001",\n
 ***  v1    0.4 debug|       "Content-Type: text/html; charset=utf-8",\n
 ***  v1    0.4 debug|       "Retry-After: 5",\n
 ***  v1    0.4 debug|   },\n
 ***  v1    0.4 debug|   vcl = {\n
 ***  v1    0.4 debug|     srcname = {\n
 ***  v1    0.4 debug|       "input",\n
 ***  v1    0.4 debug|       "Builtin",\n
 ***  v1    0.4 debug|     },\n
 ***  v1    0.4 debug|   },\n
 ***  v1    0.4 debug|   objcore (REQ) = 0x7f21f7c2a0c0 {\n
 ***  v1    0.4 debug|     refcnt = 1\n
 ***  v1    0.4 debug|     flags = 0x102\n
 ***  v1    0.4 debug|     objhead = 0x7f2202c69500\n
 ***  v1    0.4 debug|     stevedore = 0x7f2202c443c0 (malloc Transient)\n
 ***  v1    0.4 debug|   }\n
 ***  v1    0.4 debug| },\n
 ***  v1    0.4 debug| \n
 ***  v1    0.4 debug| \n
 ***  v1    0.4 debug| Child cleanup complete\n
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1621>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Oct 29 13:59:11 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 29 Oct 2014 13:59:11 -0000
Subject: [Varnish] #1343: Storage file handling is confused if file exists
In-Reply-To: <046.7e806953bab79cec3b63fad3eb7638f4@varnish-cache.org>
References: <046.7e806953bab79cec3b63fad3eb7638f4@varnish-cache.org>
Message-ID: <061.978b45ef3c232024e541d2710f6ab28b@varnish-cache.org>

#1343: Storage file handling is confused if file exists
----------------------+-----------------------------------------------
 Reporter:  lkarsten  |       Owner:  Martin Blix Grydeland <martin@?>
     Type:  defect    |      Status:  closed
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  trunk
 Severity:  minor     |  Resolution:  fixed
 Keywords:            |
----------------------+-----------------------------------------------

Comment (by kristian):

 For the record and for future troubleshooters (we ran into this on
 #varnish today and it took a while to map it to this bug):

 The original description is correct but somewhat misses the bigger point.
 It points out that the error message is misleading, but the real problem
 is that the calculation is plain wrong, and the error message would have
 been meaningful if the calculations to get there were correct.

 Part of the problem here is that it DID take existing file size into
 account, but incorrectly.  If the old size was 4GB and the new size was
 2GB, you'd check "if (2G-4G > fssize) { set size to 80% of fssize }". It
 would seem that the subtraction was done unsigned, since all variables are
 (correctly) unsigned. I'm somewhat surprised this wasn't caught by some
 warning, as this should have been cast to some signed type if my
 assumptions are correct...

 The result was that reducing size of -s file would blow the file up to 80%
 of fssize. Increasing file size would be treated fine, though still not
 taking sparseness into account I suppose.

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



From varnish-bugs at varnish-cache.org  Thu Oct 30 10:23:03 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 30 Oct 2014 10:23:03 -0000
Subject: [Varnish] #1506: Make better use of Content-Length information:
 Avoid chunked responses, more control over Range handling
In-Reply-To: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org>
References: <050.7446d258f6b1af112a619a4b721885a7@varnish-cache.org>
Message-ID: <065.67c83c05c51127f52bcb7c783a65b827@varnish-cache.org>

#1506: Make better use of Content-Length information: Avoid chunked responses,
more control over Range handling
--------------------------+----------------------------------
 Reporter:  DonMacAskill  |       Owner:  phk
     Type:  defect        |      Status:  closed
 Priority:  normal        |   Milestone:  Varnish 4.0 release
Component:  varnishd      |     Version:  4.0.0
 Severity:  critical      |  Resolution:  fixed
 Keywords:                |
--------------------------+----------------------------------
Changes (by Poul-Henning Kamp <phk@?>):

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


Comment:

 In [dec75e06706a0333d15473134ee368300fb42184]:
 {{{
 #!CommitTicketReference repository=""
 revision="dec75e06706a0333d15473134ee368300fb42184"
 Don't needlessly throw away Content-Length from backend, but assume
 it is sane and pass it to streaming clients, provided we don't munge
 the body along the way.

 Fixes: #1506
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1506#comment:11>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Oct 31 02:22:54 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 31 Oct 2014 02:22:54 -0000
Subject: [Varnish] #1622: Assert error in SES_ReleaseReq()
Message-ID: <046.acd8c975186a214407bc7a5094bc89aa@varnish-cache.org>

#1622: Assert error in SES_ReleaseReq()
-----------------------------+--------------------
 Reporter:  xieyugui         |       Type:  defect
   Status:  new              |   Priority:  normal
Milestone:  Varnish 4.0-TP2  |  Component:  build
  Version:  4.0.2            |   Severity:  normal
 Keywords:                   |
-----------------------------+--------------------
 Oct 30 23:32:56 localhost /xxx/varnish/var/varnish/cache[8135]: Child
 (8137) Panic message:#012Assert error in SES_ReleaseReq(),
 ../../include/tbl/acct_fields_req.h line 33:#012
 Condition((req->acct.req_hdrbytes) == 0) not true.#012thread = (cache-
 worker)#012ident =
 Linux,2.6.32-358.el6.x86_64,x86_64,-smalloc,-sfile,-sfile,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x431015: pan_ic+0xc5#012  0x43960d: SES_ReleaseReq+0x27d#012  0x43a203:
 SES_ScheduleReq+0xa3#012  0x423e90: hsh_rush+0xa0#012  0x42475d:
 HSH_DerefObjCore+0xad#012  0x424a63: HSH_DerefObj+0x33#012  0x434624:
 cnt_lookup+0x3d4#012  0x436391: CNT_Request+0x241#012  0x42b66b:
 HTTP1_Session+0x53b#012  0x439ec8: ses_req_pool_task+0x68#012req =
 0x7ecfd1501010 {#012  sp = 0x7ed1ea7fbdb0, vxid = 1109592047,  step =
 R_STP_LOOKUP,#012  req_body = R_BODY_NONE,#012  restarts = 0, esi_level =
 0#012  sp = 0x7ed1ea7fbdb0 {#012    fd = 1546, vxid = 35850216,#012
 client = 10.0.0.10 57241,#012    step = S_STP_WORKING,#012  },#012  worker
 = 0x7f29e017bc40 {#012    ws = 0x7f29e017be58 {#012      id = "wrk",#012
 {s,f,r,e} = {0x7f29e017a430,0x7f29e017a430,(nil),+6144},#012    },#012
 VCL::method = 0x0,#012  VCL::return = abandon,#012  },#012  ws =
 0x7ecfd15011a8 {#012    id = "req",#012    {s,f,r,e} =
 {0x7ecfd1505640,+880,(nil),+244176},#012  },#012  http[req] = {#012    ws
 = 0x7ecfd15011a8[req]#012      "GET",#012
 "/creative/93334/giukjobs.rnx_2014109.swf",#012      "HTTP/1.1",#012
 "Accept: */*",#012      "Accept-Language: zh-CN",#012      "Referer:
 http://xxx.com/ta.htm?sp=0,1184525,1183170,mm_26632206_2690592_21024578,0a67f5380000545259e55a01006401e0,9
 ,eH-XjB_p5o0=,60.177.167.45,0,0,",#012      "x-flash-version:
 15,0,0,189",#012      "User-Agent: Mozilla/5.0 (compatible; MSIE 9.0;
 Windows NT 6.1; Trident/5.0)",#012      "grace: none",#012      "X
 -Forwarded-For: 10.0.0.10, 10.0.0.10",#012      "Host:
 static.mlt01.com",#012      "Accept-Encoding: gzip",#012  },#012  vcl =
 {#012    srcname = {#012      "input",#012      "Builtin",#012    },#012
 },#012

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1622>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Oct 31 02:26:25 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 31 Oct 2014 02:26:25 -0000
Subject: [Varnish] #1622: Assert error in SES_ReleaseReq()
In-Reply-To: <046.acd8c975186a214407bc7a5094bc89aa@varnish-cache.org>
References: <046.acd8c975186a214407bc7a5094bc89aa@varnish-cache.org>
Message-ID: <061.8977ca979a2a3915ca4b540560e4ea3a@varnish-cache.org>

#1622: Assert error in SES_ReleaseReq()
----------------------+------------------------------
 Reporter:  xieyugui  |       Owner:
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:  Varnish 4.0-TP2
Component:  build     |     Version:  4.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+------------------------------

Comment (by xieyugui):

 At first, an error?

 Oct 24 22:20:19 localhost /xxx/varnish/var/varnish/cache[18102]: Child
 (7752) not responding to CLI, killing it.
 Oct 24 22:20:20 localhost /xxx/varnish/var/varnish/cache[18102]: Child
 (7752) died signal=6
 Oct 24 22:20:20 localhost /xxx/varnish/var/varnish/cache[18102]: Child
 (7752) Panic message:#012Assert error in SES_ScheduleReq(),
 cache/cache_session.c line 229:#012  Condition((sp)->magic == 0x2c2f9c5a)
 not true.#012thread = (cache-worker)#012ident =
 Linux,2.6.32-358.el6.x86_64,x86_64,-smalloc,-sfile,-sfile,-smalloc,-hcritbit,epoll#012Backtrace:#012
 0x4310e5: pan_ic+0xc5#012  0x43a3b4: SES_ScheduleReq+0x184#012  0x423f30:
 hsh_rush+0xa0#012  0x42482d: HSH_DerefObjCore+0xad#012  0x424b33:
 HSH_DerefObj+0x33#012  0x4346f4: cnt_lookup+0x3d4#012  0x436461:
 CNT_Request+0x241#012  0x42b73b: HTTP1_Session+0x53b#012  0x439f98:
 ses_req_pool_task+0x68#012  0x433b87: Pool_Work_Thread+0x357#012req =
 0x7eba12fb6670 {#012  sp = 0x7eba07b832f0, vxid = 1083220271,  step =
 R_STP_LOOKUP,#012  req_body = R_BODY_NONE,#012  restarts = 0, esi_level =
 0#012  sp = 0x7eba07b832f0 {#012    fd = 1089, vxid = 9478446,#012
 client = 10.0.0.11 64691,#012    step = S_STP_WORKING,#012  },#012  worker
 = 0x7f0a8c15bc40 {#012    ws = 0x7f0a8c15be58 {#012      id = "wrk",#012
 {s,f,r,e} = {0x7f0a8c15a430,0x7f0a8c15a430,(nil),+6144},#012    },#012
 VCL::method = 0x0,#012  VCL::return = abandon,#012  },#012  ws =
 0x7eba12fb6808 {#012    id = "req",#012    {s,f,r,e} =
 {0x7eba12fbaca0,+544,(nil),+244176},#012  },#012  http[req] = {#012    ws
 = 0x7eba12fb6808[req]#012      "GET",#012
 "/manhuatuku/6938/201287161859700.jpg",#012      "HTTP/1.1",#012
 "referer: http://www.xxxx.com//manhua/6938/167493.html",#012      "User-
 Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.31 (KHTML, like
 Gecko) Chrome/26.0.1410.64 Safari/537.31",#012      "grace: none",#012
 "X-Forwarded-For: 10.0.0.11, 10.0.0.11",#012      "Host:
 cartoon.jide123.cc",#012  },#012  vcl = {#012    srcname = {#012
 "input",#012      "Builtin",#012    },#012  },#012},#012

 then ,I find this ?https://www.varnish-
 cache.org/trac/changeset/9a2a221c713b7329231d7a1b9e996a4a41eedcf2
 and Repair it

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



From varnish-bugs at varnish-cache.org  Fri Oct 31 09:33:07 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 31 Oct 2014 09:33:07 -0000
Subject: [Varnish] #1606: Assert error in VDI_Finish(),
 cache/cache_director.c line 120:
In-Reply-To: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>
References: <049.99660975cfc76f7b9ee0416228fefa34@varnish-cache.org>
Message-ID: <064.6d08149c47f0ff3d537ce99726cfc689@varnish-cache.org>

#1606: Assert error in VDI_Finish(), cache/cache_director.c line 120:
-------------------------+--------------------
 Reporter:  cache_layer  |       Owner:  phk
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:
Component:  build        |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+--------------------

Comment (by lkarsten):

 I'm seeing this on the last Fryer run as well. Happened about 40 seconds
 into the run.

 {{{
 Last panic at: Fri, 31 Oct 2014 01:49:56 GMT
 Assert error in VDI_Finish(), cache/cache_director.c line 120:
   Condition(bo->director_state != DIR_S_NULL) not true.
 thread = (cache-worker)
 version = varnish-trunk revision 77849fd
 ident = Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll
 Backtrace:
   0x43b963: pan_backtrace+0x19
   0x43bc94: pan_ic+0x209
   0x41b803: VDI_Finish+0x20e
   0x45d10f: V1F_fetch_hdr+0x7f0
   0x4103d0: vbe_dir_gethdrs+0x30d
   0x41b3cf: VDI_GetHdr+0x182
   0x425950: vbf_stp_startfetch+0x35e
   0x4284c0: vbf_fetch_thread+0x41c
   0x43e173: Pool_Work_Thread+0x503
   0x456d6b: WRK_Thread+0x34d
   busyobj = 0x7f515c0122b0 {
     ws = 0x7f515c012370 {
       id = "bo",
       {s,f,r,e} = {0x7f515c014218,+592,(nil),+57488},
     },
   refcnt = 2
   retries = 0
   failed = 0
   state = 1
     is_do_stream
     bodystatus = 0 (none),
     },
     http[bereq] = {
       ws = 0x7f515c012370[bo]
         "GET",
         "/cacheabledata/set_medialibrary1/file391.bin",
         "HTTP/1.1",
         "Host: fryer1.varnish-software.com:6081",
         "Accept: */*",
         "Accept-Encoding: gzip",
         "User-Agent: Mozilla/5.0 (unknown-x86_64-linux-gnu) Siege/3.0.4",
         "X-Forwarded-For: 194.31.39.161",
         "X-Varnish: 1343512",
     },
     http[beresp] = {
       ws = 0x7f515c012370[bo]
     },
   objcore (FETCH) = 0x7f50bc021e80 {
     refcnt = 2
     flags = 0x2
     objhead = 0x7f50bc021930
     stevedore = (nil)
   }
   }
 }}}

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



From varnish-bugs at varnish-cache.org  Fri Oct 31 12:26:26 2014
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 31 Oct 2014 12:26:26 -0000
Subject: [Varnish] #1623: varnishhist -d segfault
Message-ID: <046.76e8f76d5dcfa6795373e0508a173d93@varnish-cache.org>

#1623: varnishhist -d segfault
----------------------+-------------------
 Reporter:  lkarsten  |      Owner:
     Type:  defect    |     Status:  new
 Priority:  normal    |  Milestone:
Component:  build     |    Version:  4.0.2
 Severity:  normal    |   Keywords:
----------------------+-------------------
 varnishhist run with the -d argument leads to a segmentation fault.

 Expected result: A dumped ascii graph to stdout, and then exit.
 (or whatever the current exit behaviour of -d with varnishlog is)

 (output cleaned up)
 {{{
 lkarsten at sierra:~$ /usr/bin/varnishhist -d 1>/dev/null
 Assert error in accumulate(), varnishhist.c line 267:

     Condition(bucket_hit[j] > 0) not true.
 errno = 34 (Numerical result out of range)
 Aborted (core dumped)
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1623>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator