From varnish-bugs at varnish-cache.org Sat Nov 1 15:38:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 01 Nov 2014 15:38:57 -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.34ff187f93dbadc8ebf8bd97c36bd29c@varnish-cache.org> #1622: Assert error in SES_ReleaseReq() ----------------------+------------------------------ Reporter: xieyugui | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP2 Component: build | Version: 4.0.2 Severity: normal | Resolution: duplicate Keywords: | ----------------------+------------------------------ Changes (by fgsch): * status: new => closed * resolution: => duplicate Comment: Dup of #1607 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 3 10:07:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Nov 2014 10:07:12 -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.55e57bdd78392661481c76829192c73f@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 phk): I think this is fixed in 0659213076e177bfba810f316d2b7abfb07541e5, please report back. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 3 10:34:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Nov 2014 10:34:43 -0000 Subject: [Varnish] #1620: ESI asserts when no threads are available In-Reply-To: <044.835601ea2e67939602ff155a91200ecb@varnish-cache.org> References: <044.835601ea2e67939602ff155a91200ecb@varnish-cache.org> Message-ID: <059.4d30c7ea812ba427bb5fd3909b351f7a@varnish-cache.org> #1620: ESI asserts when no threads are available --------------------+---------------------------------------- Reporter: martin | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [969674dcb3b4d430a38b7f1b1e41199b25cc8491]: {{{ #!CommitTicketReference repository="" revision="969674dcb3b4d430a38b7f1b1e41199b25cc8491" Don't attempt to run the fetch in the request thread if there are no threads available in the pool, fail the fetch and count it. Fixes #1620 Fixes #1621 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 3 10:34:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Nov 2014 10:34:43 -0000 Subject: [Varnish] #1621: Synth code path fails when no backend threads are available In-Reply-To: <044.d6b22920154b20eb08a93044b39fd41e@varnish-cache.org> References: <044.d6b22920154b20eb08a93044b39fd41e@varnish-cache.org> Message-ID: <059.9f6a7403c89898a84ffc4b9694b167b6@varnish-cache.org> #1621: Synth code path fails when no backend threads are available ----------------------+---------------------------------------- Reporter: martin | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [969674dcb3b4d430a38b7f1b1e41199b25cc8491]: {{{ #!CommitTicketReference repository="" revision="969674dcb3b4d430a38b7f1b1e41199b25cc8491" Don't attempt to run the fetch in the request thread if there are no threads available in the pool, fail the fetch and count it. Fixes #1620 Fixes #1621 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 3 10:55:22 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Nov 2014 10:55:22 -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.88dc27ee191e5e3a4ad6d040bfe6b3c3@varnish-cache.org> #1613: keep-alive is enabled even if req.http.Connection is set to "close" ----------------------+---------------------------------------- Reporter: zviratko | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [bb75c9cdda5f389adae15b68c79d2023d79ed873]: {{{ #!CommitTicketReference repository="" revision="bb75c9cdda5f389adae15b68c79d2023d79ed873" Don't add another Connection: header if we already have one, but do insist on it being "close" if we need that. Test case by daghf Fixes #1613 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 3 13:07:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Nov 2014 13:07:55 -0000 Subject: [Varnish] #1611: Unreferenced counters In-Reply-To: <043.ca60d02c4bb03bb598dd3994a53a3ab2@varnish-cache.org> References: <043.ca60d02c4bb03bb598dd3994a53a3ab2@varnish-cache.org> Message-ID: <058.2afff52c3729cf01acc9d9a98e76e3c7@varnish-cache.org> #1611: Unreferenced counters --------------------+---------------------------------------- Reporter: daghf | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [cbcfce5ca13ccc787ab5c7294e551bbf594a6349]: {{{ #!CommitTicketReference repository="" revision="cbcfce5ca13ccc787ab5c7294e551bbf594a6349" Remove two unused counters The sms_ counters were removed previously Fixes #1611 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 3 13:08:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Nov 2014 13:08:50 -0000 Subject: [Varnish] #1611: Unreferenced counters In-Reply-To: <043.ca60d02c4bb03bb598dd3994a53a3ab2@varnish-cache.org> References: <043.ca60d02c4bb03bb598dd3994a53a3ab2@varnish-cache.org> Message-ID: <058.7f482a51335acabf0904f27ae796406e@varnish-cache.org> #1611: Unreferenced counters --------------------+---------------------------------------- Reporter: daghf | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Comment (by phk): I'm leaving sess_drop for now, that code us being worked on. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 3 14:49:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Nov 2014 14:49:53 -0000 Subject: [Varnish] #1369: Spinning thread while esi+gzip fetch In-Reply-To: <046.a959baf0eee18a6849c8587f6527406f@varnish-cache.org> References: <046.a959baf0eee18a6849c8587f6527406f@varnish-cache.org> Message-ID: <061.8b1d65daf62155d7a2cf31d027bdb15b@varnish-cache.org> #1369: Spinning thread while esi+gzip fetch ----------------------+--------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: 3.0.6 is out. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 6 06:07:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 Nov 2014 06:07:29 -0000 Subject: [Varnish] #1624: Panic: Assert error in VDP_gunzip(), cache/cache_gzip.c line 314: Condition((vg->m_len) == 0) not true. Message-ID: <048.198f1f2f38ffde2358689766aae2d6ab@varnish-cache.org> #1624: Panic: Assert error in VDP_gunzip(), cache/cache_gzip.c line 314: Condition((vg->m_len) == 0) not true. ------------------------------+---------------------- Reporter: esfourteen | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: panic VDP_gunzip | ------------------------------+---------------------- Using latest source from master on github (rev 69a4711e346f356a8dc4161aac8c6f663e91c295), panic occurs extremely frequently (every 30 seconds or so) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 7 13:17:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Nov 2014 13:17:25 -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.f5824aa2d3f15fd9b21a6544572f23a1@varnish-cache.org> #1612: Bug with Transfer-Encoding and zero-byte chunks (and keep-alive) ----------------------+---------------------------------------- Reporter: zviratko | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Martin Blix Grydeland ): In [419a08f5362a0b9885ecae5cc443fb82e2c3c002]: {{{ #!CommitTicketReference repository="" revision="419a08f5362a0b9885ecae5cc443fb82e2c3c002" Fix a cornercase related to empty pass objects. Fixes #1612 Testcase by: daghf Conflicts: bin/varnishd/cache/cache_http1_deliver.c }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 7 13:17:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Nov 2014 13:17:25 -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.ea67b8868de0a78ea38d77f8a02ab41c@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: | --------------------------+---------------------------------- Comment (by Martin Blix Grydeland ): In [535d44b8909ee88e8700a35bed79f9ca77e445a4]: {{{ #!CommitTicketReference repository="" revision="535d44b8909ee88e8700a35bed79f9ca77e445a4" 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. The ungzip'ed length stored as attribute has not been backported to 4.0, meaning on-the-fly ungzip will be delivered chunked. Fixes: #1506 Conflicts: bin/varnishd/cache/cache_fetch.c }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Nov 8 01:50:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 08 Nov 2014 01:50:30 -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.1f314de2162daef76572a50ccbafa28a@varnish-cache.org> #1616: RH packages for varnish4 installs headers at the wrong place ------------------------+----------------------- Reporter: mfournier | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: 4.0.2 Severity: normal | Resolution: fixed Keywords: rpm redhat | ------------------------+----------------------- Changes (by Federico G. Schwindt ): * status: new => closed * resolution: => fixed Comment: In [61cdf24bb88a18d175c8b6e1c4dc26593728fa27]: {{{ #!CommitTicketReference repository="" revision="61cdf24bb88a18d175c8b6e1c4dc26593728fa27" Install _all_ headers under ${prefix}/include/.. Fixes #1616 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 10 09:27:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Nov 2014 09:27:57 -0000 Subject: [Varnish] #1624: Panic: Assert error in VDP_gunzip(), cache/cache_gzip.c line 314: Condition((vg->m_len) == 0) not true. In-Reply-To: <048.198f1f2f38ffde2358689766aae2d6ab@varnish-cache.org> References: <048.198f1f2f38ffde2358689766aae2d6ab@varnish-cache.org> Message-ID: <063.d3ec7d8d7081c5559f76b4882397d9d7@varnish-cache.org> #1624: Panic: Assert error in VDP_gunzip(), cache/cache_gzip.c line 314: Condition((vg->m_len) == 0) not true. ------------------------------+---------------------------------------- Reporter: esfourteen | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: panic VDP_gunzip | ------------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [980243cbc53faa5f28fda402dee09bcec47c2bcf]: {{{ #!CommitTicketReference repository="" revision="980243cbc53faa5f28fda402dee09bcec47c2bcf" Don't panic on incomplete VDP::gunzip, the backend may have abandonned us. Fixes #1624 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 10 14:27:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Nov 2014 14:27:30 -0000 Subject: [Varnish] #1623: varnishhist -d segfault In-Reply-To: <046.76e8f76d5dcfa6795373e0508a173d93@varnish-cache.org> References: <046.76e8f76d5dcfa6795373e0508a173d93@varnish-cache.org> Message-ID: <061.b15c75d579e792fabb8866193dcc9f2c@varnish-cache.org> #1623: varnishhist -d segfault ----------------------+----------------------------------------------- Reporter: lkarsten | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [14a926bd7b51b89da7a5bc4cfe9ffbeeeb443e40]: {{{ #!CommitTicketReference repository="" revision="14a926bd7b51b89da7a5bc4cfe9ffbeeeb443e40" Use n + hist_buckets as hit flag in varnishhist bucket history Because -0 == +0, the use of negative numbers as a distinction between hits and misses in the recorded bucket history fails when there are entries of index 0. Fixes: #1623 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 10 15:51:09 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Nov 2014 15:51:09 -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.78c229ced19572a6c4e05073735d1bbc@varnish-cache.org> #1596: Panic message:#012Assert error in vbf_fetch_thread() --------------------+----------------------------------------------- Reporter: webi | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | --------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * owner: => Martin Blix Grydeland * resolution: => fixed Comment: In [887c70e64516136121d9a7492aab85c18054fd55]: {{{ #!CommitTicketReference repository="" revision="887c70e64516136121d9a7492aab85c18054fd55" Delay HSH_Complete() until the storage sanity functions has finished. This fixes a race where the client started freeing the body (which it does in the case of new hit-for-pass object being inserted) before the sanity functions were run. Fixes: #1596 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 11 10:25:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 Nov 2014 10:25:57 -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.ba0d9058047fdeedb5529675b40fe8df@varnish-cache.org> #1462: ReqURL is emitted twice --------------------+----------------------------------------------- Reporter: scoof | Owner: Martin Blix Grydeland Type: defect | Status: reopened Priority: normal | Milestone: Varnish 4.0-TP2 Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+----------------------------------------------- Comment (by lkarsten): Related/closed duplicate: #1619 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 11 21:41:47 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 Nov 2014 21:41:47 -0000 Subject: [Varnish] #1625: if(req.backend_hint == b1) compiles, but does nothing Message-ID: <049.31d68d5e448809c705a9e47a94fc94ce@varnish-cache.org> #1625: if(req.backend_hint == b1) compiles, but does nothing -------------------------+-------------------- Reporter: huguesalary | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.2 | Severity: normal Keywords: | -------------------------+-------------------- In vcl_deliver, I'm currently trying to detect which backend a request was sent to. I originally tried to detect which **director** a request was assigned to, but I found this bug report: https://www.varnish- cache.org/trac/ticket/1502 and realized that doing {{{ if ( req.backend_hint == name-of-director ) { } }}} is not possible, and **will never be**. However, the following code snippet compiles correctly, but does not actually work: {{{ backend b0 { .host = "127.0.0.1"; .port = "80"; } backend b1 { .host = "127.0.0.1"; .port = "80"; } sub vcl_init { new a = directors.round_robin(); a.add_backend(b0); new b = directors.round_robin(); b.add_backend(b1); } sub vcl_recv { if(std.random(1,100) <= 50) { set req.backend_hint = a.backend(); } else { set req.backend_hint = b.backend(); } } sub vcl_deliver { if(req.backend_hint == b1) { set resp.http.Test = "something; } else { set resp.http.Test = "something else"; } } }}} The {{{ if }}} condition in //vcl_deliver// always fails and executes the {{{ else }}}. My guess is that my code is not valid (and will never be), however, if that is the case, I'd expect it to not compile. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 11 23:30:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 Nov 2014 23:30:04 -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.be6bd38be30c9a21092a35d25e38107e@varnish-cache.org> #1525: free() in VBO_DerefBusyObj causes child crash ----------------------+------------------------- Reporter: joakim | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by fgsch): * status: needinfo => closed * resolution: => worksforme Comment: Timed out. Please try a more recent release and open a new ticket if it's still occurring. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 11 23:30:40 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 Nov 2014 23:30:40 -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.7bfc95f36a2bf9f87611f0a3a2a4914c@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: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by fgsch): * status: needinfo => closed * resolution: => worksforme Comment: Timed out. Please try a more recent release and open a new ticket if it's still occurring. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 11 23:31:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 Nov 2014 23:31:43 -0000 Subject: [Varnish] #1520: m00011.vtc fails on x86_64 In-Reply-To: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> References: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> Message-ID: <061.2c35e7b34d9d0ef41a679528d0dbf185@varnish-cache.org> #1520: m00011.vtc fails on x86_64 -------------------------+------------------------- Reporter: yoloseem | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 4.0.0 Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Changes (by fgsch): * status: needinfo => closed * resolution: => worksforme Comment: Timed out. Please try a more recent release and open a new ticket if it's still occurring. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 12 12:06:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 Nov 2014 12:06:24 -0000 Subject: [Varnish] #1626: Message from VCC-compiler: Cannot read file '/varnish/etc/jide123_cc.vcl': No such file or directory Message-ID: <046.a769ec7c66d244cfc5db813b0fba866c@varnish-cache.org> #1626: Message from VCC-compiler: Cannot read file '/varnish/etc/jide123_cc.vcl': No such file or directory ----------------------+-------------------- Reporter: xieyugui | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.2 | Severity: normal Keywords: | ----------------------+-------------------- my vcl : if (utils.exists("/varnish/etc/jide123_cc.vcl")) { include "/varnish/etc/jide123_cc.vcl"; } else { acartoon_cluster.add_backend(acartoon_backend0); } /varnish/sbin/varnishd -f /varnish/etc/default.vcl -C get a error: Message from VCC-compiler: Cannot read file '/varnish/etc/jide123_cc.vcl': No such file or directory I have to judge whether the file exists, but why I get a error -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 12 12:14:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 Nov 2014 12:14:38 -0000 Subject: [Varnish] #1626: Message from VCC-compiler: Cannot read file '/varnish/etc/jide123_cc.vcl': No such file or directory In-Reply-To: <046.a769ec7c66d244cfc5db813b0fba866c@varnish-cache.org> References: <046.a769ec7c66d244cfc5db813b0fba866c@varnish-cache.org> Message-ID: <061.a8e6d98ed40044292ed3cf1a6001f5d0@varnish-cache.org> #1626: Message from VCC-compiler: Cannot read file '/varnish/etc/jide123_cc.vcl': No such file or directory ----------------------+---------------------- Reporter: xieyugui | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: invalid Keywords: | ----------------------+---------------------- Changes (by fgsch): * status: new => closed * resolution: => invalid Comment: include is done at compilation time, if the file is not there when the VCL is being loaded it will fail (as you realised). You cannot include a file only if it's present so the test above is a nop in this case. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 12 12:19:52 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 Nov 2014 12:19:52 -0000 Subject: [Varnish] #1626: Message from VCC-compiler: Cannot read file '/varnish/etc/jide123_cc.vcl': No such file or directory In-Reply-To: <046.a769ec7c66d244cfc5db813b0fba866c@varnish-cache.org> References: <046.a769ec7c66d244cfc5db813b0fba866c@varnish-cache.org> Message-ID: <061.982b62be75fe21dea4c1d86c73622a50@varnish-cache.org> #1626: Message from VCC-compiler: Cannot read file '/varnish/etc/jide123_cc.vcl': No such file or directory ----------------------+---------------------- Reporter: xieyugui | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: invalid Keywords: | ----------------------+---------------------- Comment (by xieyugui): thinks,I realized that my way is wrong -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 13 14:12:35 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 13 Nov 2014 14:12:35 -0000 Subject: [Varnish] #1627: Response where you have do_gzip and do_stream enabled return a wrong content-length to HTTP/1.0 clients Message-ID: <041.a4ee8870cc795a7f4ced77cec3172663@varnish-cache.org> #1627: Response where you have do_gzip and do_stream enabled return a wrong content-length to HTTP/1.0 clients -------------------+-------------------- Reporter: tnt | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.6 | Severity: normal Keywords: | -------------------+-------------------- During a streaming requests, if varnish gzip the object itself, the final content-length is unknown. Usually this yields a transfer-encoding chunked response and it works out. But if the client is HTTP/1.0, it will actually try to use a content-length and serve a bad one (the one of the uncompressed object). See the attached patch for the proposed fix. Basically in stream_start, instead of replacing the content-length is res_mode != CHUNKED, I always remove it, and only re-add the correct one only if RES_LEN is the mode. For HTTP 1.0, RES_EOF will be the one chosen and so no content-length will be present at all. The minimal VCL I use to test this : {{{ backend i_test { .host = "87.98.160.55"; .port = "80"; } sub vcl_recv { set req.backend = i_test; return (pass); } sub vcl_pass { # Prevent backend from gzipping ... # (that's not in prod, but in prod my backend can't gzip while # the http server I use as backend for testing can gzip so # I prevent it to using this) remove bereq.http.Accept-Encoding; } sub vcl_fetch { set beresp.do_stream = true; set beresp.do_gzip = true; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 14 10:07:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Nov 2014 10:07:55 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() Message-ID: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ---------------------------------+---------------------- Reporter: Jay | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: varnishd Version: trunk | Severity: normal Keywords: | ---------------------------------+---------------------- Assert error in VBO_DerefBusyObj(), cache/cache_busyobj.c line 171: Condition((bo) != NULL) not true. thread = (cache-worker) version = varnish-trunk revision NOGIT ident = Linux,3.14.22,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4325df: pan_ic+0xef 0x41826d: VBO_DerefBusyObj+0x32d 0x42394a: VBF_Fetch+0x29a 0x4379b0: CNT_Request+0x16c0 0x44cc9b: HTTP1_Session+0x41b 0x4398d7: ses_req_pool_task+0x67 0x43a814: SES_pool_accept_task+0x2b4 0x434b3e: Pool_Work_Thread+0x36e 0x447653: WRK_Thread+0x103 0x433a8b: pool_thread+0x2b req = 0x7f15cd2317b0 { sp = 0x7f15cc89b790, vxid = 57754958, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7f15cc89b790 { fd = 3181, vxid = 57754957, client = xxxx 52155, step = S_STP_WORKING, }, worker = 0x7f15dc5c6c50 { stack = {0x7f15dc5c7000 -> 0x7f15dc5bb000} ws = 0x7f15dc5c6e60 { id = "wrk", {s,f,r,e} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 14 13:55:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Nov 2014 13:55:55 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.13c1b8dc658e3b10a93163b3ee51dbac@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Changes (by fgsch): * status: new => needinfo Comment: Which version is this? Please also provide the full backtrace. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 14 13:57:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Nov 2014 13:57:07 -0000 Subject: [Varnish] #1627: Response where you have do_gzip and do_stream enabled return a wrong content-length to HTTP/1.0 clients In-Reply-To: <041.a4ee8870cc795a7f4ced77cec3172663@varnish-cache.org> References: <041.a4ee8870cc795a7f4ced77cec3172663@varnish-cache.org> Message-ID: <056.cfc4204b5e4acc3fcd27c1c45d7ee933@varnish-cache.org> #1627: Response where you have do_gzip and do_stream enabled return a wrong content-length to HTTP/1.0 clients --------------------+-------------------- Reporter: tnt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.6 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by fgsch): FWIW, test passes in master and 4.0. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 14 14:05:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Nov 2014 14:05:44 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.c8952ba5d924835a03a7005238e5e24b@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by Jay): Replying to [comment:1 fgsch]: > Which version is this? > > Please also provide the full backtrace. 4.0.2 trunk from 2014-11-11 This was the entire log entry from syslog. Don't have a core. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Nov 15 10:34:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 15 Nov 2014 10:34:50 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.a32858461081edad337e5929d6659c62@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Description changed by fgsch: Old description: > Assert error in VBO_DerefBusyObj(), cache/cache_busyobj.c line 171: > Condition((bo) != NULL) not true. > thread = (cache-worker) version = varnish-trunk revision NOGIT ident = > Linux,3.14.22,x86_64,-smalloc,-smalloc,-hcritbit,epoll > > Backtrace: 0x4325df: pan_ic+0xef 0x41826d: VBO_DerefBusyObj+0x32d > 0x42394a: VBF_Fetch+0x29a 0x4379b0: CNT_Request+0x16c0 0x44cc9b: > HTTP1_Session+0x41b 0x4398d7: ses_req_pool_task+0x67 0x43a814: > SES_pool_accept_task+0x2b4 0x434b3e: Pool_Work_Thread+0x36e 0x447653: > WRK_Thread+0x103 0x433a8b: pool_thread+0x2b req = 0x7f15cd2317b0 { sp > = 0x7f15cc89b790, vxid = 57754958, step = R_STP_LOOKUP, req_body = > R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7f15cc89b790 { fd > = 3181, vxid = 57754957, client = xxxx 52155, step = > S_STP_WORKING, }, worker = 0x7f15dc5c6c50 { stack = > {0x7f15dc5c7000 -> 0x7f15dc5bb000} ws = 0x7f15dc5c6e60 { id = > "wrk", {s,f,r,e} New description: {{{ Assert error in VBO_DerefBusyObj(), cache/cache_busyobj.c line 171: Condition((bo) != NULL) not true. thread = (cache-worker) version = varnish-trunk revision NOGIT ident = Linux,3.14.22,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4325df: pan_ic+0xef 0x41826d: VBO_DerefBusyObj+0x32d 0x42394a: VBF_Fetch+0x29a 0x4379b0: CNT_Request+0x16c0 0x44cc9b: HTTP1_Session+0x41b 0x4398d7: ses_req_pool_task+0x67 0x43a814: SES_pool_accept_task+0x2b4 0x434b3e: Pool_Work_Thread+0x36e 0x447653: WRK_Thread+0x103 0x433a8b: pool_thread+0x2b req = 0x7f15cd2317b0 { sp = 0x7f15cc89b790, vxid = 57754958, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7f15cc89b790 { fd = 3181, vxid = 57754957, client = xxxx 52155, step = S_STP_WORKING, }, worker = 0x7f15dc5c6c50 { stack = {0x7f15dc5c7000 -> 0x7f15dc5bb000} ws = 0x7f15dc5c6e60 { id = "wrk", {s,f,r,e} }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Nov 16 23:18:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 16 Nov 2014 23:18:42 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.d2dceb1bb93eac04cd648623bfb9d47a@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by franveux): I've got the same error 5 times in 2 days. Here is trace from syslog. It happens on MISS or PASS (VCL::method). Hope this will help. {{{ Child (28841) Panic message: Assert error in VBO_DerefBusyObj(), cache/cache_busyobj.c line 171: Condition((bo) != NULL) not true.[[BR]] thread = (cache-worker) version = varnish-trunk revision a221996 ident = Linux,3.13.0-37-generic,x86_64,-smalloc,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4328e4: pan_ic+0xf4 0x4183d9: VBO_DerefBusyObj+0x369 0x423b5e: VBF_Fetch+0x2ce 0x437b7d: CNT_Request+0x130d 0x44d63b: HTTP1_Session+0x77b 0x439e07: ses_req_pool_task+0x67 0x43ad5a: SES_pool_accept_task+0x2ca 0x4350e8: Pool_Work_Thread+0x358 0x447c61: WRK_Thread+0x111 0x433e7b: pool_thread+0x2b req = 0x7f2c57339c00 { sp = 0x7f2d66407970, vxid = 9756460, step = R_STP_MISS, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7f2d66407970 { fd = 2814, vxid = 9756459, client = 80.12.XXX.1 52435, step = S_STP_WORKING, }, worker = 0x7f2ebfb06c70 { stack = {0x7f2ebfb07000 -> 0x7f2ebfafb000} ws = 0x7f2ebfb06e80 { id = "wrk", {s,f,r,e} = {0x7f2ebfb06460,0x7f2ebfb06460,(nil),+2040}, }, VCL::method = MISS, VCL::return = fetch, VCL::methods = {RECV, PIPE, PASS, HASH, MISS, HIT, DELIVER, BACKEND_FETCH, BACKEND_RESPONSE}, }, ws = 0x7f2c57339db0 { id = "req", {s,f,r,e} = {0x7f2c5733bbd0,+1000,(nil),+57384}, }, http[req] = { ws = 0x7f2c57339db0[req] "GET", "/reaction/attach_article_liste?article_id=142XXXX&title=La%20XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXtifs%20de%20r%C3%A9duction%20de%20ses%20gaz%20%C3%A0%20effet%20de%20serre%20%3F&output=JSON&media_code=seamen&check=1&date=1415977107.000000", "HTTP/1.1", "Host: apiXXXXXXXXXXXXXXXXX.com", "Accept: */*", "Cookie: RMFL=011XEZseU1011WrXXXXXXXXXXXXX1XE; _ga=GA1.2.1634744289.1369299457; xtidc=1304XXXXXXX6206392; __utma=163XXXXXXXXXXXXX4289.1369299457.1392368585.1394796293.107; CoreM_State=3~-1~-1~-1~-1~6~6~6~10~10~7~7~|~~|~~|~~|~||||||~|~~|~~|~~|~~|~~|~~|~~|~; CoreM_State_Content=6~|~93E7406300C435F6~4304E2414848F762~C6C74508251CEEF6~B4D4BE839E7D5F91~812BC5ADDCCA42C8~BF8A8E8B92BFC6A4~|~0~1~2~3~4~5; CoreID6=65923101541313807417965&ci=50430000|XXXXXXXXXXXXXXXXXXXXX0000|TRNO; xtvrn=$354102$353617$", "Connection: keep-alive", "Accept-Language: fr-fr", "User-Agent: XXXXXXXX%20&%20A/35 CFNetwork/609 Darwin/13.0.0", "X-Forwarded-For: 80.12.XX.XXX", "Accept-Encoding: gzip", }, vcl = { srcname = { "input", "Builtin", "local.vcl", "purge.vcl", }, }, objcore (REQ) = 0x7f2e80146270 { refcnt = 2 flags = 0x202 objhead = 0x7f2d9f27ce60 stevedore = (nil) } }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 17 09:04:39 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Nov 2014 09:04:39 -0000 Subject: [Varnish] #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 Message-ID: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 -----------------------------+---------------------- Reporter: xieyugui | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0-TP2 | Component: varnishd Version: 4.0.2 | Severity: normal Keywords: | -----------------------------+---------------------- Nov 17 16:52:01 localhost /xxx/varnish/var/varnish/cache[17234]: Child (17236) 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 0x424161: HSH_Unbusy+0xf1#012 0x41ea46: vbf_stp_fetch+0x526#012 0x41f0db: vbf_fetch_thread+0x20b#012 0x433ab7: Pool_Work_Thread+0x357#012 0x446719: wrk_thread_real+0xb9#012 0x7f8ec1abf9d1: /lib64/libpthread.so.0(+0x79d1) [0x7f8ec1abf9d1]#012 busyobj = 0x7f45f8e9b240 {#012 ws = 0x7f45f8e9b300 {#012 id = "bo",#012 {s,f,r,e} = {0x7f45f8e9f868,+1856,(nil),+113112},#012 },#012 refcnt = 2#012 retries = 0#012 failed = 0#012 state = 1#012 is_do_stream#012 is_is_gunzip#012 is_should_close#012 bodystatus = 3 (length),#012 },#012 http[bereq] = {#012 ws = 0x7f45f8e9b300[bo]#012 "GET",#012 "/manhuatuku/3670/20131031161810322.jpg",#012 "HTTP/1.1",#012 "X-Real-IP: 127.0.0.1",#012 "User-Agent: Mozilla/5.0",#012 "Referer: http://www.xxx.com/manhua/3670/240059.html?p=5",#012 "X-Forwarded- For: 10.0.0.21, 127.0.0.1, 10.0.0.22, 10.0.0.22",#012 "Host: cartoon.xxxx.cc",#012 "grace: none",#012 "Accept-Encoding: gzip",#012 "X-Varnish: 233308163",#012 "connection: close",#012 },#012 http[beresp] = {#012 ws = 0x7f45f8e9b300[bo]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Cache-Control: max-age=31536000",#012 "Content- Type: image/jpeg",#012 "Last-Modified: Thu, 31 Oct 2013 08:18:10 GMT",#012 "Accept-Ranges: bytes",#012 "ETag: "578437bc11d6ce1:0"",#012 "Server: Microsoft-IIS/7.5",#012 "Date: Mon, 17 Nov 2014 08:48:40 GMT",#012 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 17 09:08:18 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Nov 2014 09:08:18 -0000 Subject: [Varnish] #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 In-Reply-To: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> References: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> Message-ID: <061.4c451639ed96c3bf50479a86e4ccf446@varnish-cache.org> #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 ----------------------+------------------------------ Reporter: xieyugui | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP2 Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: Keywords: | ----------------------+------------------------------ Comment (by xieyugui): I have to fix the code according to the[ ticket-1607][https://www.varnish- cache.org/trac/ticket/1607], but still error -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 17 11:04:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Nov 2014 11:04:24 -0000 Subject: [Varnish] #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 In-Reply-To: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> References: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> Message-ID: <061.7762ae4bba8a4ddc6026abb517e8a7cd@varnish-cache.org> #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 ----------------------+------------------------------ Reporter: xieyugui | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP2 Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: Keywords: | ----------------------+------------------------------ Description changed by phk: Old description: > Nov 17 16:52:01 localhost /xxx/varnish/var/varnish/cache[17234]: Child > (17236) 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 0x424161: > HSH_Unbusy+0xf1#012 0x41ea46: vbf_stp_fetch+0x526#012 0x41f0db: > vbf_fetch_thread+0x20b#012 0x433ab7: Pool_Work_Thread+0x357#012 > 0x446719: wrk_thread_real+0xb9#012 0x7f8ec1abf9d1: > /lib64/libpthread.so.0(+0x79d1) [0x7f8ec1abf9d1]#012 busyobj = > 0x7f45f8e9b240 {#012 ws = 0x7f45f8e9b300 {#012 id = "bo",#012 > {s,f,r,e} = {0x7f45f8e9f868,+1856,(nil),+113112},#012 },#012 refcnt = > 2#012 retries = 0#012 failed = 0#012 state = 1#012 is_do_stream#012 > is_is_gunzip#012 is_should_close#012 bodystatus = 3 (length),#012 > },#012 http[bereq] = {#012 ws = 0x7f45f8e9b300[bo]#012 > "GET",#012 "/manhuatuku/3670/20131031161810322.jpg",#012 > "HTTP/1.1",#012 "X-Real-IP: 127.0.0.1",#012 "User-Agent: > Mozilla/5.0",#012 "Referer: > http://www.xxx.com/manhua/3670/240059.html?p=5",#012 "X-Forwarded- > For: 10.0.0.21, 127.0.0.1, 10.0.0.22, 10.0.0.22",#012 "Host: > cartoon.xxxx.cc",#012 "grace: none",#012 "Accept-Encoding: > gzip",#012 "X-Varnish: 233308163",#012 "connection: > close",#012 },#012 http[beresp] = {#012 ws = > 0x7f45f8e9b300[bo]#012 "HTTP/1.1",#012 "200",#012 > "OK",#012 "Cache-Control: max-age=31536000",#012 "Content- > Type: image/jpeg",#012 "Last-Modified: Thu, 31 Oct 2013 08:18:10 > GMT",#012 "Accept-Ranges: bytes",#012 "ETag: > "578437bc11d6ce1:0"",#012 "Server: Microsoft-IIS/7.5",#012 > "Date: Mon, 17 Nov 2014 08:48:40 GMT",#012 New description: {{{ v 17 16:52:01 localhost /xxx/varnish/var/varnish/cache[17234]: Child (17236) Panic message: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33: Condition((req->acct.req_hdrbytes) == 0) not true. thread = (cache-worker) ident = Linux,2.6.32-358.el6.x86_64,x86_64,-smalloc,-sfile,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x431015: pan_ic+0xc5 0x43960d: SES_ReleaseReq+0x27d 0x43a203: SES_ScheduleReq+0xa3 0x423e90: hsh_rush+0xa0 0x424161: HSH_Unbusy+0xf1 0x41ea46: vbf_stp_fetch+0x526 0x41f0db: vbf_fetch_thread+0x20b 0x433ab7: Pool_Work_Thread+0x357 0x446719: wrk_thread_real+0xb9 0x7f8ec1abf9d1: /lib64/libpthread.so.0(+0x79d1) [0x7f8ec1abf9d1] busyobj = 0x7f45f8e9b240 { ws = 0x7f45f8e9b300 { id = "bo", {s,f,r,e} = {0x7f45f8e9f868,+1856,(nil),+113112}, }, refcnt = 2 retries = 0 failed = 0 state = 1 is_do_stream is_is_gunzip is_should_close bodystatus = 3 (length), }, http[bereq] = { ws = 0x7f45f8e9b300[bo] "GET", "/manhuatuku/3670/20131031161810322.jpg", "HTTP/1.1", "X-Real-IP: 127.0.0.1", "User-Agent: Mozilla/5.0", "Referer: http://www.xxx.com/manhua/3670/240059.html?p=5", "X-Forwarded-For: 10.0.0.21, 127.0.0.1, 10.0.0.22, 10.0.0.22", "Host: cartoon.xxxx.cc", "grace: none", "Accept-Encoding: gzip", "X-Varnish: 233308163", "connection: close", }, http[beresp] = { ws = 0x7f45f8e9b300[bo] "HTTP/1.1", "200", "OK", "Cache-Control: max-age=31536000", "Content-Type: image/jpeg", "Last-Modified: Thu, 31 Oct 2013 08:18:10 GMT", "Accept-Ranges: bytes", "ETag: "578437bc11d6ce1:0"", "Server: Microsoft-IIS/7.5", "Date: Mon, 17 Nov 2014 08:48:40 GMT", }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 17 11:12:02 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Nov 2014 11:12:02 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.7f68b48bb209f669ea531a8831e1c58b@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Changes (by phk): * version: trunk => 4.0.2 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 17 11:16:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Nov 2014 11:16:27 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.a9ac71520212f46efa84c246be5b8249@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Changes (by phk): * version: 4.0.2 => trunk * milestone: Varnish 4.0 release => Later -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 17 11:19:47 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Nov 2014 11:19:47 -0000 Subject: [Varnish] #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 In-Reply-To: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> References: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> Message-ID: <061.ce52a0540028943b81d8007a513ac66b@varnish-cache.org> #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 ----------------------+------------------------------ Reporter: xieyugui | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP2 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+------------------------------ Changes (by fgsch): * version: 4.0.2 => trunk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 17 11:30:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Nov 2014 11:30:29 -0000 Subject: [Varnish] #1625: if(req.backend_hint == b1) compiles, but does nothing In-Reply-To: <049.31d68d5e448809c705a9e47a94fc94ce@varnish-cache.org> References: <049.31d68d5e448809c705a9e47a94fc94ce@varnish-cache.org> Message-ID: <064.44b0b6606137dd068089d76d8cff1745@varnish-cache.org> #1625: if(req.backend_hint == b1) compiles, but does nothing -------------------------+-------------------- Reporter: huguesalary | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by lkarsten): Comparing with req.backend_hint isn't the way to go. You should tag your object with beresp.backend.name in vcl_backend_response, and compare with that instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 17 12:04:51 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Nov 2014 12:04:51 -0000 Subject: [Varnish] #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 In-Reply-To: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> References: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> Message-ID: <061.a9551c4ab634b2c02054c7b736b9790b@varnish-cache.org> #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 ----------------------+------------------ Reporter: xieyugui | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+------------------ Changes (by martin): * version: trunk => * milestone: Varnish 4.0-TP2 => Comment: This is caused by 9fbcb4e94942a1bc7ff540f0a475b057a616b1ae not being backported (original fix for #1607 introduced a bug and that's what the reporter is seeing). Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 17 16:38:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Nov 2014 16:38:03 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.f769ef9ed96a7219e53a7b51fa11b7fd@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by fgsch): Potentially introduced in 969674dcb3b4d430a38b7f1b1e41199b25cc8491. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 17 19:09:18 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Nov 2014 19:09:18 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.e5d7813a8591d0f28bdd53f18bf478f7@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by franveux): It looks that the problem occurs when varnish is increasing the number of thread, while not been on a peak of request nor trafic. The following ugly code permits to avoid child crashes with no others troubles at this time: In cache/cache_busyobj.c just before line 171: {{{ if (bo == NULL) { // FVEMODIF avoid assert's child crash !!! syslog(LOG_NOTICE, "FVEMODIF: assert bo == null avoid crash..."); return; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 18 03:10:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 Nov 2014 03:10:53 -0000 Subject: [Varnish] #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 In-Reply-To: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> References: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> Message-ID: <061.27acc33ed7bc2b6eacbb23db31f75971@varnish-cache.org> #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 ----------------------+------------------ Reporter: xieyugui | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+------------------ Comment (by xieyugui): Replying to [comment:4 martin]: > This is caused by 9fbcb4e94942a1bc7ff540f0a475b057a616b1ae not being backported (original fix for #1607 introduced a bug and that's what the reporter is seeing). > > Martin You mean ,first I have to repair the #1607 , and then again repair it according 9fbcb4e94942a1bc7ff540f0a475b057a616b1ae? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 18 10:19:35 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 Nov 2014 10:19:35 -0000 Subject: [Varnish] #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 In-Reply-To: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> References: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> Message-ID: <061.6481b380235cf5c1e315c3678981cfc3@varnish-cache.org> #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 ----------------------+------------------ Reporter: xieyugui | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+------------------ Comment (by martin): Yes, fixing this issue means backporting both 9a2a221c713b7329231d7a1b9e996a4a41eedcf2 and 9fbcb4e94942a1bc7ff540f0a475b057a616b1ae Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 18 12:32:32 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 Nov 2014 12:32:32 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.ee2096fd2e6cbdd93a67a3725b6c37ac@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+----------------------------------------------- Reporter: Jay | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: needinfo => closed * resolution: => fixed Comment: In [7746e30e2c53cf55f0f2525bb3f49c9ee83e9611]: {{{ #!CommitTicketReference repository="" revision="7746e30e2c53cf55f0f2525bb3f49c9ee83e9611" Keep the fetch thread busyobj pointer-ref separate from the client thread pointer-ref, and deref it on thread scheduling failure. The code tried to deref the same pointer twice, which failed because the VBO_DerefBusyobj() will clear the pointer when called. Separating allows calling VBO_DerefBusyobj() for each of them. Fixes: #1628 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 18 19:26:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 Nov 2014 19:26:28 -0000 Subject: [Varnish] #1625: if(req.backend_hint == b1) compiles, but does nothing In-Reply-To: <049.31d68d5e448809c705a9e47a94fc94ce@varnish-cache.org> References: <049.31d68d5e448809c705a9e47a94fc94ce@varnish-cache.org> Message-ID: <064.4abca86fddb6469dda65f58a8a0ae17c@varnish-cache.org> #1625: if(req.backend_hint == b1) compiles, but does nothing -------------------------+-------------------- Reporter: huguesalary | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by fgsch): I think the issue here is more about semantics than anything else. req.backend_hints is type BACKEND. You assign a backend and read the backend name back. If you assign a backend via a director, however, you get the director's name back. This might not be a problem except that you cannot compare it against a director or specific backend within that director. The former will fail while the latter will never match. I think we need define how req.backend_hint should behave and make it consistent across all cases. Right now it seems to be consistent when assigning backends directly but not via directors. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 18 19:44:06 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 Nov 2014 19:44:06 -0000 Subject: [Varnish] #1630: Varnish crashes with long regex condition Message-ID: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> #1630: Varnish crashes with long regex condition -------------------------+---------------------- Reporter: huguesalary | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.2 | Severity: normal Keywords: | -------------------------+---------------------- I just upgraded to from 3 (.0.5/6) to 4.0.2 on my debian system. I converted my old varnish 3 code to 4.0.2. The varnish 3 code has been working flawlessly for more than 2 years. Now, in my varnish 4 VCL, everything works fine except for a very specific piece of code that crashes varnish. Some useful info: {{{ $ uname -a Linux proxy_newvarnish 3.13-1-amd64 #1 SMP Debian 3.13.10-1 (2014-04-15) x86_64 GNU/Linux $ varnishd -V varnishd (varnish-4.0.2 revision bfe7cd1) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2014 Varnish Software AS $ varnishd -a :80 \ -T localhost:6082 \ -f /etc/varnish/magento.vcl \ -S /etc/varnish/secret \ -p http_req_hdr_len=32768 \ -p thread_pools=8 \ -p thread_pool_min=100 \ -p thread_pool_max=2000 \ -p pcre_match_limit=1000000 \ -p pcre_match_limit_recursion=1000000 \ -p workspace_client=5M \ -p debug=+req_state,+workspace,+waiter,+waitinglist,+syncvsl,+hashedge,+vclrel,+lurker,+esi_chop -s memory=malloc,256m }}} Configuration to reproduce the bug: {{{ sub identify_device { if(!req.http.X-Device) # If req.http.X-Device is already set (by the browser for example), we don't overwrite it (useful for our recaching script) { # By default we consider our device as a desktop set req.http.X-Device = "desktop"; if ( (req.http.User-Agent ~ "\biPhone.*Mobile|\biPod") || (req.http.User-Agent ~ "BlackBerry|\bBB10\b|rim[0-9]+") || (req.http.User-Agent ~ "HTC|HTC.*(Sensation|Evo|Vision|Explorer|6800|8100|8900|A7272|S510e|C110e|Legend|Desire|T8282)|APX515CKT|Qtek9090|APA9292KT|HD_mini|Sensation.*Z710e|PG86100|Z715e|Desire.*(A8181|HD)|ADR6200|ADR6400L|ADR6425|001HT|Inspire 4G|Android.*\bEVO\b|T-Mobile G1|Z520m") || (req.http.User-Agent ~ "Nexus One|Nexus S|Galaxy.*Nexus|Android.*Nexus.*Mobile") || (req.http.User-Agent ~ "Dell.*Streak|Dell.*Aero|Dell.*Venue|DELL.*Venue Pro|Dell Flash|Dell Smoke|Dell Mini 3iX|XCD28|XCD35|\b001DL\b|\b101DL\b|\bGS01\b") || (req.http.User-Agent ~ "Motorola|\bDroid\b.*Build|DROIDX|Android.*Xoom|HRI39|MOT-|A1260|A1680|A555|A853|A855|A953|A955|A956|Motorola.*ELECTRIFY|Motorola.*i1|i867|i940|MB200|MB300|MB501|MB502|MB508|MB511|MB520|MB525|MB526|MB611|MB612|MB632|MB810|MB855|MB860|MB861|MB865|MB870|ME501|ME502|ME511|ME525|ME600|ME632|ME722|ME811|ME860|ME863|ME865|MT620|MT710|MT716|MT720|MT810|MT870|MT917|Motorola.*TITANIUM|WX435|WX445|XT300|XT301|XT311|XT316|XT317|XT319|XT320|XT390|XT502|XT530|XT531|XT532|XT535|XT603|XT610|XT611|XT615|XT681|XT701|XT702|XT711|XT720|XT800|XT806|XT860|XT862|XT875|XT882|XT883|XT894|XT901|XT907|XT909|XT910|XT912|XT928|XT926|XT915|XT919|XT925") || (req.http.User-Agent ~ "Samsung|SGH-I337|BGT-S5230|GT-B2100|GT-B2700|GT-B2710|GT-B3210|GT-B3310|GT-B3410|GT-B3730|GT-B3740|GT-B5510|GT-B5512|GT-B5722|GT-B6520|GT-B7300|GT-B7320|GT-B7330|GT-B7350|GT-B7510|GT-B7722|GT-B7800|GT-C3010|GT-C3011|GT-C3060|GT-C3200|GT-C3212 |GT-C3212I|GT-C3262|GT-C3222|GT-C3300|GT-C3300K|GT-C3303|GT- C3303K|GT-C3310|GT-C3322|GT-C3330|GT-C3350|GT-C3500|GT-C3510|GT-C3530|GT-C3630|GT-C3780|GT-C5010|GT-C5212|GT-C6620|GT-C6625|GT-C6712|GT-E1050|GT-E1070|GT-E1075|GT-E1080|GT-E1081|GT-E1085|GT-E1087|GT-E1100|GT-E1107|GT-E1110|GT-E1120|GT-E1125|GT-E1130|GT-E1160|GT-E1170|GT-E1175|GT-E1180|GT-E1182|GT-E1200|GT-E1210|GT-E1225|GT-E1230|GT-E1390|GT-E2100|GT-E2120|GT-E2121|GT-E2152|GT-E2220|GT-E2222|GT-E2230|GT-E2232|GT-E2250|GT-E2370|GT-E2550|GT-E2652|GT-E3210|GT-E3213|GT-I5500|GT-I5503|GT-I5700|GT-I5800|GT-I5801|GT-I6410|GT-I6420|GT-I7110|GT-I7410|GT-I7500|GT-I8000|GT-I8150|GT-I8160|GT-I8190|GT-I8320|GT-I8330|GT-I8350|GT-I8530|GT-I8700|GT-I8703|GT-I8910|GT-I9000|GT-I9001|GT-I9003|GT-I9010|GT-I9020|GT-I9023|GT-I9070|GT-I9082|GT-I9100|GT-I9103|GT-I9220|GT-I9250|GT-I9300|GT-I9305|GT-I9500|GT-I9505|GT-M3510|GT-M5650|GT-M7500|GT-M7600|GT-M7603|GT-M8800|GT-M8910|GT-N7000|GT-S3110|GT-S3310|GT-S3350|GT-S3353|GT-S3370|GT-S3650|GT-S3653|GT-S3770|GT-S3850|GT-S5210|GT-S5220|GT-S5229|GT-S5230|GT-S5233|GT-S5250|GT-S5253|GT-S5260|GT-S5263|GT-S5270|GT-S5300|GT-S5330|GT-S5350|GT-S5360|GT-S5363|GT-S5369|GT-S5380 |GT- S5380D|GT-S5560|GT-S5570|GT-S5600|GT-S5603|GT-S5610|GT-S5620|GT-S5660|GT-S5670|GT-S5690|GT-S5750|GT-S5780|GT-S5830|GT-S5839|GT-S6102|GT-S6500|GT-S7070|GT-S7200|GT-S7220|GT-S7230|GT-S7233|GT-S7250|GT-S7500|GT-S7530|GT-S7550|GT-S7562|GT-S7710|GT-S8000|GT-S8003|GT-S8500|GT-S8530|GT-S8600|SCH-A310|SCH-A530|SCH-A570|SCH-A610|SCH-A630|SCH-A650|SCH-A790|SCH-A795|SCH-A850|SCH-A870|SCH-A890|SCH-A930|SCH-A950|SCH-A970|SCH-A990|SCH-I100|SCH-I110|SCH-I400|SCH-I405|SCH-I500|SCH-I510|SCH-I515|SCH-I600|SCH-I730|SCH-I760|SCH-I770|SCH-I830|SCH-I910|SCH-I920|SCH-I959 |SCH- LC11|SCH-N150|SCH-N300|SCH-R100|SCH-R300|SCH-R351|SCH-R400|SCH-R410|SCH-T300|SCH-U310|SCH-U320|SCH-U350|SCH-U360|SCH-U365|SCH-U370|SCH-U380|SCH-U410|SCH-U430|SCH-U450|SCH-U460|SCH-U470|SCH-U490|SCH-U540|SCH-U550|SCH-U620|SCH-U640|SCH-U650|SCH-U660|SCH-U700|SCH-U740|SCH-U750|SCH-U810|SCH-U820|SCH-U900|SCH-U940|SCH-U960 |SCS- 26UC|SGH-A107|SGH-A117|SGH-A127|SGH-A137|SGH-A157|SGH-A167|SGH-A177|SGH-A187|SGH-A197|SGH-A227|SGH-A237|SGH-A257|SGH-A437|SGH-A517|SGH-A597|SGH-A637|SGH-A657|SGH-A667|SGH-A687|SGH-A697|SGH-A707|SGH-A717|SGH-A727|SGH-A737|SGH-A747|SGH-A767|SGH-A777|SGH-A797|SGH-A817|SGH-A827|SGH-A837|SGH-A847|SGH-A867|SGH-A877|SGH-A887|SGH-A897|SGH-A927|SGH-B100|SGH-B130|SGH-B200|SGH-B220|SGH-C100|SGH-C110|SGH-C120|SGH-C130|SGH-C140|SGH-C160|SGH-C170|SGH-C180|SGH-C200|SGH-C207|SGH-C210|SGH-C225|SGH-C230|SGH-C417|SGH-C450|SGH-D307|SGH-D347|SGH-D357|SGH-D407|SGH-D415|SGH-D780|SGH-D807|SGH-D980|SGH-E105|SGH-E200|SGH-E315|SGH-E316|SGH-E317|SGH-E335|SGH-E590|SGH-E635|SGH-E715|SGH-E890|SGH-F300|SGH-F480|SGH-I200|SGH-I300|SGH-I320|SGH-I550|SGH-I577|SGH-I600|SGH-I607|SGH-I617|SGH-I627|SGH-I637|SGH-I677|SGH-I700|SGH-I717|SGH-I727 |SGH- i747M|SGH-I777|SGH-I780|SGH-I827|SGH-I847|SGH-I857|SGH-I896|SGH-I897|SGH-I900|SGH-I907|SGH-I917|SGH-I927|SGH-I937|SGH-I997|SGH-J150|SGH-J200|SGH-L170|SGH-L700|SGH-M110|SGH-M150|SGH-M200|SGH-N105|SGH-N500|SGH-N600|SGH-N620|SGH-N625|SGH-N700|SGH-N710|SGH-P107|SGH-P207|SGH-P300|SGH-P310|SGH-P520|SGH-P735|SGH-P777|SGH-Q105|SGH-R210|SGH-R220|SGH-R225|SGH-S105|SGH-S307|SGH-T109|SGH-T119|SGH-T139|SGH-T209|SGH-T219|SGH-T229|SGH-T239|SGH-T249|SGH-T259|SGH-T309|SGH-T319|SGH-T329|SGH-T339|SGH-T349|SGH-T359|SGH-T369|SGH-T379|SGH-T409|SGH-T429|SGH-T439|SGH-T459|SGH-T469|SGH-T479|SGH-T499|SGH-T509|SGH-T519|SGH-T539|SGH-T559|SGH-T589|SGH-T609|SGH-T619|SGH-T629|SGH-T639|SGH-T659|SGH-T669|SGH-T679|SGH-T709|SGH-T719|SGH-T729|SGH-T739|SGH-T746|SGH-T749|SGH-T759|SGH-T769|SGH-T809|SGH-T819|SGH-T839|SGH-T919|SGH-T929|SGH-T939|SGH-T959|SGH-T989|SGH-U100|SGH-U200|SGH-U800|SGH-V205|SGH-V206|SGH-X100|SGH-X105|SGH-X120|SGH-X140|SGH-X426|SGH-X427|SGH-X475|SGH-X495|SGH-X497|SGH-X507|SGH-X600|SGH-X610|SGH-X620|SGH-X630|SGH-X700|SGH-X820|SGH-X890|SGH-Z130|SGH-Z150|SGH-Z170 |SGH-ZX10|SGH- ZX20|SHW-M110|SPH-A120|SPH-A400|SPH-A420|SPH-A460|SPH-A500|SPH-A560|SPH-A600|SPH-A620|SPH-A660|SPH-A700|SPH-A740|SPH-A760|SPH-A790|SPH-A800|SPH-A820|SPH-A840|SPH-A880|SPH-A900|SPH-A940|SPH-A960|SPH-D600|SPH-D700|SPH-D710|SPH-D720|SPH-I300|SPH-I325|SPH-I330|SPH-I350|SPH-I500|SPH-I600|SPH-I700|SPH-L700|SPH-M100|SPH-M220|SPH-M240|SPH-M300|SPH-M305|SPH-M320|SPH-M330|SPH-M350|SPH-M360|SPH-M370|SPH-M380|SPH-M510|SPH-M540|SPH-M550|SPH-M560|SPH-M570|SPH-M580|SPH-M610|SPH-M620|SPH-M630|SPH-M800|SPH-M810|SPH-M850|SPH-M900|SPH-M910|SPH-M920|SPH-M930|SPH-N100|SPH-N200|SPH-N240|SPH-N300|SPH-N400|SPH-Z400|SWC-E100|SCH-i909|GT-N7100|GT-N7105|SCH-I535 |SM-N900A|SGH-I317|SGH-T999L|GT-S5360B") || (req.http.User-Agent ~ "\bLG\b;|LG[- ]?(C800|C900|E400|E610|E900|E-900|F160|F180K|F180L|F180S|730|855|L160|LS840|LS970|LU6200|MS690|MS695|MS770|MS840|MS870|MS910|P500|P700|P705|VM696|AS680|AS695|AX840|C729|E970|GS505|272|C395|E739BK|E960|L55C|L75C|LS696|LS860|P769BK|P350|P500|P509|P870|UN272|US730|VS840|VS950|LN272|LN510|LS670|LS855|LW690|MN270|MN510|P509|P769|P930|UN200|UN270|UN510|UN610|US670|US740|US760|UX265|UX840|VN271|VN530|VS660|VS700|VS740|VS750|VS910|VS920|VS930|VX9200|VX11000|AX840A|LW770|P506|P925|P999)") || (req.http.User-Agent ~ "SonyST|SonyLT|SonyEricsson|SonyEricssonLT15iv|LT18i|E10i|LT28h|LT26w|SonyEricssonMT27i") || (req.http.User-Agent ~ "Asus.*Galaxy|PadFone.*Mobile") || (req.http.User-Agent ~ "Micromax.*\b(A210|A92|A88|A72|A111|A110Q|A115|A116|A110|A90S|A26|A51|A35|A54|A25|A27|A89|A68|A65|A57|A90)\b") || (req.http.User-Agent ~ "PalmSource|Palm") || (req.http.User-Agent ~ "Vertu|Vertu.*Ltd|Vertu.*Ascent|Vertu.*Ayxta|Vertu.*Constellation(F|Quest)?|Vertu.*Monika|Vertu.*Signature") || (req.http.User-Agent ~ "PANTECH|IM-A850S|IM-A840S|IM- A830L|IM-A830K|IM-A830S|IM-A820L|IM-A810K|IM-A810S|IM-A800S|IM-T100K|IM- A725L|IM-A780L|IM-A775C|IM-A770K|IM-A760S|IM-A750K|IM-A740S|IM-A730S|IM- A720L|IM-A710K|IM-A690L|IM-A690S|IM-A650S|IM-A630K|IM-A600S|VEGA PTL21|PT003|P8010|ADR910L|P6030|P6020|P9070|P4100|P9060|P5000|CDM8992|TXT8045|ADR8995|IS11PT|P2030|P6010|P8000|PT002|IS06|CDM8999|P9050|PT001|TXT8040|P2020|P9020|P2000|P7040|P7000|C790") || (req.http.User-Agent ~ "IQ230|IQ444|IQ450|IQ440|IQ442|IQ441|IQ245|IQ256|IQ236|IQ255|IQ235|IQ245|IQ275|IQ240|IQ285|IQ280|IQ270|IQ260|IQ250") || (req.http.User-Agent ~ "\b(SP-80|XT-930|SX-340|XT-930|SX-310|SP-360|SP60|SPT-800|SP-120|SPT-800|SP-140|SPX-5|SPX-8|SP-100|SPX-8|SPX-12)\b") || (req.http.User-Agent ~ "Tapatalk|PDA;|SAGEM|\bmmp\b|pocket|\bpsp\b|symbian|Smartphone|smartfon|treo|up.browser|up.link|vodafone|\bwap\b|nokia|Series40|Series60|S60|SonyEricsson|N900|MAUI.*WAP.*Browser")) { set req.http.X-Device = "mobile"; } elsif ( (req.http.User-Agent ~ "\bCrMo\b|CriOS|Android.*Chrome/[.0-9]* (Mobile)?") || (req.http.User-Agent ~ "\bDolfin\b") || (req.http.User-Agent ~ "Opera.*Mini|Opera.*Mobi|Android.*Opera|Mobile.*OPR/[0-9.]+|Coast/[0-9.]+") || (req.http.User-Agent ~ "Skyfire") || (req.http.User-Agent ~ "IEMobile|MSIEMobile") || (req.http.User-Agent ~ "fennec|firefox.*maemo|(Mobile|Tablet).*Firefox|Firefox.*Mobile") || (req.http.User-Agent ~ "bolt") || (req.http.User-Agent ~ "teashark") || (req.http.User-Agent ~ "Blazer") || (req.http.User-Agent ~ "Version.*Mobile.*Safari|Safari.*Mobile") || (req.http.User-Agent ~ "Tizen") || (req.http.User-Agent ~ "UC.*Browser|UCWEB") || (req.http.User-Agent ~ "DiigoBrowser") || (req.http.User-Agent ~ "Puffin") || (req.http.User-Agent ~ "\bMercury\b") || (req.http.User-Agent ~ "NokiaBrowser|OviBrowser|OneBrowser|TwonkyBeamBrowser|SEMC.*Browser|FlyFlow|Minimo|NetFront |Novarra-Vision|MQQBrowser|MicroMessenger")) { set req.http.X-Device = "mobile"; } elsif ( (req.http.User-Agent ~ "Android") || (req.http.User-Agent ~ "blackberry|\bBB10\b|rim tablet os") || (req.http.User-Agent ~ "PalmOS|avantgo|blazer|elaine|hiptop|palm|plucker|xiino") || (req.http.User-Agent ~ "Symbian|SymbOS|Series60|Series40|SYB-[0-9]+|\bS60\b") || (req.http.User-Agent ~ "Windows CE.*(PPC|Smartphone|Mobile|[0-9]{3}x[0-9]{3})|Window Mobile|Windows Phone [0-9.]+|WCE;") || (req.http.User-Agent ~ "Windows Phone 8.0|Windows Phone OS|XBLWP7|ZuneWP7") || (req.http.User-Agent ~ "\biPhone.*Mobile|\biPod|\biPad") || (req.http.User-Agent ~ "MeeGo") || (req.http.User-Agent ~ "Maemo") || (req.http.User-Agent ~ "J2ME/|\bMIDP\b|\bCLDC\b") || (req.http.User-Agent ~ "webOS|hpwOS") || (req.http.User-Agent ~ "\bBada\b") || (req.http.User-Agent ~ "BREW")) { set req.http.X-Device = "mobile"; } elsif ( (req.http.User-Agent ~ "iPad|iPad.*Mobile") || (req.http.User-Agent ~ "^.*Android.*Nexus(((?:(?!Mobile))|(?:(\s(7|10).+))).)*$") || (req.http.User-Agent ~ "SAMSUNG.*Tablet|Galaxy.*Tab|SC- 01C|GT-P1000|GT-P1003|GT-P1010|GT-P3105|GT-P6210|GT-P6800|GT-P6810|GT-P7100|GT-P7300|GT-P7310|GT-P7500|GT-P7510|SCH-I800|SCH-I815|SCH-I905|SGH-I957|SGH-I987|SGH-T849|SGH-T859|SGH-T869|SPH-P100|GT-P3100|GT-P3108|GT-P3110|GT-P5100|GT-P5110|GT-P6200|GT-P7320|GT-P7511|GT-N8000|GT-P8510|SGH-I497|SPH-P500|SGH-T779|SCH-I705|SCH-I915|GT-N8013|GT-P3113|GT-P5113|GT-P8110|GT-N8010|GT-N8005|GT-N8020|GT-P1013|GT-P6201|GT-P7501|GT-N5100|GT-N5110 |SHV-E140K|SHV-E140L|SHV-E140S|SHV-E150S|SHV-E230K|SHV-E230L|SHV-E230S |SHW-M180K|SHW-M180L|SHW-M180S|SHW-M180W|SHW-M300W|SHW-M305W|SHW-M380K |SHW-M380S|SHW-M380W|SHW-M430W|SHW-M480K|SHW-M480S|SHW-M480W|SHW-M485W |SHW-M486W|SHW- M500W|GT-I9228|SCH-P739|SCH-I925|GT-I9200|GT-I9205|GT-P5200|GT-P5210|SM-T311|SM-T310|SM-T210 |SM-T210R|SM-T211|SM-P600|SM-P601|SM-P605|SM-P900|SM-T217|SM-T217A|SM- T217S|SM-P6000|SM-T3100|SGH-I467|XE500") || (req.http.User-Agent ~ "Kindle|Silk.*Accelerated|Android.*\b(KFOT|KFTT|KFJWI|KFJWA|KFOTE|KFSOWI|KFTHWI|KFTHWA|KFAPWI|KFAPWA|WFJWAE)\b") || (req.http.User-Agent ~ "Windows NT [0-9.]+; ARM;") || (req.http.User-Agent ~ "HP Slate 7|HP ElitePad 900|hp- tablet|EliteBook.*Touch") || (req.http.User-Agent ~ "^.*PadFone((?!Mobile).)*$|Transformer|TF101|TF101G|TF300T|TF300TG|TF300TL|TF700T|TF700KL|TF701T|TF810C|ME171|ME301T|ME302C|ME371MG|ME370T|ME372MG|ME172V|ME173X|ME400C|Slider SL101|\bK00F\b|TX201LA") || (req.http.User-Agent ~ "PlayBook|RIM Tablet") || (req.http.User-Agent ~ "HTC Flyer|HTC Jetstream|HTC- P715a|HTC EVO View 4G|PG41200") || (req.http.User-Agent ~ "xoom|sholest|MZ615|MZ605|MZ505|MZ601|MZ602|MZ603|MZ604|MZ606|MZ607|MZ608|MZ609|MZ615|MZ616|MZ617") || (req.http.User-Agent ~ "Android.*Nook|NookColor|nook browser|BNRV200|BNRV200A|BNTV250|BNTV250A|BNTV400|BNTV600|LogicPD Zoom2") || (req.http.User-Agent ~ "Android.*; \b(A100|A101|A110|A200|A210|A211|A500|A501|A510|A511|A700|A701|W500|W500P|W501|W501P|W510|W511|W700|G100|G100W|B1-A71|B1-710|B1-711|A1-810)\b|W3-810") || (req.http.User-Agent ~ "Android.*(AT100|AT105|AT200|AT205|AT270|AT275|AT300|AT305|AT1S5|AT500|AT570|AT700|AT830)|TOSHIBA.*FOLIO") || (req.http.User-Agent ~ "\bL-06C|LG-V900|LG-V909\b") || (req.http.User-Agent ~ "Android.*\b(F-01D|F-05E|F-10D|M532|Q572)\b") || (req.http.User-Agent ~ "PMP3170B|PMP3270B|PMP3470B|PMP7170B|PMP3370B|PMP3570C|PMP5870C|PMP3670B|PMP5570C|PMP5770D|PMP3970B|PMP3870C|PMP5580C|PMP5880D|PMP5780D|PMP5588C|PMP7280C|PMP7280|PMP7880D|PMP5597D|PMP5597|PMP7100D|PER3464|PER3274|PER3574|PER3884|PER5274|PER5474|PMP5097CPRO|PMP5097|PMP7380D|PMP5297C|PMP5297C_QUAD") || (req.http.User-Agent ~ "IdeaTab|S2110|S6000|K3011|A3000|A1000|A2107|A2109|A1107|ThinkPad([ ]+)?Tablet") || (req.http.User-Agent ~ "Android.*\b(TAB210|TAB211|TAB224|TAB250|TAB260|TAB264|TAB310|TAB360|TAB364|TAB410|TAB411|TAB420|TAB424|TAB450|TAB460|TAB461|TAB464|TAB465|TAB467|TAB468|TAB07-100|TAB07-101|TAB07-150|TAB07-151|TAB07-152|TAB07-200|TAB07-201-3G|TAB07-210|TAB07-211|TAB07-212|TAB07-214|TAB07-220|TAB07-400|TAB07-485|TAB08-150|TAB08-200|TAB08-201-3G|TAB09-100|TAB09-211|TAB09-410|TAB10-150|TAB10-201|TAB10-211|TAB10-400|TAB10-410|TAB13-201|TAB274EUK|TAB275EUK|TAB374EUK|TAB462EUK|TAB474EUK|TAB9-200)\b") || (req.http.User-Agent ~ "Android.*\bOYO\b|LIFE.*(P9212|P9514|P9516|S9512)|LIFETAB") || (req.http.User-Agent ~ "AN10G2|AN7bG3|AN7fG3|AN8G3|AN8cG3|AN7G3|AN9G3|AN7dG3|AN7dG3ST|AN7dG3ChildPad|AN10bG3|AN10bG3DT") || (req.http.User-Agent ~ "M702pro") || (req.http.User-Agent ~ "MegaFon V9|\bZTE V9\b|Android.*\bMT7A\b") || (req.http.User-Agent ~ "E-Boda (Supreme|Impresspeed|Izzycomm|Essential)") || (req.http.User-Agent ~ "Allview.*(Viva|Alldro|City|Speed|All TV|Frenzy|Quasar|Shine|TX1|AX1|AX2)") || (req.http.User-Agent ~ "\b(101G9|80G9|A101IT)\b|Qilive 97R|ARCHOS 101G10") || (req.http.User-Agent ~ "NOVO7|NOVO8|NOVO10|Novo7Aurora|Novo7Basic|NOVO7PALADIN|novo9-Spark") || (req.http.User-Agent ~ "Sony.*Tablet|Xperia Tablet|Sony Tablet S|SO- 03E|SGPT12|SGPT13|SGPT114|SGPT121|SGPT122|SGPT123|SGPT111|SGPT112|SGPT113|SGPT131|SGPT132|SGPT133|SGPT211|SGPT212|SGPT213|SGP311|SGP312|SGP321|EBRD1101|EBRD1102|EBRD1201") || (req.http.User-Agent ~ "Android.*(K8GT|U9GT|U10GT|U16GT|U17GT|U18GT|U19GT|U20GT|U23GT|U30GT)|CUBE U8GT") || (req.http.User-Agent ~ "MID1042|MID1045|MID1125|MID1126|MID7012|MID7014|MID7015|MID7034|MID7035|MID7036|MID7042|MID7048|MID7127|MID8042|MID8048|MID8127|MID9042|MID9740|MID9742|MID7022|MID7010") || (req.http.User-Agent ~ "M9701|M9000|M9100|M806|M1052|M806|T703|MID701|MID713|MID710|MID727|MID760|MID830|MID728|MID933|MID125|MID810|MID732|MID120|MID930|MID800|MID731|MID900|MID100|MID820|MID735|MID980|MID130|MID833|MID737|MID960|MID135|MID860|MID736|MID140|MID930|MID835|MID733") || (req.http.User-Agent ~ "Android.*(\bMID\b|MID-560|MTV-T1200|MTV-PND531|MTV-P1101|MTV-PND530)") || (req.http.User-Agent ~ "Android.*(RK2818|RK2808A|RK2918|RK3066)|RK2738|RK2808A") || (req.http.User-Agent ~ "IQ310|Fly Vision") || (req.http.User-Agent ~ "bq.*(Elcano|Curie|Edison|Maxwell|Kepler|Pascal|Tesla|Hypatia|Platon|Newton|Livingstone|Cervantes|Avant)|Maxwell.*Lite|Maxwell.*Plus") || (req.http.User-Agent ~ "MediaPad|IDEOS S7|S7-201c|S7-202u|S7-101|S7-103|S7-104|S7-105|S7-106|S7-201|S7-Slim") || (req.http.User-Agent ~ "\bN-06D|\bN-08D") || (req.http.User-Agent ~ "Pantech.*P4100") || (req.http.User-Agent ~ "Broncho.*(N701|N708|N802|a710)") || (req.http.User-Agent ~ "TOUCHPAD.*[78910]|\bTOUCHTAB\b") || (req.http.User-Agent ~ "z1000|Z99 2G|z99|z930|z999|z990|z909|Z919|z900") || (req.http.User-Agent ~ "TB07STA|TB10STA|TB07FTA|TB10FTA") || (req.http.User-Agent ~ "Android.*\bNabi") || (req.http.User-Agent ~ "Kobo Touch|\bK080\b|\bVox\b Build|\bArc\b Build") || (req.http.User-Agent ~ "DSlide.*\b(700|701R|702|703R|704|802|970|971|972|973|974|1010|1012)\b") || (req.http.User-Agent ~ "NaviPad|TB- 772A|TM-7045|TM-7055|TM-9750|TM-7016|TM-7024|TM-7026|TM-7041|TM-7043|TM-7047|TM-8041|TM-9741|TM-9747|TM-9748|TM-9751|TM-7022|TM-7021|TM-7020|TM-7011|TM-7010|TM-7023|TM-7025 |TM-7037W|TM-7038W|TM-7027W|TM-9720|TM-9725|TM-9737W|TM-1020|TM- 9738W|TM-9740|TM-9743W|TB-807A|TB-771A|TB-727A|TB-725A|TB-719A|TB-823A|TB- 805A|TB-723A|TB-715A|TB-707A|TB-705A|TB-709A|TB-711A|TB-890HD|TB-880HD|TB- 790HD|TB-780HD|TB-770HD|TB-721HD|TB-710HD|TB-434HD|TB-860HD|TB-840HD|TB- 760HD|TB-750HD|TB-740HD|TB-730HD|TB-722HD|TB-720HD|TB-700HD|TB-500HD|TB- 470HD|TB-431HD|TB-430HD|TB-506|TB-504|TB-446|TB-436|TB-416|TB-146SE|TB- 126SE") || (req.http.User-Agent ~ "Playstation.*(Portable|Vita)") || (req.http.User-Agent ~ "ST10416-1|VT10416-1|ST70408-1|ST702xx-1|ST702xx-2|ST80208|ST97216|ST70104-2") || (req.http.User-Agent ~ "\b(PTBL10CEU|PTBL10C|PTBL72BC|PTBL72BCEU|PTBL7CEU|PTBL7C|PTBL92BC|PTBL92BCEU|PTBL9CEU|PTBL9CUK|PTBL9C)\b") || (req.http.User-Agent ~ "Android.* \b(S5G|S5K|T5B|T3E|T3C|T3B|T1J|T1F|S5D|T2A|T1H|E1C|T1i|S5E|T1-E|S5F|E1-B|T2Ci|T1-B|T1-D|T5-A|O1-A|E1-A|T1-A|T3A|S5|T4i)\b ") || (req.http.User-Agent ~ "Genius Tab G3|Genius Tab S2|Genius Tab Q3|Genius Tab G4|Genius Tab Q4|Genius Tab G-II|Genius TAB GII|Genius TAB GIII|Genius Tab S1") || (req.http.User-Agent ~ "Android.*\bG1\b") || (req.http.User-Agent ~ "Funbook|Micromax.*\b(P250|P560|P360|P362|P600|P300|P350|P500|P275)\b") || (req.http.User-Agent ~ "Android.*\b(A39|A37|A34|ST8|ST10|ST7|Smart Tab3|Smart Tab2)\b") || (req.http.User-Agent ~ "Fine7 Genius|Fine7 Shine|Fine7 Air|Fine8 Style|Fine9 More|Fine10 Joy|Fine11 Wide") || (req.http.User-Agent ~ "\b(PEM63|PLT1023G|PLT1041|PLT1044|PLT1044G|PLT1091|PLT4311|PLT4311PL|PLT4315|PLT7030|PLT7033|PLT7033D|PLT7035|PLT7035D|PLT7044K|PLT7045K|PLT7045KB|PLT7071KG|PLT7072|PLT7223G|PLT7225G|PLT7777G|PLT7810K|PLT7849G|PLT7851G|PLT7852G|PLT8015|PLT8031|PLT8034|PLT8036|PLT8080K|PLT8082|PLT8088|PLT8223G|PLT8234G|PLT8235G|PLT8816K|PLT9011|PLT9045K|PLT9233G|PLT9735|PLT9760G|PLT9770G)\b") || (req.http.User-Agent ~ "BQ1078|BC1003|BC1077|RK9702|BC9730|BC9001|IT9001|BC7008|BC7010|BC708|BC728|BC7012|BC7030|BC7027|BC7026") || (req.http.User-Agent ~ "TPC7102|TPC7103|TPC7105|TPC7106|TPC7107|TPC7201|TPC7203|TPC7205|TPC7210|TPC7708|TPC7709|TPC7712|TPC7110|TPC8101|TPC8103|TPC8105|TPC8106|TPC8203|TPC8205|TPC8503|TPC9106|TPC9701|TPC97101|TPC97103|TPC97105|TPC97106|TPC97111|TPC97113|TPC97203|TPC97603|TPC97809|TPC97205|TPC10101|TPC10103|TPC10106|TPC10111|TPC10203|TPC10205|TPC10503") || (req.http.User-Agent ~ "TX-A1301|TX-M9002|Q702|kf026") || (req.http.User-Agent ~ "TAB-P506|TAB- navi-7-3G-M|TAB-P517|TAB-P-527|TAB-P701|TAB-P703|TAB-P721|TAB- P731N|TAB-P741|TAB-P825|TAB-P905|TAB-P925|TAB-PR945|TAB-PL1015|TAB-P1025 |TAB-PI1045|TAB-P1325|TAB-PROTAB[0-9]+|TAB-PROTAB25|TAB-PROTAB26|TAB- PROTAB27|TAB-PROTAB26XL|TAB-PROTAB2-IPS9|TAB-PROTAB30-IPS9|TAB-PROTAB25XXL |TAB-PROTAB26-IPS10|TAB-PROTAB30-IPS10") || (req.http.User-Agent ~ "OV-(SteelCore|NewBase|Basecore|Baseone|Exellen|Quattor|EduTab|Solution|ACTION|BasicTab|TeddyTab|MagicTab|Stream|TB-08|TB-09)") || (req.http.User-Agent ~ "HCL.*Tablet|Connect-3G-2.0 |Connect-2G-2.0|ME Tablet U1|ME Tablet U2|ME Tablet G1|ME Tablet X1|ME Tablet Y2|ME Tablet Sync") || (req.http.User-Agent ~ "DPS Dream 9|DPS Dual 7") || (req.http.User-Agent ~ "V97 HD|i75 3G|Visture V4( HD)?|Visture V5( HD)?|Visture V10") || (req.http.User-Agent ~ "CTP(-)?810|CTP(-)?818|CTP(-)?828|CTP(-)?838|CTP(-)?888|CTP(-)?978|CTP(-)?980|CTP(-)?987|CTP(-)?988|CTP(-)?989") || (req.http.User-Agent ~ "\bMT8125|MT8389|MT8135|MT8377\b") || (req.http.User-Agent ~ "Concorde([ ]+)?Tab|ConCorde ReadMan") || (req.http.User-Agent ~ "GOCLEVER TAB|A7GOCLEVER|M1042|M7841|M742|R1042BK|R1041|TAB A975|TAB A7842|TAB A741|TAB A741L|TAB M723G|TAB M721|TAB A1021|TAB I921|TAB R721|TAB I720|TAB T76|TAB R70|TAB R76.2|TAB R106|TAB R83.2|TAB M813G|TAB I721|GCTA722|TAB I70|TAB I71|TAB S73|TAB R73|TAB R74|TAB R93|TAB R75|TAB R76.1|TAB A73|TAB A93|TAB A93.2|TAB T72|TAB R83|TAB R974|TAB R973|TAB A101|TAB A103|TAB A104|TAB A104.2|R105BK|M713G|A972BK|TAB A971|TAB R974.2|TAB R104|TAB R83.3|TAB A1042") || (req.http.User-Agent ~ "FreeTAB 9000|FreeTAB 7.4|FreeTAB 7004|FreeTAB 7800|FreeTAB 2096|FreeTAB 7.5|FreeTAB 1014|FreeTAB 1001 |FreeTAB 8001|FreeTAB 9706|FreeTAB 9702|FreeTAB 7003|FreeTAB 7002|FreeTAB 1002|FreeTAB 7801|FreeTAB 1331|FreeTAB 1004|FreeTAB 8002|FreeTAB 8014|FreeTAB 9704|FreeTAB 1003") || (req.http.User-Agent ~ "Hudl HT7S3") || (req.http.User-Agent ~ "T-Hub2") || (req.http.User-Agent ~ "Android.*\b97D\b|Tablet(?!.*PC)|ViewPad7|BNTV250A|MID-WCDMA|LogicPD Zoom2|\bA7EB\b|CatNova8|A1_07|CT704|CT1002|\bM721\b|rk30sdk|\bEVOTAB\b|SmartTabII10|SmartTab10|M758A|ET904")) { set req.http.X-Device = "mobile;tablet"; } } } vcl_recv { call identify_device; } }}} One-liner triggering the bug: {{{ curl http://yourhost/ --header "User-Agent: Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 4 Build/JOP40D) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19" }}} dmesg output on my machines: {{{ [ 5930.438102] varnishd[21356]: segfault at 7ff2c9cb6ee0 ip 00007ff2e55e97ed sp 00007ff2c9cb6ea0 error 6 in libpcre.so.3.13.1[7ff2e55d6000+3c000] [ 5937.141468] varnishd[22171]: segfault at 7ff2c9dbeee0 ip 00007ff2e55e97ed sp 00007ff2c9dbeea0 error 6 in libpcre.so.3.13.1[7ff2e55d6000+3c000] [ 5938.550985] varnishd[23054]: segfault at 7ff2c6bcfee0 ip 00007ff2e55e97ed sp 00007ff2c6bcfea0 error 6 in libpcre.so.3.13.1[7ff2e55d6000+3c000] [ 5957.939599] varnishd[23943]: segfault at 7ff2c830fee0 ip 00007ff2e55e97ed sp 00007ff2c830fea0 error 6 in libpcre.so.3.13.1[7ff2e55d6000+3c000] [ 5960.249944] varnishd[24757]: segfault at 7ff2c9477ff8 ip 00007ff2e55e97d6 sp 00007ff2c9478000 error 6 in libpcre.so.3.13.1[7ff2e55d6000+3c000] [ 6703.908736] varnishd[25667]: segfault at 7ff2c6a97ff8 ip 00007ff2e55e97d6 sp 00007ff2c6a98000 error 6 in libpcre.so.3.13.1[7ff2e55d6000+3c000] [ 6734.907388] varnishd[27194]: segfault at 7ff2c92acff8 ip 00007ff2e55e97d6 sp 00007ff2c92ad000 error 6 in libpcre.so.3.13.1[7ff2e55d6000+3c000] }}} Varnishlog output: {{{ hugues at proxy_newvarnish:~$ varnishlog * << Session >> 1 - Begin sess 0 HTTP/1 - SessOpen 172.17.42.1 57981 :80 172.17.0.8 80 1416016309.424483 13 - Link req 2 rxreq - VSL flush - End synth * << Request >> 2 - Begin req 1 rxreq - Timestamp Start: 1416016309.424564 0.000000 0.000000 - Timestamp Req: 1416016309.424564 0.000000 0.000000 - Debug "vxid 1073741826 STP_RECV sp 0x7fd37080f1a0 obj (nil) vcl 0x7fd391011128" - ReqStart 172.17.42.1 57981 - ReqMethod GET - ReqURL / - ReqProtocol HTTP/1.1 - ReqHeader Host: www.newvarnish.betabrand.io - ReqHeader Accept: */* - ReqHeader User-Agent: Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 4 Build/JOP40D) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19 - ReqHeader X-Forwarded-For: 98.210.153.225 - ReqUnset X-Forwarded-For: 98.210.153.225 - ReqHeader X-Forwarded-For: 98.210.153.225, 172.17.42.1 - VCL_call RECV - ReqURL / - ReqUnset X-Forwarded-For: 98.210.153.225, 172.17.42.1 - ReqHeader X-Forwarded-For: 98.210.153.225, 172.17.42.1, 172.17.42.1 - ReqHeader X-PSA-Blocking-Rewrite: betabrand-pagespeed - ReqHeader X-Device: desktop - ReqUnset X-Device: desktop - ReqHeader X-Device: mobile - VSL flush - End synth Log abandoned Log reacquired }}} And all this info in a gist: https://gist.github.com/huguesalary/fc59034d3a49745755f4 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 18 22:12:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 Nov 2014 22:12:43 -0000 Subject: [Varnish] #1630: Varnish crashes with long regex condition In-Reply-To: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> References: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> Message-ID: <064.34171bc313ae5e316f88946ba899da9b@varnish-cache.org> #1630: Varnish crashes with long regex condition -------------------------+-------------------- Reporter: huguesalary | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by fgsch): Likely related to #1576. Try increasing thread_pool_stack to see if the problem goes away. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 18 23:30:35 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 Nov 2014 23:30:35 -0000 Subject: [Varnish] #1630: Varnish crashes with long regex condition In-Reply-To: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> References: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> Message-ID: <064.6edaa45c2df26952e575028152ffb5f5@varnish-cache.org> #1630: Varnish crashes with long regex condition -------------------------+-------------------- Reporter: huguesalary | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by huguesalary): increasing thread_pool_stack did the trick. Is there any sensible value this should be set? Is there any magic formula to determine the best value? I currently have it set to 196k. Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 19 02:01:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 Nov 2014 02:01:12 -0000 Subject: [Varnish] #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 In-Reply-To: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> References: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> Message-ID: <061.6b100b970bb6cbf25e72baf3726c3079@varnish-cache.org> #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 ----------------------+------------------ Reporter: xieyugui | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+------------------ Comment (by xieyugui): Replying to [comment:6 martin]: > Yes, fixing this issue means backporting both 9a2a221c713b7329231d7a1b9e996a4a41eedcf2 and 9fbcb4e94942a1bc7ff540f0a475b057a616b1ae > > Martin Thank you, after repair, hoping to stable operation in a production environment -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 19 14:45:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 Nov 2014 14:45:27 -0000 Subject: [Varnish] #1631: timeout and 503 Message-ID: <050.d9fdf1912c75a15bfd3724162e2f0221@varnish-cache.org> #1631: timeout and 503 --------------------------+------------------------- Reporter: lorenzololli | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | --------------------------+------------------------- Greetings, when I get a timeout or a tcp reset with varnish, it ends up showing a 503 error. Is it possible to choose a custom error level for: timeout from varnish and clients timeout from varnish and backends tcp reset ? Best regards, Lorenzo Lolli -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 19 19:09:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 Nov 2014 19:09:25 -0000 Subject: [Varnish] #1630: Varnish crashes with long regex condition In-Reply-To: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> References: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> Message-ID: <064.933a799007eadb3f3b5fb5bfa27f5cec@varnish-cache.org> #1630: Varnish crashes with long regex condition -------------------------+-------------------- Reporter: huguesalary | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by huguesalary): So, increasing the thread_pool_stack worked, but it seems like I still sometimes get a crash, so I might not have increased it enough. I noticed that thread_pool_stack is marked as experimental in the doc and was defaulted to -1 in varnish 3, which I assume was "disabling" it. I tried setting it to -1 on varnish 4 but couldn't get any page of my website to load, so assumed that -1 in varnish 4 was not valid (although I did not investigate more). So here are some questions: - since this param is marked as experimental is there any way to "disable" it? - is there any documentation available describing this param more in depth? (considering I read: https://www.varnish- cache.org/docs/4.0/reference/varnishd.html#thread-pool-stack) Thanks! -Hugues -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 20 00:42:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 Nov 2014 00:42:38 -0000 Subject: [Varnish] #1631: timeout and 503 In-Reply-To: <050.d9fdf1912c75a15bfd3724162e2f0221@varnish-cache.org> References: <050.d9fdf1912c75a15bfd3724162e2f0221@varnish-cache.org> Message-ID: <065.77f15c41e06ea2d193702c1aafdf3191@varnish-cache.org> #1631: timeout and 503 --------------------------+---------------------- Reporter: lorenzololli | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: invalid Keywords: | --------------------------+---------------------- Changes (by fgsch): * status: new => closed * resolution: => invalid Comment: Please use the mailing lists for questions, not the bug tracking system. See https://www.varnish-cache.org/lists/mailman/listinfo for available lists. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 20 10:47:46 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 Nov 2014 10:47:46 -0000 Subject: [Varnish] #1632: Debian: postinst broken Message-ID: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> #1632: Debian: postinst broken ---------------------+----------------------- Reporter: idl0r | Type: defect Status: new | Priority: normal Milestone: | Component: packaging Version: unknown | Severity: normal Keywords: | ---------------------+----------------------- Hi, the postinst script of the official Debian files does a "start" instead of "restart" which thus results into "[FAIL] Starting HTTP accelerator: varnishd failed!" if the daemons are already started/running. This will lead into a package "not fully installed or removed". # /etc/init.d/varnish start [FAIL] Starting HTTP accelerator: varnishd failed! A restart should be used instead, for all services, varnish, varnishncsa and varnishlog. Or, as "wedge" just mentioned in #varnish: wedge | postint should stop varnish prior to upgrade / config changes wedge | usually this is what most packages do -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 20 12:05:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 Nov 2014 12:05:38 -0000 Subject: [Varnish] #1630: Varnish crashes with long regex condition In-Reply-To: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> References: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> Message-ID: <064.a0f075471ed06b7b15405af1cb2c264a@varnish-cache.org> #1630: Varnish crashes with long regex condition -------------------------+-------------------- Reporter: huguesalary | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by paluna): Using varnishd (varnish-4.0.2 revision bfe7cd1) I get this annoying crash as well (the exact same segfault message). It occurs +- 1x/week on a website with 50K hits per day (20% are smartphones) but I cannot reproduce it at all. I restart the varnish cache daemon every night, it might occur more frequently if I do not do the restart every night. I see some similarities with this ticket. I also use User-Agent regexp's intensively. But your repro command works fine on my installation. There are no traces in the web server logs around that timestamp so it occurs before the request is passed to the backend. I already changed these settings a month ago but it does not fix it unfortunately. VARNISH_PCRE_MATCH_LIMIT=2500 VARNISH_PCRE_MATCH_LIMIT_RECURSION=2500 VARNISH_THREAD_POOL_STACK=72k The only extra artifacts I have are the Ubuntu .crash file and the apport.log https://dl.dropboxusercontent.com/u/5629939/temp/_usr_sbin_varnishd.65534.crash https://dl.dropboxusercontent.com/u/5629939/temp/apport.log -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 20 18:41:51 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 20 Nov 2014 18:41:51 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.c50b9dc3e573e81357eaf0286a5d0bfc@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+----------------------------------------------- Reporter: Jay | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Comment (by zaterio@?): Still persist in 7746e30 - High transfer server (2 Gbps) Regards. varnishd -V varnishd (varnish-trunk revision 7746e30) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2014 Varnish Software AS varnish> panic.show 200 Last panic at: Thu, 20 Nov 2014 13:51:19 GMT Assert error in VBO_DerefBusyObj(), cache/cache_busyobj.c line 171: Condition((bo) != NULL) not true. thread = (cache-worker) version = varnish-trunk revision 7746e30 ident = Linux,3.2.0-0.bpo.1-amd64,x86_64,-smalloc,-smalloc,-hclassic,epoll Backtrace: 0x4327df: pan_ic+0xdf 0x4183a0: VBO_DerefBusyObj+0x2a0 0x42093d: VBF_Fetch+0x2bd 0x4362a4: cnt_lookup+0x434 0x437db1: CNT_Request+0x2a1 0x44cbcb: HTTP1_Session+0x53b 0x43a878: ses_req_pool_task+0x68 0x434c2b: Pool_Work_Thread+0x33b 0x4474df: WRK_Thread+0x10f 0x43483b: pool_thread+0x2b req = 0x7fedb6be47a0 { sp = 0x7fe9fef870b0, vxid = 3244336, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fe9fef870b0 { fd = 100, vxid = 1015862, client = 200.28.7.138 47686, step = S_STP_WORKING, }, worker = 0x7ff15b215c50 { stack = {0x7ff15b216000 -> 0x7ff15b20a000} ws = 0x7ff15b215e60 { id = "wrk", {s,f,r,e} = {0x7ff15b215430,0x7ff15b215430,(nil),+2040}, }, VCL::method = HIT, VCL::return = deliver, VCL::methods = {RECV, HASH, MISS, HIT, DELIVER, SYNTH, BACKEND_FETCH, BACKEND_RESPONSE}, }, ws = 0x7fedb6be4950 { id = "req", {s,f,r,e} = {0x7fedb6be6770,+560,(nil),+57384}, }, http[req] = { ws = 0x7fedb6be4950[req] "GET", "/chvhddesktop/chvMi.m3u8", "HTTP/1.1", "Host: live.hls.http.chv.ztreaming.com", "Accept: */*", "Referer: http://www.chilevision.cl/", "Accept-Language: es-ES,es;q=0.8,en;q=0.6", "If-Modified-Since: Thu, 20 Nov 2014 13:50:23 GMT", "If-None-Match: "546df19f-af"", "X-Varnish: 25519714", "X-Forwarded-For: 201.223.91.74, 201.223.91.74, 200.28.7.138, 200.28.7.138", "Accept-Encoding: gzip", }, vcl = { srcname = { "input", "Builtin", "/etc/varnish/default.vcl", }, }, objcore (REQ) = 0x7fef5905dc70 { refcnt = 1 flags = 0x0 objhead = 0x7fea40011030 stevedore = 0x1286e80 (malloc s0) } }, -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 09:24:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 09:24:28 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.9df74f44f13317b1d50a45a8e76c4baf@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+----------------------------------------------- Reporter: Jay | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Comment (by franveux): Just to help, with ugly code no child crash during 3 days. But the strange thing is that there's only one syslog message ... as if the issue hit only once in the child's life. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 14:18:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 14:18:28 -0000 Subject: [Varnish] #1633: Change backend director doesn't work Message-ID: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> #1633: Change backend director doesn't work ------------------------------+-------------------- Reporter: steven.raccourci | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.2 | Severity: normal Keywords: director | ------------------------------+-------------------- First, thanks for Varnish ! However, something strange occures in version 4. Basically, I've got 3 web backends, 1 for the admin users and the 2 others for the public traffic. The choice of the cluster (admin / public) is done in vcl_recv, but it doesn't seem to work. Users are sent to a cluster according to the content of their cookies (PHP session or not) The relevant parts of the VCL file are the following : {{{ # Above is the backends declaration that properly work, plus the "directors" import sub vcl_init { new cluster_public = directors.round_robin(); cluster_public.add_backend(backendf1); cluster_public.add_backend(backendf2); new cluster_admin = directors.round_robin(); cluster_admin.add_backend(backenda1); } ... sub vcl_recv { set req.backend_hint = cluster_public.backend(); # Various things happens here, but no backend affectation ... if (req.http.Cookie) { # Forward to the backend admin if a session exists and disable cache if (req.http.Cookie ~ "SESS[a-z0-9]+") { set req.backend_hint = cluster_admin.backend(); return (pass); } } return (hash); } }}} What happens is that every hit ends on a public backend despite the cache disabling works (return (pass)). I can provide some more of my VCL if it is needed. All of my backend are marked as "healthy", are properly configured and point to the right machines (ping-checked). Is it possible that "set req.backend_hint = *.backend();" actually appens a backend / directory instead of setting a single value ? I ran some tests that says not, but I might be wrong. What's more, when I only define once the backend like this : {{{ if (req.http.Cookie ~ "SESS[a-z0-9]+") { set req.backend_hint = cluster_admin.backend(); } else { set req.backend_hint = cluster_public.backend(); } }}} It works like a charm. Am I missing something ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 14:55:46 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 14:55:46 -0000 Subject: [Varnish] #1307: Multiple StatSess records in varnishlog (3.0.3plus) In-Reply-To: <043.e29141848057645f33a5dc1ea330536a@varnish-cache.org> References: <043.e29141848057645f33a5dc1ea330536a@varnish-cache.org> Message-ID: <058.c78834ef8889702379eb911ea5ee7520@varnish-cache.org> #1307: Multiple StatSess records in varnishlog (3.0.3plus) ----------------------+---------------------- Reporter: scoof | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: wontfix Keywords: plus | ----------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => wontfix Comment: OBE time out Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:02:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:02:53 -0000 Subject: [Varnish] #1187: Document restrictions on range requests In-Reply-To: <043.3a5b79d566e4d093cdee9d9c0342bc65@varnish-cache.org> References: <043.3a5b79d566e4d093cdee9d9c0342bc65@varnish-cache.org> Message-ID: <058.fc69994ec53d7308d2984675377f2280@varnish-cache.org> #1187: Document restrictions on range requests ---------------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+----------------------- Comment (by lkarsten): After reviewing this on VDD14Q4, I think we rather should just document this properly. Should also be noted that with the new fetch processors it should be pretty simple to add a more complete Range implementation and avoid documenting some of these. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:04:20 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:04:20 -0000 Subject: [Varnish] #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. In-Reply-To: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> References: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> Message-ID: <058.5362fb6048fc38e3d09264937dd5229c@varnish-cache.org> #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. ----------------------+------------------------- Reporter: geoff | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: major | Resolution: worksforme Keywords: gzip | ----------------------+------------------------- Changes (by martin): * status: new => closed * resolution: => worksforme Comment: This part of Varnish has changed significantly in Varnish 4, making this bug invalid. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:07:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:07:24 -0000 Subject: [Varnish] #940: For gzip and un-gzip: Change ETags and add Vary In-Reply-To: <043.d3f0122c5f2e8a8e1ed36783de6aff0a@varnish-cache.org> References: <043.d3f0122c5f2e8a8e1ed36783de6aff0a@varnish-cache.org> Message-ID: <058.aca608689f1a33d480cb487c3f1c7a36@varnish-cache.org> #940: For gzip and un-gzip: Change ETags and add Vary ----------------------+--------------------- Reporter: david | Owner: slink Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 3.0.0 Severity: critical | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: Closing, this has turned into a zombie. (at VDD14Q4) Related: https://www.varnish-cache.org/lists/pipermail/varnish- dev/2014-August/007955.html -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:10:40 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:10:40 -0000 Subject: [Varnish] #1449: Assert error in ban_check_object(), cache/cache_ban.c line 915 In-Reply-To: <046.7113ebd1ce10ac27acc0986067f77f64@varnish-cache.org> References: <046.7113ebd1ce10ac27acc0986067f77f64@varnish-cache.org> Message-ID: <061.07e0f5aeb172c66bff2f257e81c427f8@varnish-cache.org> #1449: Assert error in ban_check_object(), cache/cache_ban.c line 915 ----------------------+---------------------------------- Reporter: lkarsten | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: I never got around to rerunning the tests, but we haven't seen this for 8 months and there are a lot of people running 4.0 now. We would have heard about it if it was still the case. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:12:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:12:23 -0000 Subject: [Varnish] #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check In-Reply-To: <057.dbb04d60a18cae71789693faca361b5c@varnish-cache.org> References: <057.dbb04d60a18cae71789693faca361b5c@varnish-cache.org> Message-ID: <072.f9fd09c67cf1c0ee015403f7610f1277@varnish-cache.org> #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check -------------------------+--------------------- Reporter: jinjian.1@? | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: stream Gzip | -------------------------+--------------------- Comment (by fgsch): Timed out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:13:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:13:53 -0000 Subject: [Varnish] #1465: Empty chunked response on storage failure In-Reply-To: <046.2a16722930c8a8f8903e2d31a85fb9eb@varnish-cache.org> References: <046.2a16722930c8a8f8903e2d31a85fb9eb@varnish-cache.org> Message-ID: <061.ea9e2bc3a5a8e0785d854357e8e12375@varnish-cache.org> #1465: Empty chunked response on storage failure ----------------------+--------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: The question of RST has been moved to future features. Closing ticket. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:16:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:16:50 -0000 Subject: [Varnish] #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check In-Reply-To: <057.dbb04d60a18cae71789693faca361b5c@varnish-cache.org> References: <057.dbb04d60a18cae71789693faca361b5c@varnish-cache.org> Message-ID: <072.0b59acec1b2394fd37ae86abf38a7db5@varnish-cache.org> #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check -------------------------+------------------------- Reporter: jinjian.1@? | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: worksforme Keywords: stream Gzip | -------------------------+------------------------- Changes (by fgsch): * status: new => closed * resolution: => worksforme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:25:06 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:25:06 -0000 Subject: [Varnish] #1608: Varnish does not return 413 or 414 In-Reply-To: <043.855604c38eb44e6eba395fc067ec62e2@varnish-cache.org> References: <043.855604c38eb44e6eba395fc067ec62e2@varnish-cache.org> Message-ID: <058.8799a39b0fe3939b02235a5414e6bfd7@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 | Resolution: Keywords: | --------------------+-------------------- Comment (by lkarsten): phk says: send a patch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:26:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:26:07 -0000 Subject: [Varnish] #1604: Reject request lines that don't conform to the Request-URI definition in HTTP/1.1 In-Reply-To: <050.14a3350c32e64c2892a15e7ace57f8e4@varnish-cache.org> References: <050.14a3350c32e64c2892a15e7ace57f8e4@varnish-cache.org> Message-ID: <065.be16da68c5b55e46ffb9abba57ab7441@varnish-cache.org> #1604: Reject request lines that don't conform to the Request-URI definition in HTTP/1.1 --------------------------+---------------------- Reporter: mattrobenolt | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: wontfix Keywords: http | --------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => wontfix Comment: This kind of error checking is better performed in the backend. 12:32 < phk> if you want to be strict, use vmod_i_want_to_be_more_strict_because_my_backend_sucks -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:28:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:28:50 -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.cbf1131485a3dffd7cbf49e059770659@varnish-cache.org> #1618: The "Range" header is not honored for a cache miss. -------------------------------+--------------------- Reporter: jeffawang | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: range header miss | -------------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:32:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:32:44 -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.ce1899cf76a44e877bd69ca3f7c8364a@varnish-cache.org> #1462: ReqURL is emitted twice --------------------+----------------------------------------------- Reporter: scoof | Owner: Martin Blix Grydeland Type: defect | Status: reopened Priority: normal | Milestone: Varnish 4.0-TP2 Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+----------------------------------------------- Comment (by lkarsten): Dag explained on VDD14Q4: varnishncsa should pick the first on the request side, and overwrite /use the last entry if on the delivery side. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:35:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:35:48 -0000 Subject: [Varnish] #1627: Response where you have do_gzip and do_stream enabled return a wrong content-length to HTTP/1.0 clients In-Reply-To: <041.a4ee8870cc795a7f4ced77cec3172663@varnish-cache.org> References: <041.a4ee8870cc795a7f4ced77cec3172663@varnish-cache.org> Message-ID: <056.d4c9fd286ecfb855ea0651b59c793c5e@varnish-cache.org> #1627: Response where you have do_gzip and do_stream enabled return a wrong content-length to HTTP/1.0 clients --------------------+-------------------- Reporter: tnt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.6 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by lkarsten): cut from bugwash: {{{ 12:18 < fgs> since it is 3.0 specific and he has a workaround, do we care? 12:19 < scn> fgs: i'd like a review of the patch, and if it is sane then we'll put it in 3.0 and perhaps do a final 3.0.7 with it in march }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:41:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:41:34 -0000 Subject: [Varnish] #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 In-Reply-To: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> References: <046.1f51127ba4909c87efc53a43f32f4411@varnish-cache.org> Message-ID: <061.dd3674be276d25b934ca77539989c68b@varnish-cache.org> #1629: Assert error in SES_ReleaseReq(), ../../include/tbl/acct_fields_req.h line 33 ----------------------+------------------ Reporter: xieyugui | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+------------------ Comment (by lkarsten): This will be in the upcoming 4.0.3. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:42:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:42:11 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.88b812c926e32ccfdbbff8be4503406b@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+----------------------------------------------- Reporter: Jay | Owner: Martin Blix Grydeland Type: defect | Status: reopened Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------- Changes (by martin): * status: closed => reopened * resolution: fixed => Comment: Need to revisit this -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:43:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:43:08 -0000 Subject: [Varnish] #1601: PRIV_{REQ, SESS} method invocations crash in vcl_backend_* In-Reply-To: <043.4159ad35442738d960b0976a1759d0e8@varnish-cache.org> References: <043.4159ad35442738d960b0976a1759d0e8@varnish-cache.org> Message-ID: <058.eeae2940a46954e5024fa303d5d33f57@varnish-cache.org> #1601: PRIV_{REQ,SESS} method invocations crash in vcl_backend_* ----------------------+-------------------- Reporter: daghf | Owner: daghf Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by daghf): * owner: => daghf -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:43:06 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:43:06 -0000 Subject: [Varnish] #1632: Debian: postinst broken In-Reply-To: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> References: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> Message-ID: <058.ed944ec7ff0c96936aacbb9d63c40d25@varnish-cache.org> #1632: Debian: postinst broken -----------------------+---------------------- Reporter: idl0r | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: invalid Keywords: | -----------------------+---------------------- Changes (by lkarsten): * status: new => closed * resolution: => invalid Comment: Please file this with the Debian bugtracker. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:44:51 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:44:51 -0000 Subject: [Varnish] #1608: Varnish does not return 413 or 414 In-Reply-To: <043.855604c38eb44e6eba395fc067ec62e2@varnish-cache.org> References: <043.855604c38eb44e6eba395fc067ec62e2@varnish-cache.org> Message-ID: <058.01d6786f0a6c84621b1afea149b3615d@varnish-cache.org> #1608: Varnish does not return 413 or 414 --------------------+-------------------- Reporter: fgsch | Owner: fgsch Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+-------------------- Changes (by fgsch): * owner: => fgsch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:45:22 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:45:22 -0000 Subject: [Varnish] #1633: Change backend director doesn't work In-Reply-To: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> References: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> Message-ID: <069.9aff13ababe68bb63db026ebb752be1c@varnish-cache.org> #1633: Change backend director doesn't work ------------------------------+-------------------- Reporter: steven.raccourci | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: director | ------------------------------+-------------------- Comment (by daghf): Can you please provide varnishlog output for a transaction that demonstrates the behavior? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:45:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:45:27 -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.76dc6b6ec5845069d9773b4fc6e357a9@varnish-cache.org> #1609: Reset MGT.child_panic after a panic.clear -------------------------+-------------------- Reporter: coredump | Owner: fgsch Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Changes (by fgsch): * owner: => fgsch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 15:48:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 15:48:24 -0000 Subject: [Varnish] #1632: Debian: postinst broken In-Reply-To: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> References: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> Message-ID: <058.90bd9dbd12304957b12a2f26d8a94aeb@varnish-cache.org> #1632: Debian: postinst broken -----------------------+----------------------- Reporter: idl0r | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+----------------------- Changes (by idl0r): * status: closed => reopened * resolution: invalid => Comment: Nope, sorry, this is from repo.varnish-cache.org. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 16:18:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 16:18:48 -0000 Subject: [Varnish] #1625: if(req.backend_hint == b1) compiles, but does nothing In-Reply-To: <049.31d68d5e448809c705a9e47a94fc94ce@varnish-cache.org> References: <049.31d68d5e448809c705a9e47a94fc94ce@varnish-cache.org> Message-ID: <064.494640850392e2ccfe09a4dfeb2bbfa8@varnish-cache.org> #1625: if(req.backend_hint == b1) compiles, but does nothing -------------------------+-------------------- Reporter: huguesalary | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Changes (by fgsch): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 21 19:24:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Nov 2014 19:24:13 -0000 Subject: [Varnish] #1634: How to append a cookie on backend Message-ID: <046.f5b1941d4fc818f380ad2479e71d27c5@varnish-cache.org> #1634: How to append a cookie on backend ----------------------+--------------------- Reporter: Phoenix9 | Type: defect Status: new | Priority: highest Milestone: | Component: build Version: unknown | Severity: major Keywords: | ----------------------+--------------------- The case is I'd like to add two headers with the same name, but different values while processing response from the backend server. More precisely under certain circumstances I'd like to append (not set) another Set- Cookie header to the original response from my Apache server to eventually return two cookies to the client. It seems that "set" action overrides all occurrences of the same header. Is that somehow possible? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Nov 22 18:13:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 22 Nov 2014 18:13:57 -0000 Subject: [Varnish] #1634: How to append a cookie on backend In-Reply-To: <046.f5b1941d4fc818f380ad2479e71d27c5@varnish-cache.org> References: <046.f5b1941d4fc818f380ad2479e71d27c5@varnish-cache.org> Message-ID: <061.1dc7d605f71f0261844fe729a68dfca7@varnish-cache.org> #1634: How to append a cookie on backend ----------------------+---------------------- Reporter: Phoenix9 | Owner: Type: defect | Status: closed Priority: highest | Milestone: Component: build | Version: unknown Severity: major | Resolution: invalid Keywords: | ----------------------+---------------------- Changes (by fgsch): * status: new => closed * resolution: => invalid Comment: You can use the header vmod but please use the mailing lists for questions, not the bug tracking system. See https://www.varnish-cache.org/lists/mailman/listinfo for available lists. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Nov 23 13:29:02 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 23 Nov 2014 13:29:02 -0000 Subject: [Varnish] #1513: Changes in v_b_r or v_b_e lost in v_s when returning abandon In-Reply-To: <043.db2ab567f1ed05ba57f00e57b891cb67@varnish-cache.org> References: <043.db2ab567f1ed05ba57f00e57b891cb67@varnish-cache.org> Message-ID: <058.0d4414f5c762cec60e23813a06fa26f0@varnish-cache.org> #1513: Changes in v_b_r or v_b_e lost in v_s when returning abandon --------------------+-------------------- Reporter: fgsch | Owner: fgsch Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+-------------------- Changes (by fgsch): * owner: phk => fgsch Comment: I don't remember the reasoning behind this now. I'll get back to my notes on this and update the ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Nov 23 13:38:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 23 Nov 2014 13:38:04 -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.5126c2eb598e8aaed8e3b7795b78e109@varnish-cache.org> #1618: The "Range" header is not honored for a cache miss. -------------------------------+--------------------- Reporter: jeffawang | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: range header miss | -------------------------------+--------------------- Comment (by fgsch): This is fixed in master. Attached is a testcase for it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Nov 23 21:16:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 23 Nov 2014 21:16:23 -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.429e625ba7f8c79e5667a0cda938ebe7@varnish-cache.org> #1618: The "Range" header is not honored for a cache miss. -------------------------------+--------------------- Reporter: jeffawang | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: range header miss | -------------------------------+--------------------- Comment (by fgsch): Tried with 4.0.2 and cannot reproduce it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 24 08:00:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Nov 2014 08:00:11 -0000 Subject: [Varnish] #1633: Change backend director doesn't work In-Reply-To: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> References: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> Message-ID: <069.53769ce8fe045111fb7790f6cb252505@varnish-cache.org> #1633: Change backend director doesn't work ------------------------------+-------------------- Reporter: steven.raccourci | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: director | ------------------------------+-------------------- Comment (by steven.raccourci): Hop you'll find what you're looking for :) {{{ * << Request >> 339837449 - Begin req 339837446 rxreq - Timestamp Start: 1416815809.432919 0.000000 0.000000 - Timestamp Req: 1416815809.432919 0.000000 0.000000 - ReqStart xxx.xxx.xxx.xxx 50015 - ReqMethod GET - ReqURL /?foo - ReqProtocol HTTP/1.1 - ReqHeader Host: www.saintlary.com - ReqHeader Connection: keep-alive - ReqHeader Pragma: no-cache - ReqHeader Cache-Control: no-cache - ReqHeader Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 - ReqHeader User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36 - ReqHeader Accept-Encoding: gzip,deflate,sdch - ReqHeader Accept-Language: fr,en-US;q=0.8,en;q=0.6,fr-FR;q=0.4 - ReqHeader Cookie: ot-st-lary_hiver=0eede76i7r27oplrvrgje3n4r7; ot-st-lary_ete=1481bou3q47hpcadt0vf3q36m2; __utma=1.1558254274.1414403769.1414403769.1414403769.1; __utmz=1.1414403769.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); SESS243 - ReqHeader X-Forwarded-For: xxx.xxx.xxx.xxx - VCL_call RECV - ReqHeader X-Real-IP: xxx.xxx.xxx.xxx - ReqUnset Host: www.saintlary.com - ReqHeader Host: www.saintlary.com - VCL_return pass - VCL_call HASH - VCL_return lookup - VCL_call PASS - VCL_return fetch - Link bereq 339837450 pass - Timestamp Fetch: 1416815809.695994 0.263075 0.263075 - RespProtocol HTTP/1.1 - RespStatus 200 - RespReason OK - RespHeader Date: Mon, 24 Nov 2014 07:56:49 GMT - RespHeader Server: Apache - RespHeader Expires: Sun, 19 Nov 1978 05:00:00 GMT - RespHeader Last-Modified: Mon, 24 Nov 2014 07:56:49 +0000 - RespHeader Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0 - RespHeader ETag: "1416815809" - RespHeader Content-Language: fr - RespHeader Vary: Accept-Encoding - RespHeader Content-Encoding: gzip - RespHeader Content-Type: text/html; charset=utf-8 - RespHeader X-Backend: backendf2 - RespHeader X-Domain: www.saintlary.com - RespHeader X-Varnish: 339837449 - RespHeader Age: 0 - RespHeader Via: 1.1 varnish-v4 - VCL_call DELIVER - RespHeader X-Varnish-Cache: MISS - RespUnset Server: Apache - RespUnset X-Domain: www.saintlary.com - RespUnset X-Varnish: 339837449 - RespUnset Via: 1.1 varnish-v4 - VCL_return deliver - Timestamp Process: 1416815809.696049 0.263131 0.000055 - Debug "RES_MODE 8" - RespHeader Transfer-Encoding: chunked - RespHeader Connection: keep-alive - RespHeader Accept-Ranges: bytes - Timestamp Resp: 1416815809.696703 0.263784 0.000654 - Debug "XXX REF 1" - ReqAcct 979 0 979 468 20602 21070 - End }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 24 09:39:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Nov 2014 09:39:27 -0000 Subject: [Varnish] #1633: Change backend director doesn't work In-Reply-To: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> References: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> Message-ID: <069.eb84f89f12d3ea1e99689157faa22e6a@varnish-cache.org> #1633: Change backend director doesn't work ------------------------------+-------------------- Reporter: steven.raccourci | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: director | ------------------------------+-------------------- Comment (by fgsch): Can you use varnishlog -g request please and also include the full vcl_recv? Also in your VCL you are matching against "SESS[a-z0-9]+" which only covers numbers and lowercase characters after SESS. Are you sure the cookie won't have any uppercase characters on it? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 24 21:27:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Nov 2014 21:27:50 -0000 Subject: [Varnish] #1628: Assert error in VBO_DerefBusyObj() In-Reply-To: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> References: <041.d988225a70fb3421845c28c4830e2c87@varnish-cache.org> Message-ID: <056.f7a0dcdea0f32043c91d43d30c579ff3@varnish-cache.org> #1628: Assert error in VBO_DerefBusyObj() ----------------------+----------------------------------------------- Reporter: Jay | Owner: Martin Blix Grydeland Type: defect | Status: reopened Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------- Comment (by chrisj): The last commit did seem to reduce the frequency of crashes. We have since had one crash which occurred after 5 days of uptime. {{{ Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 878: Condition(bo->director_state == DIR_S_NULL) not true. thread = (cache-worker) version = varnish-trunk revision 7746e30 ident = Linux,3.2.0-58-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43311f: pan_ic+0xdf 0x423bfb: vbf_fetch_thread+0x25ab 0x435981: Pool_Work_Thread+0x361 0x4488af: WRK_Thread+0x11f 0x43471b: pool_thread+0x2b 0x7fb4dd663e9a: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7fb4dd663e9a] 0x7fb4dd39131d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fb4dd39131d] busyobj = 0x7fab8934a020 { ws = 0x7fab8934a0e0 { id = "bo", {s,f,r,e} = {0x7fab8934bf88,+832,(nil),+57488}, }, refcnt = 1 retries = 0 failed = 1 state = 4 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 26 08:16:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 26 Nov 2014 08:16:03 -0000 Subject: [Varnish] #1633: Change backend director doesn't work In-Reply-To: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> References: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> Message-ID: <069.43fcaee645f63e3f5b1904770081b5fd@varnish-cache.org> #1633: Change backend director doesn't work ------------------------------+-------------------- Reporter: steven.raccourci | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: Keywords: director | ------------------------------+-------------------- Comment (by steven.raccourci): Sorry for the late response. So here is the full vcl_recv : {{{ # Handle the HTTP request received by the client sub vcl_recv { # Choose the round-robin backend set req.backend_hint = cluster_public.backend(); # shortcut for DFind requests if (req.url ~ "^/w00tw00t") { return (synth(404, "Not Found")); } if (req.restarts == 0) { if (!req.http.X-Real-IP) { set req.http.X-Real-IP = client.ip; } } # Normalize the header, remove the port (in case you're testing this on various TCP ports) set req.http.Host = regsub(req.http.Host, ":[0-9]+", ""); # Allow purging if (req.method == "PURGE") { if (!client.ip ~ purge) { # Not from an allowed IP? Then die with an error. return (synth(405, "This IP is not allowed to send PURGE requests.")); } # If you got this stage (and didn't error out above), purge the cached result return (purge); } # Allow ban if (req.method == "BAN") { if (!client.ip ~ purge) { # Not from an allowed IP? Then die with an error. return (synth(405, "This IP is not allowed to send PURGE requests.")); } if (req.url != "/") { # Ban every cache object containing the given tag ban("obj.http.x-domain == " + req.http.host + " && obj.http.x -drupal-cache-tags ~ " + regsuball(req.url, "^/", "")); } else { # Ban the full domain ban("obj.http.x-domain == " + req.http.host); } return(synth(200, "BAN added")); } # Only deal with "normal" types if (req.method != "GET" && req.method != "HEAD" && req.method != "PUT" && req.method != "POST" && req.method != "TRACE" && req.method != "OPTIONS" && req.method != "PATCH" && req.method != "DELETE") { /* Non-RFC2616 or CONNECT which is weird. */ return (pipe); } # Only cache GET or HEAD requests. This makes sure the POST requests are always passed. if (req.method != "GET" && req.method != "HEAD") { return (pass); } # Don't cache. This makes sure requests are to this URL always passed. if (req.http.Cache-Control ~ "no-cache" || req.url ~ "^/phpmyadmin" || req.url ~ "^/user" || req.url ~ "^/apc") { return (pass); } # Some generic URL manipulation, useful for all templates that follow # First remove the Google Analytics added parameters, useless for our backend if (req.url ~ "(\?|&)(utm_source|utm_medium|utm_campaign|gclid|cx|ie|cof|siteurl)=") { set req.url = regsuball(req.url, "&(utm_source|utm_medium|utm_campaign|gclid|cx|ie|cof|siteurl)=([A-z0-9_\-\.%25]+)", ""); set req.url = regsuball(req.url, "\?(utm_source|utm_medium|utm_campaign|gclid|cx|ie|cof|siteurl)=([A-z0-9_\-\.%25]+)", "?"); set req.url = regsub(req.url, "\?&", "?"); set req.url = regsub(req.url, "\?$", ""); } # Strip a trailing ? if it exists if (req.url ~ "\?$") { set req.url = regsub(req.url, "\?$", ""); } # Normalize Accept-Encoding header # straight from the manual: https://www.varnish- cache.org/docs/3.0/tutorial/vary.html if (req.http.Accept-Encoding) { if (req.url ~ "\.(jpg|jpeg|png|gif|gz|tgz|bz2|tbz|tgz|rar|zip|mp[34]|ogg|wav)$") { # No point in compressing these unset req.http.Accept-Encoding; } elsif (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { # unkown algorithm unset req.http.Accept-Encoding; } } # Large static files should be piped, so they are delivered directly to the end-user without # waiting for Varnish to fully read the file first. if (req.url ~ "^[^?]*\.(gz|bz2|tbz|zip|tgz|rar|doc|docx|xls|xlsx|odt|flv|pdf|rtf|swf|mp[34]|ogg|wav|bmp|gif|ico|jpeg|jpg|png|css|js|less|eot|ttf|woff|txt|xml|html|htm)(\?.*)?$") { unset req.http.Cookie; return (pass); } # Remove all cookies if (req.http.Cookie) { # Forward to the backend admin if a session exists and disable cache if (req.http.Cookie ~ "SESS[a-z0-9]+") { set req.backend_hint = cluster_admin.backend(); return (pass); } # Remove all cookies for SSO My Account if (req.url ~ "^/api/myaccount" && req.http.Cookie ~ "RC-API- SESSID") { return (pass); } unset req.http.Cookie; } return (hash); } }}} Here is the results of varnishlog ({{{varnishlog -g request -w varnish.log -q "ReqURL eq '/?foo'"}}}), (drupalf2 is the name of one of our public backends) : {{{ * << Request >> 390792402 - Begin req 390792401 rxreq - Timestamp Start: 1416989650.113073 0.000000 0.000000 - Timestamp Req: 1416989650.113073 0.000000 0.000000 - ReqStart 10.7.0.18 50119 - ReqMethod GET - ReqURL /?foo - ReqProtocol HTTP/1.1 - ReqHeader Host: www.saintlary.com - ReqHeader Connection: keep-alive - ReqHeader Pragma: no-cache - ReqHeader Cache-Control: no-cache - ReqHeader Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 - ReqHeader User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36 - ReqHeader Accept-Encoding: gzip,deflate,sdch - ReqHeader Accept-Language: fr,en-US;q=0.8,en;q=0.6,fr-FR;q=0.4 - ReqHeader Cookie: ot-st-lary_hiver=0eede76i7r27oplrvrgje3n4r7; ot-st-lary_ete=1481bou3q47hpcadt0vf3q36m2; __utma=1.1558254274.1414403769.1414403769.1414403769.1; __utmz=1.1414403769.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); SESS243 - ReqHeader X-Forwarded-For: 10.7.0.18 - VCL_call RECV - ReqHeader X-Real-IP: 10.7.0.18 - ReqUnset Host: www.saintlary.com - ReqHeader Host: www.saintlary.com - VCL_return pass - VCL_call HASH - VCL_return lookup - VCL_call PASS - VCL_return fetch - Link bereq 390792403 pass - Timestamp Fetch: 1416989650.326714 0.213640 0.213640 - RespProtocol HTTP/1.1 - RespStatus 200 - RespReason OK - RespHeader Date: Wed, 26 Nov 2014 08:14:10 GMT - RespHeader Server: Apache - RespHeader Expires: Sun, 19 Nov 1978 05:00:00 GMT - RespHeader Last-Modified: Wed, 26 Nov 2014 08:14:10 +0000 - RespHeader Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0 - RespHeader ETag: "1416989650" - RespHeader Content-Language: fr - RespHeader Vary: Accept-Encoding - RespHeader Content-Encoding: gzip - RespHeader Content-Type: text/html; charset=utf-8 - RespHeader X-Backend: drupalf2 - RespHeader X-Domain: www.saintlary.com - RespHeader X-Varnish: 390792402 - RespHeader Age: 0 - RespHeader Via: 1.1 varnish-v4 - VCL_call DELIVER - RespHeader X-Varnish-Cache: MISS - RespUnset Server: Apache - RespUnset X-Domain: www.saintlary.com - RespUnset X-Varnish: 390792402 - RespUnset Via: 1.1 varnish-v4 - VCL_return deliver - Timestamp Process: 1416989650.326740 0.213666 0.000026 - Debug "RES_MODE 8" - RespHeader Transfer-Encoding: chunked - RespHeader Connection: keep-alive - RespHeader Accept-Ranges: bytes - Timestamp Resp: 1416989650.327441 0.214367 0.000701 - Debug "XXX REF 1" - ReqAcct 988 0 988 468 20602 21070 - End ** << BeReq >> 390792403 -- Begin bereq 390792402 pass -- Timestamp Start: 1416989650.113177 0.000000 0.000000 -- BereqMethod GET -- BereqURL /?foo -- BereqProtocol HTTP/1.1 -- BereqHeader Pragma: no-cache -- BereqHeader Cache-Control: no-cache -- BereqHeader Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 -- BereqHeader User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36 -- BereqHeader Accept-Encoding: gzip,deflate,sdch -- BereqHeader Accept-Language: fr,en-US;q=0.8,en;q=0.6,fr-FR;q=0.4 -- BereqHeader Cookie: ot-st-lary_hiver=0eede76i7r27oplrvrgje3n4r7; ot-st-lary_ete=1481bou3q47hpcadt0vf3q36m2; __utma=1.1558254274.1414403769.1414403769.1414403769.1; __utmz=1.1414403769.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); SESS243 -- BereqHeader X-Forwarded-For: 10.7.0.18 -- BereqHeader X-Real-IP: 10.7.0.18 -- BereqHeader Host: www.saintlary.com -- BereqHeader X-Varnish: 390792403 -- VCL_call BACKEND_FETCH -- VCL_return fetch -- BackendOpen 13 drupalf2(10.14.0.41,,80) 10.14.0.38 60648 -- Backend 13 cluster_public drupalf2(10.14.0.41,,80) -- Timestamp Bereq: 1416989650.113477 0.000300 0.000300 -- Timestamp Beresp: 1416989650.326505 0.213328 0.213028 -- BerespProtocol HTTP/1.1 -- BerespStatus 200 -- BerespReason OK -- BerespHeader Date: Wed, 26 Nov 2014 08:14:10 GMT -- BerespHeader Server: Apache -- BerespHeader Expires: Sun, 19 Nov 1978 05:00:00 GMT -- BerespHeader Last-Modified: Wed, 26 Nov 2014 08:14:10 +0000 -- BerespHeader Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0 -- BerespHeader ETag: "1416989650" -- BerespHeader Content-Language: fr -- BerespHeader Vary: Accept-Encoding -- BerespHeader Content-Encoding: gzip -- BerespHeader Connection: close -- BerespHeader Transfer-Encoding: chunked -- BerespHeader Content-Type: text/html; charset=utf-8 -- TTL RFC 0 -1 -1 1416989650 1416989650 1416989650 280299600 0 -- VCL_call BACKEND_RESPONSE -- BerespHeader X-Backend: drupalf2 -- BerespHeader X-Domain: www.saintlary.com -- TTL VCL 0 10 0 1416989650 -- VCL_return deliver -- Storage malloc Transient -- ObjProtocol HTTP/1.1 -- ObjStatus 200 -- ObjReason OK -- ObjHeader Date: Wed, 26 Nov 2014 08:14:10 GMT -- ObjHeader Server: Apache -- ObjHeader Expires: Sun, 19 Nov 1978 05:00:00 GMT -- ObjHeader Last-Modified: Wed, 26 Nov 2014 08:14:10 +0000 -- ObjHeader Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0 -- ObjHeader ETag: "1416989650" -- ObjHeader Content-Language: fr -- ObjHeader Vary: Accept-Encoding -- ObjHeader Content-Encoding: gzip -- ObjHeader Content-Type: text/html; charset=utf-8 -- ObjHeader X-Backend: drupalf2 -- ObjHeader X-Domain: www.saintlary.com -- Fetch_Body 2 chunked stream -- Gzip u F - 20587 144037 80 164616 164626 -- Timestamp BerespBody: 1416989650.327351 0.214174 0.000846 -- BackendClose 13 drupalf2(10.14.0.41,,80) -- Length 20587 -- BereqAcct 1036 0 1036 405 20604 21009 -- End }}} Our session ids are md5 alike with no uppercase character. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 26 12:23:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 26 Nov 2014 12:23:30 -0000 Subject: [Varnish] #1633: Change backend director doesn't work In-Reply-To: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> References: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> Message-ID: <069.38b225460125db36fe3bbeeb5e10600e@varnish-cache.org> #1633: Change backend director doesn't work ------------------------------+---------------------- Reporter: steven.raccourci | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: invalid Keywords: director | ------------------------------+---------------------- Changes (by fgsch): * status: new => closed * resolution: => invalid Comment: The problem is in your VCL. Specifically: {{{ # Don't cache. This makes sure requests are to this URL always passed. if (req.http.Cache-Control ~ "no-cache" || req.url ~ "^/phpmyadmin" || req.url ~ "^/user" || req.url ~ "^/apc") { return (pass); } }}} And in your request: {{{ - ReqHeader Cache-Control: no-cache }}} So the request is pass'd earlier before it reaches the other if statement where you set req.backend_hint. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 26 13:07:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 26 Nov 2014 13:07:38 -0000 Subject: [Varnish] #1633: Change backend director doesn't work In-Reply-To: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> References: <054.894b2be16275ce222e873e6cfbc3e14b@varnish-cache.org> Message-ID: <069.70c2489c5a11e02d895fcccd27b46794@varnish-cache.org> #1633: Change backend director doesn't work ------------------------------+---------------------- Reporter: steven.raccourci | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.2 Severity: normal | Resolution: invalid Keywords: director | ------------------------------+---------------------- Comment (by steven.raccourci): Oh sorry, you're right everything works fine (I use Chrome's console to check the responding backend but the console also sens a "no-cache" header by default). Thank you ! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 27 10:30:10 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Nov 2014 10:30:10 -0000 Subject: [Varnish] #1635: Completed bans keep accumulating Message-ID: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> #1635: Completed bans keep accumulating --------------------+---------------------- Reporter: Sesse | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: lurker | --------------------+---------------------- Hi, I have a site where almost every backend response (vcl_backend_response) produces a new ban, of the form: ban ( "obj.http.x-analysis == 1 && obj.http.x-rglm != " + beresp.http.x-rglm ); Pretty soon, these bans go into completed state. However, for some reason the ban lurker doesn't manage to delete them, even though there are no req.* bans. This seems to go on and on until I have hundreds of thousands of bans, and BAN_Insert and ban_lurker both take significant amounts of CPU time. Making the ban lurker wake up more often does not seem to help anything; the ban count still goes up and never seems to go down (at all). If I stop the backend entirely, so no requests ever go through, it seems to actually reduce the count after a while. Start it again, and the count increases. It's 100% reproducible for me. Relevant parts of varnishstat -1: MAIN.bans 507 . Count of bans MAIN.bans_completed 505 . Number of bans marked 'completed' MAIN.bans_obj 507 . Number of bans using obj.* MAIN.bans_req 0 . Number of bans using req.* MAIN.bans_added 25714 0.18 Bans added MAIN.bans_deleted 25207 0.18 Bans deleted MAIN.bans_tested 19528 0.14 Bans tested against objects (lookup) MAIN.bans_obj_killed 8168 0.06 Objects killed by bans (lookup) MAIN.bans_lurker_tested 20704629 147.19 Bans tested against objects (lurker) MAIN.bans_tests_tested 67431 0.48 Ban tests tested against objects (lookup) MAIN.bans_lurker_tests_tested 20721896 147.31 Ban tests tested against objects (lurker) MAIN.bans_lurker_obj_killed 13909 0.10 Objects killed by bans (lurker) MAIN.bans_dups 15323 0.11 Bans superseded by other bans MAIN.bans_lurker_contention 0 0.00 Lurker gave way for lookup MAIN.bans_persisted_bytes 1619932 . Bytes used by the persisted ban lists MAIN.bans_persisted_fragmentation 1613241 . Extra bytes in persisted ban lists due to fragmentation Relevant parts of my VCL: http://git.sesse.net/?p=remoteglot;a=blob;f=default.vcl;h=38631cb4f1d3c6f399dd4fb1378dec993339aa32;hb=HEAD This is Varnish from git, 7746e30e2c53cf55f0f2525bb3f49c9ee83e9611. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 27 10:48:51 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Nov 2014 10:48:51 -0000 Subject: [Varnish] #1635: Completed bans keep accumulating In-Reply-To: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> References: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> Message-ID: <058.33ab4d02c8c96d690eecedc94a3289ab@varnish-cache.org> #1635: Completed bans keep accumulating ----------------------+-------------------- Reporter: Sesse | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: lurker | ----------------------+-------------------- Description changed by lkarsten: Old description: > Hi, > > I have a site where almost every backend response (vcl_backend_response) > produces a new ban, of the form: > > ban ( "obj.http.x-analysis == 1 && obj.http.x-rglm != " + > beresp.http.x-rglm ); > > Pretty soon, these bans go into completed state. However, for some reason > the ban lurker doesn't manage to delete them, even though there are no > req.* bans. This seems to go on and on until I have hundreds of thousands > of bans, and BAN_Insert and ban_lurker both take significant amounts of > CPU time. Making the ban lurker wake up more often does not seem to help > anything; the ban count still goes up and never seems to go down (at > all). > > If I stop the backend entirely, so no requests ever go through, it seems > to actually reduce the count after a while. Start it again, and the count > increases. It's 100% reproducible for me. > > Relevant parts of varnishstat -1: > > MAIN.bans 507 . Count of bans > MAIN.bans_completed 505 . Number of bans marked > 'completed' > MAIN.bans_obj 507 . Number of bans using > obj.* > MAIN.bans_req 0 . Number of bans using > req.* > MAIN.bans_added 25714 0.18 Bans added > MAIN.bans_deleted 25207 0.18 Bans deleted > MAIN.bans_tested 19528 0.14 Bans tested against > objects (lookup) > MAIN.bans_obj_killed 8168 0.06 Objects killed by bans > (lookup) > MAIN.bans_lurker_tested 20704629 147.19 Bans tested against > objects (lurker) > MAIN.bans_tests_tested 67431 0.48 Ban tests tested > against objects (lookup) > MAIN.bans_lurker_tests_tested 20721896 147.31 Ban tests tested > against objects (lurker) > MAIN.bans_lurker_obj_killed 13909 0.10 Objects killed by > bans (lurker) > MAIN.bans_dups 15323 0.11 Bans superseded > by other bans > MAIN.bans_lurker_contention 0 0.00 Lurker gave way > for lookup > MAIN.bans_persisted_bytes 1619932 . Bytes used by the > persisted ban lists > MAIN.bans_persisted_fragmentation 1613241 . Extra bytes > in persisted ban lists due to > fragmentation > > Relevant parts of my VCL: > > http://git.sesse.net/?p=remoteglot;a=blob;f=default.vcl;h=38631cb4f1d3c6f399dd4fb1378dec993339aa32;hb=HEAD > > This is Varnish from git, 7746e30e2c53cf55f0f2525bb3f49c9ee83e9611. New description: Hi, I have a site where almost every backend response (vcl_backend_response) produces a new ban, of the form: ban ( "obj.http.x-analysis == 1 && obj.http.x-rglm != " + beresp.http.x-rglm ); Pretty soon, these bans go into completed state. However, for some reason the ban lurker doesn't manage to delete them, even though there are no req.* bans. This seems to go on and on until I have hundreds of thousands of bans, and BAN_Insert and ban_lurker both take significant amounts of CPU time. Making the ban lurker wake up more often does not seem to help anything; the ban count still goes up and never seems to go down (at all). If I stop the backend entirely, so no requests ever go through, it seems to actually reduce the count after a while. Start it again, and the count increases. It's 100% reproducible for me. Relevant parts of varnishstat -1: {{{ MAIN.bans 507 . Count of bans MAIN.bans_completed 505 . Number of bans marked 'completed' MAIN.bans_obj 507 . Number of bans using obj.* MAIN.bans_req 0 . Number of bans using req.* MAIN.bans_added 25714 0.18 Bans added MAIN.bans_deleted 25207 0.18 Bans deleted MAIN.bans_tested 19528 0.14 Bans tested against objects (lookup) MAIN.bans_obj_killed 8168 0.06 Objects killed by bans (lookup) MAIN.bans_lurker_tested 20704629 147.19 Bans tested against objects (lurker) MAIN.bans_tests_tested 67431 0.48 Ban tests tested against objects (lookup) MAIN.bans_lurker_tests_tested 20721896 147.31 Ban tests tested against objects (lurker) MAIN.bans_lurker_obj_killed 13909 0.10 Objects killed by bans (lurker) MAIN.bans_dups 15323 0.11 Bans superseded by other bans MAIN.bans_lurker_contention 0 0.00 Lurker gave way for lookup MAIN.bans_persisted_bytes 1619932 . Bytes used by the persisted ban lists MAIN.bans_persisted_fragmentation 1613241 . Extra bytes in persisted ban lists due to fragmentation }}} Relevant parts of my VCL: http://git.sesse.net/?p=remoteglot;a=blob;f=default.vcl;h=38631cb4f1d3c6f399dd4fb1378dec993339aa32;hb=HEAD This is Varnish from git, 7746e30e2c53cf55f0f2525bb3f49c9ee83e9611. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 27 16:00:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Nov 2014 16:00:29 -0000 Subject: [Varnish] #1636: Outdated paragraph in Vary: documentation for Varnish 4.0 Message-ID: <043.4d744112853e344703907f1c44f6decf@varnish-cache.org> #1636: Outdated paragraph in Vary: documentation for Varnish 4.0 --------------------------------+--------------------------- Reporter: mabes | Type: documentation Status: new | Priority: lowest Milestone: | Component: build Version: trunk | Severity: trivial Keywords: vary documentation | --------------------------------+--------------------------- On this page : https://www.varnish-cache.org/docs/4.0/users-guide/increasing-your- hitrate.html#http-vary There is an example of how to normalize a HTTP header, but the explanation under the code sample refers to an earlier example, still visible here : https://www.varnish-cache.org/docs/3.0/tutorial/vary.html#pitfall-vary- user-agent The attached patch updates the comment to reflect what the code sample really does -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 27 16:59:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Nov 2014 16:59:30 -0000 Subject: [Varnish] #1636: Outdated paragraph in Vary: documentation for Varnish 4.0 In-Reply-To: <043.4d744112853e344703907f1c44f6decf@varnish-cache.org> References: <043.4d744112853e344703907f1c44f6decf@varnish-cache.org> Message-ID: <058.790e09fd48d6fe10ea51827a81aa2609@varnish-cache.org> #1636: Outdated paragraph in Vary: documentation for Varnish 4.0 -----------------------------+--------------------------------------------- Reporter: mabes | Owner: Federico G. Schwindt Type: documentation | Status: closed Priority: lowest | Milestone: Component: build | Version: trunk Severity: trivial | Resolution: fixed Keywords: vary | documentation | -----------------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * owner: => Federico G. Schwindt * status: new => closed * resolution: => fixed Comment: In [5c80dc65291b1ca17d6955f3ae2e97c6fe7873c1]: {{{ #!CommitTicketReference repository="" revision="5c80dc65291b1ca17d6955f3ae2e97c6fe7873c1" Rework example Fixes #1636 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 28 10:27:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 28 Nov 2014 10:27:44 -0000 Subject: [Varnish] #1637: Assert error in VFP_Fetch_Body() Message-ID: <045.21ddee12af57707010d10fb844941331@varnish-cache.org> #1637: Assert error in VFP_Fetch_Body() --------------------------+---------------------- Reporter: llavaud | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.2 | Severity: major Keywords: Assert error | --------------------------+---------------------- Hello, I am using varnish 4.0.2 on a debian wheezy server. The varnish child regularly died with the following error log: Nov 27 16:03:26 webcache02 varnishd[27811]: Child (27830) Panic message:#012Assert error in VFP_Fetch_Body(), cache/cache_fetch_proc.c line 216:#012 Condition((bo->failed) == 0) not true.#012thread = (cache- worker)#012ident = Linux,3.2.0-4-amd64,x86_64,-sfile,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x4347c5: /usr/sbin/varnishd() [0x4347c5]#012 0x42432a: /usr/sbin/varnishd(VFP_Fetch_Body+0x2ba) [0x42432a]#012 0x421569: /usr/sbin/varnishd() [0x421569]#012 0x4376b3: /usr/sbin/varnishd(Pool_Work_Thread+0x373) [0x4376b3]#012 0x44a98d: /usr/sbin/varnishd() [0x44a98d]#012 0x7fa6735ebb50: /lib/x86_64-linux- gnu/libpthread.so.0(+0x6b50) [0x7fa6735ebb50]#012 0x7fa6733357bd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fa6733357bd]#012 busyobj = 0x7fa672b02020 {#012 ws = 0x7fa672b020e0 {#012 id = "bo",#012 {s,f,r,e} = {0x7fa672b04008,+1920,(nil),+253976},#012 },#012 refcnt = 2#012 retries = 0#012 failed = 1#012 state = 1#012 is_do_esi#012 is_do_gzip#012 is_is_gunzip#012 bodystatus = 3 (length),#012 },#012 http[bereq] = {#012 ws = 0x7fa672b020e0[bo]#012 "GET",#012 "/myuri",#012 "HTTP/1.1",#012 "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0",#012 "Accept: image/png,image/*;q=0.8,*/*;q=0.5",#012 "Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3",#012 "Referer: http://myhost/myuri",#012 "Host: myhost",#012 "Surrogate-Capability: abc=ESI/1.0",#012 "X-Forwarded-For: xxx, xxx",#012 "X-Varnish: 852351",#012 },#012 http[beresp] = {#012 ws = 0x7fa672b020e0[bo]#012 "HTTP/1.1",#012 "301",#012 "Moved Permanently",#012 "Date: Thu, 27 Nov 2014 15:03:25 GMT",#012 "Server: Apache",#012 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Nov 29 22:18:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 29 Nov 2014 22:18:43 -0000 Subject: [Varnish] #1637: Assert error in VFP_Fetch_Body() In-Reply-To: <045.21ddee12af57707010d10fb844941331@varnish-cache.org> References: <045.21ddee12af57707010d10fb844941331@varnish-cache.org> Message-ID: <060.88d8b8e33bb14ac841a0c62e3bd63b93@varnish-cache.org> #1637: Assert error in VFP_Fetch_Body() --------------------------+-------------------- Reporter: llavaud | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: major | Resolution: Keywords: Assert error | --------------------------+-------------------- Description changed by fgsch: Old description: > Hello, > > I am using varnish 4.0.2 on a debian wheezy server. > > The varnish child regularly died with the following error log: > > Nov 27 16:03:26 webcache02 varnishd[27811]: Child (27830) Panic > message:#012Assert error in VFP_Fetch_Body(), cache/cache_fetch_proc.c > line 216:#012 Condition((bo->failed) == 0) not true.#012thread = (cache- > worker)#012ident = > Linux,3.2.0-4-amd64,x86_64,-sfile,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x4347c5: /usr/sbin/varnishd() [0x4347c5]#012 0x42432a: > /usr/sbin/varnishd(VFP_Fetch_Body+0x2ba) [0x42432a]#012 0x421569: > /usr/sbin/varnishd() [0x421569]#012 0x4376b3: > /usr/sbin/varnishd(Pool_Work_Thread+0x373) [0x4376b3]#012 0x44a98d: > /usr/sbin/varnishd() [0x44a98d]#012 0x7fa6735ebb50: /lib/x86_64-linux- > gnu/libpthread.so.0(+0x6b50) [0x7fa6735ebb50]#012 0x7fa6733357bd: > /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fa6733357bd]#012 busyobj > = 0x7fa672b02020 {#012 ws = 0x7fa672b020e0 {#012 id = "bo",#012 > {s,f,r,e} = {0x7fa672b04008,+1920,(nil),+253976},#012 },#012 refcnt = > 2#012 retries = 0#012 failed = 1#012 state = 1#012 is_do_esi#012 > is_do_gzip#012 is_is_gunzip#012 bodystatus = 3 (length),#012 > },#012 http[bereq] = {#012 ws = 0x7fa672b020e0[bo]#012 > "GET",#012 "/myuri",#012 "HTTP/1.1",#012 "User- > Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 > Firefox/33.0",#012 "Accept: > image/png,image/*;q=0.8,*/*;q=0.5",#012 "Accept-Language: fr,fr- > fr;q=0.8,en-us;q=0.5,en;q=0.3",#012 "Referer: > http://myhost/myuri",#012 "Host: myhost",#012 "Surrogate- > Capability: abc=ESI/1.0",#012 "X-Forwarded-For: xxx, xxx",#012 > "X-Varnish: 852351",#012 },#012 http[beresp] = {#012 ws = > 0x7fa672b020e0[bo]#012 "HTTP/1.1",#012 "301",#012 > "Moved Permanently",#012 "Date: Thu, 27 Nov 2014 15:03:25 > GMT",#012 "Server: Apache",#012 New description: Hello, I am using varnish 4.0.2 on a debian wheezy server. The varnish child regularly died with the following error log: {{{ Nov 27 16:03:26 webcache02 varnishd[27811]: Child (27830) Panic message: Assert error in VFP_Fetch_Body(), cache/cache_fetch_proc.c line 216: Condition((bo->failed) == 0) not true. thread = (cache-worker) ident = Linux,3.2.0-4-amd64,x86_64,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x4347c5: /usr/sbin/varnishd() [0x4347c5] 0x42432a: /usr/sbin/varnishd(VFP_Fetch_Body+0x2ba) [0x42432a] 0x421569: /usr/sbin/varnishd() [0x421569] 0x4376b3: /usr/sbin/varnishd(Pool_Work_Thread+0x373) [0x4376b3] 0x44a98d: /usr/sbin/varnishd() [0x44a98d] 0x7fa6735ebb50: /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7fa6735ebb50] 0x7fa6733357bd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fa6733357bd] busyobj = 0x7fa672b02020 { ws = 0x7fa672b020e0 { id = "bo", {s,f,r,e} = {0x7fa672b04008,+1920,(nil),+253976}, }, refcnt = 2 retries = 0 failed = 1 state = 1 is_do_esi is_do_gzip is_is_gunzip bodystatus = 3 (length), }, http[bereq] = { ws = 0x7fa672b020e0[bo] "GET", "/myuri", "HTTP/1.1", "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0", "Accept: image/png,image/*;q=0.8,*/*;q=0.5", "Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3", "Referer: http://myhost/myuri", "Host: myhost", "Surrogate-Capability: abc=ESI/1.0", "X-Forwarded-For: xxx, xxx", "X-Varnish: 852351", }, http[beresp] = { ws = 0x7fa672b020e0[bo] "HTTP/1.1", "301", "Moved Permanently", "Date: Thu, 27 Nov 2014 15:03:25 GMT", "Server: Apache", }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Nov 30 13:45:43 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 30 Nov 2014 13:45:43 -0000 Subject: [Varnish] #1638: 82b29b1 Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. Message-ID: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> #1638: 82b29b1 Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+------------------- Reporter: slink | Owner: Type: defect | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+------------------- Seen in production repeatedly since Nov 16 {{{ Nov 16 03:12:04 fw01 varnishd[24913]: Child (24914) Panic message: Assert error in vbf_stp_startfetch(), cache/cache_fetch.c line 248: Condition(bo->doclose == SC_NULL) not true. thread = (cache-worker) version = varnish-trunk revision 82b29b1 ident = Linux,3.10.0-123.9.2.el7.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4324b4: pan_ic+0xf4 0x422b95: vbf_fetch_thread+0x1d65 0x434ca8: Pool_Work_Thread+0x358 0x4476c2: WRK_Thread+0x102 0x433a3b: pool_thread+0x2b 0x7f31c2287df3: /lib64/libpthread.so.0(+0x7df3) [0x7f31c2287df3] 0x7f31c1fae01d: /lib64/libc.so.6(clone+0x6d) [0x7f31c1fae01d] busyobj = 0x7f30f01d0e50 { ws = 0x7f30f01d0f10 { id = "bo", {s,f,r,e} = {0x7f30f01d2db8,+800,(nil),+57488}, }, refcnt = 2 retries = 1 failed = 1 state = 1 is_do_pass is_uncacheable is_is_gzip }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Nov 30 13:46:09 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 30 Nov 2014 13:46:09 -0000 Subject: [Varnish] #1638: 82b29b1 Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.de3d615957f19ccc39cc04f1a6aa4977@varnish-cache.org> #1638: 82b29b1 Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------- Changes (by slink): * owner: => slink * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Nov 30 13:46:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 30 Nov 2014 13:46:29 -0000 Subject: [Varnish] #1638: 82b29b1 Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. In-Reply-To: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> References: <043.531de57203cb30d1d236fb877abf9455@varnish-cache.org> Message-ID: <058.54e7ae8d37e88a744b2268de53531b37@varnish-cache.org> #1638: 82b29b1 Assert error in vbf_stp_startfetch() : Condition(bo->doclose == SC_NULL) not true. ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------- Changes (by slink): * cc: nils.goroll@? (added) -- Ticket URL: Varnish The Varnish HTTP Accelerator