From varnish-bugs at varnish-cache.org Mon Oct 1 10:03:36 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Oct 2012 10:03:36 -0000 Subject: [Varnish] #1200: On systems with INET6 disabled, c00005.vtc test fails In-Reply-To: <040.e3d9367dba5ffa1540668a97afc0b35e@varnish-cache.org> References: <040.e3d9367dba5ffa1540668a97afc0b35e@varnish-cache.org> Message-ID: <055.1c84aec8e35917414d1108fe85ac9fdc@varnish-cache.org> #1200: On systems with INET6 disabled, c00005.vtc test fails -------------------------+---------------------- Reporter: mi | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: normal | Resolution: wontfix Keywords: | -------------------------+---------------------- Changes (by tfheen): * status: new => closed * resolution: => wontfix Comment: Yes, the test suite requires IPv6 to run. Please enable IPv6, it's part of today's internet. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 1 10:05:29 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Oct 2012 10:05:29 -0000 Subject: [Varnish] #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) In-Reply-To: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> References: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> Message-ID: <055.cdaf44f99f832e2a80f6ccbfbe3f35f2@varnish-cache.org> #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) -------------------------+-------------------- Reporter: mi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 1 10:07:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Oct 2012 10:07:53 -0000 Subject: [Varnish] #1199: c00045.vtc may fail intermittently depending on compiler and optimization In-Reply-To: <040.142f68a1a38937f0fa2e389fb4c02db6@varnish-cache.org> References: <040.142f68a1a38937f0fa2e389fb4c02db6@varnish-cache.org> Message-ID: <055.355804e5100dc66365495706931eac61@varnish-cache.org> #1199: c00045.vtc may fail intermittently depending on compiler and optimization -------------------------+-------------------- Reporter: mi | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: Keywords: | -------------------------+-------------------- Comment (by tfheen): Are your build machine a single-core machine? If so, can you see if making it a multi-core machine helps? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 1 10:09:49 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Oct 2012 10:09:49 -0000 Subject: [Varnish] #1198: Make check takes much longer after we started to sync the shmem file In-Reply-To: <044.9aa3d0a3e8fb7c21731fdfe1e38a61ff@varnish-cache.org> References: <044.9aa3d0a3e8fb7c21731fdfe1e38a61ff@varnish-cache.org> Message-ID: <059.a4caf2541b6b7ebae920ac5e503977de@varnish-cache.org> #1198: Make check takes much longer after we started to sync the shmem file --------------------+-------------------- Reporter: martin | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 1 16:05:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Oct 2012 16:05:16 -0000 Subject: [Varnish] #1200: On systems with INET6 disabled, c00005.vtc test fails In-Reply-To: <040.e3d9367dba5ffa1540668a97afc0b35e@varnish-cache.org> References: <040.e3d9367dba5ffa1540668a97afc0b35e@varnish-cache.org> Message-ID: <055.b609ba88c75fc3217234b4f4329cefee@varnish-cache.org> #1200: On systems with INET6 disabled, c00005.vtc test fails -------------------------+---------------------- Reporter: mi | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: normal | Resolution: wontfix Keywords: | -------------------------+---------------------- Comment (by mi): IPv6 is even less "part of today's Internet" than 64-bit servers, for example. Yet, the project -- rightfully -- makes an effort to properly work on 32-bit computers. A number of operating systems -- such as FreeBSD and various Linux distributions -- make IPv6-support optional, because supporting it adds non-trivial overhead, but remains just dead weight for millions of people. No consumer ISP (in the Northeastern United States, at least), for example, offer INET6 today, and it is not that common among hosting providers either. The problem is real and should not have been dismissed. With a fairly advanced scripting language such as VCL, it should not be hard to make the use of IPv6-style addresses optional -- depending on run- time detection... Being new to Varnish myself, I don't know, how to do this. But you, in all likelihood, can figure it out. Please, fix properly (r00832.vtc also needs the same change). Thank you! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 1 16:08:04 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Oct 2012 16:08:04 -0000 Subject: [Varnish] #1199: c00045.vtc may fail intermittently depending on compiler and optimization In-Reply-To: <040.142f68a1a38937f0fa2e389fb4c02db6@varnish-cache.org> References: <040.142f68a1a38937f0fa2e389fb4c02db6@varnish-cache.org> Message-ID: <055.8e830c06745fec832387be6de7f287d5@varnish-cache.org> #1199: c00045.vtc may fail intermittently depending on compiler and optimization -------------------------+-------------------- Reporter: mi | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: Keywords: | -------------------------+-------------------- Comment (by mi): The machine, where this bug manifested itself, is a RHEL-5.6 with 4 CPUs. The build itself was parallelized (-j4) and varnishtest itself was running with default parallelization of -j3 (from under `make check'). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 1 16:10:21 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Oct 2012 16:10:21 -0000 Subject: [Varnish] #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) In-Reply-To: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> References: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> Message-ID: <055.c8ecbc34f74600452279d23b9bafe861@varnish-cache.org> #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) -------------------------+-------------------- Reporter: mi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by mi): I can not reproduce this problem on a similarly-configured FreeBSD/amd64 machine: {{{ # top TEST ./tests/r01109.vtc passed (1.302) }}} I suspect, the bug is 32bit-specific... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 1 16:12:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Oct 2012 16:12:43 -0000 Subject: [Varnish] #1202: Test r01036.vtc warns of assertion-failure, but succeeds Message-ID: <040.6f79c78bd1b252d620cc7f7f25bb02b3@varnish-cache.org> #1202: Test r01036.vtc warns of assertion-failure, but succeeds -------------------+------------------------- Reporter: mi | Type: defect Status: new | Priority: low Milestone: | Component: varnishtest Version: 3.0.3 | Severity: minor Keywords: | -------------------+------------------------- Any time I run the test suit, I get the following warning: {{{ ######## ./tests/r01036.vtc ######## Assert error in vtc_log(), vtc_log.c line 140: Condition(lvl < NLEAD) not true. # top TEST ./tests/r01036.vtc passed (1.189) }}} The test succeeds, but the assertion failure is troubling (to an untrained mind). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 1 16:41:13 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Oct 2012 16:41:13 -0000 Subject: [Varnish] #1202: Test r01036.vtc warns of assertion-failure, but succeeds In-Reply-To: <040.6f79c78bd1b252d620cc7f7f25bb02b3@varnish-cache.org> References: <040.6f79c78bd1b252d620cc7f7f25bb02b3@varnish-cache.org> Message-ID: <055.1b41025dc43a1da182f5aab1d222c56a@varnish-cache.org> #1202: Test r01036.vtc warns of assertion-failure, but succeeds -------------------------+-------------------- Reporter: mi | Owner: Type: defect | Status: new Priority: low | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: Keywords: | -------------------------+-------------------- Comment (by mi): Ok, this one proved easy... NLEAD is a defined as an array-dimension (sizeof/sizeof), which makes it unsigned. lvl, on the other hand, is (signed) integer. When they compared, the int is interpreted to unsigned, evidently -- the problem strikes, when lvl is negative (such as -1). This patch fixes the assert: {{{ --- bin/varnishtest/vtc_log.c 2012-08-20 05:20:40.000000000 -0400 +++ bin/varnishtest/vtc_log.c 2012-10-01 12:35:45.000000000 -0400 @@ -138,5 +138,5 @@ AZ(pthread_mutex_lock(&vl->mtx)); vl->act = 1; - assert(lvl < NLEAD); + assert(lvl < (int)NLEAD); VSB_clear(vl->vsb); VSB_printf(vl->vsb, "%s %-4s %4.1f ", }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 3 12:06:26 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Oct 2012 12:06:26 -0000 Subject: [Varnish] #1203: Varnish loging problem? Message-ID: <050.1a2c6b32221040abbce9c7fc172c36be@varnish-cache.org> #1203: Varnish loging problem? --------------------------+-------------------- Reporter: muneeb nasir | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | --------------------------+-------------------- Hello. I have installed varnish with play framework. I found this command varnishlog -a -w /var/log/varnish.log but it didn't show ant thing. How can i configure log of varnish. ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 5 13:01:48 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 05 Oct 2012 13:01:48 -0000 Subject: [Varnish] #1204: INT in vmod should be 64 bit Message-ID: <044.a101ca4487a458f9c25ce3a55fe48af8@varnish-cache.org> #1204: INT in vmod should be 64 bit ----------------------+------------------- Reporter: tfheen | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- You might reasonably want to use std.integer to compare the Content-Length header with a known size, and objects can be over 2G big, so we should use a 64 bit number, rather than just an int for the INT vmod type. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Oct 6 10:11:02 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 06 Oct 2012 10:11:02 -0000 Subject: [Varnish] #1205: Excellent Advantage of Resume Helper Online Message-ID: <052.5fb77da81d19e4683f9a285e6a4df4ee@varnish-cache.org> #1205: Excellent Advantage of Resume Helper Online ----------------------------+-------------------- Reporter: RenatoBrickson | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | ----------------------------+-------------------- In some employment websites comparable to Monster.com, your online resume is searchable, and this indicates possible employers can have access to your resume when searching for those that fit openings in their business. [http://www.resumesplanet.com/resume_writing.php Help writing a resume] - this really is optional and also you can generally turn it off, which means that whilst your online resume continues to be becoming hosted in the website, random employers will not have the ability to browse your resume once they appear for possible workers. This might be an excellent advantage of resume helper online. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Oct 6 15:38:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 06 Oct 2012 15:38:45 -0000 Subject: [Varnish] #940: ETag for gzip'd variant identical to ETag of ungzipped variant. In-Reply-To: <043.d3f0122c5f2e8a8e1ed36783de6aff0a@varnish-cache.org> References: <043.d3f0122c5f2e8a8e1ed36783de6aff0a@varnish-cache.org> Message-ID: <058.76bde389e92e1819737386c18f10cd61@varnish-cache.org> #940: ETag for gzip'd variant identical to ETag of ungzipped variant. ----------------------+--------------------- Reporter: david | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 3.0.0 Severity: critical | Resolution: Keywords: | ----------------------+--------------------- Changes (by slink): * cc: nils.goroll@? (added) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Oct 6 15:47:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 06 Oct 2012 15:47:52 -0000 Subject: [Varnish] #940: ETag for gzip'd variant identical to ETag of ungzipped variant. In-Reply-To: <043.d3f0122c5f2e8a8e1ed36783de6aff0a@varnish-cache.org> References: <043.d3f0122c5f2e8a8e1ed36783de6aff0a@varnish-cache.org> Message-ID: <058.c2a8a2a22b05795053732d5d38edfd58@varnish-cache.org> #940: ETag for gzip'd variant identical to ETag of ungzipped variant. ----------------------+--------------------- Reporter: david | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 3.0.0 Severity: critical | Resolution: Keywords: | ----------------------+--------------------- Comment (by slink): want to document recommendations in the wiki: [wiki:ETags] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 8 10:13:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Oct 2012 10:13:00 -0000 Subject: [Varnish] #1202: Test r01036.vtc warns of assertion-failure, but succeeds In-Reply-To: <040.6f79c78bd1b252d620cc7f7f25bb02b3@varnish-cache.org> References: <040.6f79c78bd1b252d620cc7f7f25bb02b3@varnish-cache.org> Message-ID: <055.cf712a5481c316f870988cdf94e53db3@varnish-cache.org> #1202: Test r01036.vtc warns of assertion-failure, but succeeds -------------------------+-------------------- Reporter: mi | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: Keywords: | -------------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 8 10:13:05 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Oct 2012 10:13:05 -0000 Subject: [Varnish] #1203: Varnish loging problem? In-Reply-To: <050.1a2c6b32221040abbce9c7fc172c36be@varnish-cache.org> References: <050.1a2c6b32221040abbce9c7fc172c36be@varnish-cache.org> Message-ID: <065.7d2798a3eb2991de644b00342c26aa8e@varnish-cache.org> #1203: Varnish loging problem? --------------------------+---------------------- Reporter: muneeb nasir | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: invalid Keywords: | --------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: This bug tracker is for Varnish bugs only. Please contact the varnish-misc mailing list or ask for help on the #varnish IRC channel. Regards, Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 8 10:13:10 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Oct 2012 10:13:10 -0000 Subject: [Varnish] #1204: INT in vmod should be 64 bit In-Reply-To: <044.a101ca4487a458f9c25ce3a55fe48af8@varnish-cache.org> References: <044.a101ca4487a458f9c25ce3a55fe48af8@varnish-cache.org> Message-ID: <059.a2b1a5565190d82f090a21cf41f6156d@varnish-cache.org> #1204: INT in vmod should be 64 bit ----------------------+-------------------- Reporter: tfheen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 9 12:21:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Oct 2012 12:21:16 -0000 Subject: [Varnish] #1206: Pass shouldn't honor IMS/INM if the backend doesn't Message-ID: <045.056ef3b3c7a98c4fb026f4180bff25e1@varnish-cache.org> #1206: Pass shouldn't honor IMS/INM if the backend doesn't ---------------------+---------------------- Reporter: drwilco | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | ---------------------+---------------------- Right now if a backend replies with a 200, Varnish will apply If-Modified- Since and If-None-Match, even in pass-through mode. Patch will follow, snagging ticket number for testcase. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 9 22:11:42 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Oct 2012 22:11:42 -0000 Subject: [Varnish] #1207: varnishd child segfaults when using dns director Message-ID: <046.cbd6b84dea250737a025adc3c0105555@varnish-cache.org> #1207: varnishd child segfaults when using dns director --------------------------+---------------------- Reporter: econnell | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Keywords: dns director | --------------------------+---------------------- System Information: Ubuntu 12.04 amd64 Server on Amazon EC2 Varnish Package: 3.0.2-1ubuntu0.1 (also tried with Debian SID 3.0.2-2) Using the following very basic config, varnishd does not start properly: {{{ backend default { .host = "127.0.0.7"; .port = "8081"; } director blah dns { .list = { .host_header = "www.myhost.com"; .port = "80"; "72.246.30.10/32"; } .ttl = 5m; } sub vcl_recv { set req.backend = blah; } }}} When running varnish in debug mode, the following is output: {{{ /usr/sbin/varnishd -n / -d -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256mPlatform: Linux,3.2.0-30-virtual,x86_64,-smalloc,-smalloc,-hcritbit 200 244 ----------------------------- Varnish Cache CLI 1.0 ----------------------------- Linux,3.2.0-30-virtual,x86_64,-smalloc,-smalloc,-hcritbit Type 'help' for command list. Type 'quit' to close CLI session. Type 'start' to launch worker process. start child (9426) Started Pushing vcls failed: CLI communication error (hdr) Stopping Child 200 0 Child (9426) died signal=11 (core dumped) Child (-1) said Child starts Child cleanup complete }}} The backtrace is: {{{ Program terminated with signal 11, Segmentation fault. #0 VBE_UseHealth (vdi=0x0) at cache_backend.c:428 428 cache_backend.c: No such file or directory. (gdb) back #0 VBE_UseHealth (vdi=0x0) at cache_backend.c:428 #1 0x000000000043651c in ccf_config_use (cli=, av=, priv=) at cache_vcl.c:314 #2 0x00007f90c734b6f7 in cls_dispatch (ac=2, av=0x7f90c5c12400, clp=, cli=0x7f90c5c0e630) at cli_serve.c:228 #3 cls_vlu2 (priv=0x7f90c5c0e600, av=0x7f90c5c12400) at cli_serve.c:284 #4 0x00007f90c734bbf8 in cls_vlu (priv=0x7f90c5c0e600, p=) at cli_serve.c:339 #5 0x00007f90c734f84d in LineUpProcess (l=0x7f90c5c02940) at vlu.c:154 #6 0x00007f90c734ca7e in VCLS_Poll (cs=0x7f90c5c150b0, timeout=) at cli_serve.c:528 #7 0x000000000041a2a1 in CLI_Run () at cache_cli.c:113 #8 0x000000000042e6a8 in child_main () at cache_main.c:138 #9 0x0000000000441e97 in start_child (cli=0x7f90c5c0e4b0) at mgt_child.c:345 #10 start_child (cli=0x7f90c5c0e4b0) at mgt_child.c:271 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 07:54:20 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 07:54:20 -0000 Subject: [Varnish] #1204: INT in vmod should be 64 bit In-Reply-To: <044.a101ca4487a458f9c25ce3a55fe48af8@varnish-cache.org> References: <044.a101ca4487a458f9c25ce3a55fe48af8@varnish-cache.org> Message-ID: <059.a1f879683f754387e88ad40232ab4119@varnish-cache.org> #1204: INT in vmod should be 64 bit ----------------------+--------------------- Reporter: tfheen | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [935744727402361ee69133a84e880fff939ad2a4]) Change VCL::INT from C::int to C::long to gain more range on 64bit architectures. NB: VMOD writers need to review/revise use of the INT type. Fixes #1204 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 07:49:31 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 07:49:31 -0000 Subject: [Varnish] #1146: Persistent: When dropping empty segments, it will leak objects from LRU_Alloc, and not reset the free_offset to reclaim the space In-Reply-To: <044.1aadbdec81ec327f20ce81ac5a318c96@varnish-cache.org> References: <044.1aadbdec81ec327f20ce81ac5a318c96@varnish-cache.org> Message-ID: <059.8cd5b960126a49ea72dfb37809a2c8ef@varnish-cache.org> #1146: Persistent: When dropping empty segments, it will leak objects from LRU_Alloc, and not reset the free_offset to reclaim the space ----------------------+--------------------- Reporter: martin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: (In [c74c457414847d5a1a56894fd9797ce2e4d2e208]) Free the LRU object and set free_offset when dropping empty segments in smp_close_seg() Fixes: #1146 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 07:54:18 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 07:54:18 -0000 Subject: [Varnish] #1204: INT in vmod should be 64 bit In-Reply-To: <044.a101ca4487a458f9c25ce3a55fe48af8@varnish-cache.org> References: <044.a101ca4487a458f9c25ce3a55fe48af8@varnish-cache.org> Message-ID: <059.9a8c3a2bc110960a056c8ea5e5093a54@varnish-cache.org> #1204: INT in vmod should be 64 bit ----------------------+-------------------- Reporter: tfheen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Poul-Henning Kamp ): In [935744727402361ee69133a84e880fff939ad2a4]: {{{ #!CommitTicketReference repository="" revision="935744727402361ee69133a84e880fff939ad2a4" Change VCL::INT from C::int to C::long to gain more range on 64bit architectures. NB: VMOD writers need to review/revise use of the INT type. Fixes #1204 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 07:49:21 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 07:49:21 -0000 Subject: [Varnish] #1146: Persistent: When dropping empty segments, it will leak objects from LRU_Alloc, and not reset the free_offset to reclaim the space In-Reply-To: <044.1aadbdec81ec327f20ce81ac5a318c96@varnish-cache.org> References: <044.1aadbdec81ec327f20ce81ac5a318c96@varnish-cache.org> Message-ID: <059.7a1bedb9ffbc6e589641fcf941d60a9a@varnish-cache.org> #1146: Persistent: When dropping empty segments, it will leak objects from LRU_Alloc, and not reset the free_offset to reclaim the space ----------------------+-------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Martin Blix Grydeland ): In [c74c457414847d5a1a56894fd9797ce2e4d2e208]: {{{ #!CommitTicketReference repository="" revision="c74c457414847d5a1a56894fd9797ce2e4d2e208" Free the LRU object and set free_offset when dropping empty segments in smp_close_seg() Fixes: #1146 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 08:19:36 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 08:19:36 -0000 Subject: [Varnish] #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) In-Reply-To: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> References: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> Message-ID: <055.18468fa0b6e36741242137fbb53b4dd0@varnish-cache.org> #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) -------------------------+-------------------- Reporter: mi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by phk): I cannot reproduce on my 32bit FreeBSD with Varnish-trunk. I think the problem is that it runs out of thread-stack, can you try something like this: {{{ diff --git a/bin/varnishtest/tests/r01109.vtc b/bin/varnishtest/tests/r01109.vtc index 50f0a0e..e6b43e8 100644 --- a/bin/varnishtest/tests/r01109.vtc +++ b/bin/varnishtest/tests/r01109.vtc @@ -21,7 +21,7 @@ server s1 { txresp -bodylen 4074 } -start -varnish v1 -arg "-pfetch_chunksize=4k" -arg "-pgzip_level=0" -vcl+backend { +varnish v1 -arg "-pfetch_chunksize=4k" -arg "-pgzip_level=0" -arg "-pthread_pool_stack=131072" -vcl+backend { sub vcl_fetch { if (req.url ~ "/test") { set beresp.do_esi = true; }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 08:46:56 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 08:46:56 -0000 Subject: [Varnish] #1208: CLANG does not like -g in link commands Message-ID: <041.cade3d35733de2a5964fe9739e909f60@varnish-cache.org> #1208: CLANG does not like -g in link commands --------------------+------------------- Reporter: phk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Keywords: --------------------+------------------- {{{ clang: error: argument unused during compilation: '-g' }}} This is an auto* issue I pressume. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 08:47:49 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 08:47:49 -0000 Subject: [Varnish] #1208: CLANG does not like -g in link commands In-Reply-To: <041.cade3d35733de2a5964fe9739e909f60@varnish-cache.org> References: <041.cade3d35733de2a5964fe9739e909f60@varnish-cache.org> Message-ID: <056.08d0455d2167b8a66d8bb9e8dcdd3e78@varnish-cache.org> #1208: CLANG does not like -g in link commands --------------------+--------------------- Reporter: phk | Owner: tollef Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: Keywords: | --------------------+--------------------- Changes (by phk): * owner: => tollef -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 13:08:27 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 13:08:27 -0000 Subject: [Varnish] #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) In-Reply-To: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> References: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> Message-ID: <055.facca145ed7827f73b002b462c5a9d1a@varnish-cache.org> #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) -------------------------+-------------------- Reporter: mi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by mi): Yes, the explicit stack-size helped. Thank you, I'll work on adding the above to FreeBSD port www/varnish. Is this a valid fix, however, or a work-around? Should varnish's default be higher on 32-bit systems? Also, should not varnish react in a more civilized manner in such cases? BTW, are tests dependent on each other in any way? In other words, does the sequence matter? I'm running with TESTS_PARALLELISM=-j8 (I have 8 CPU- cores here) and just had a sudden failure of c00022.vtc, which ''went away simply upon rerunning'': {{{ ######## ./tests/c00022.vtc ######## Assert error in VSL_Open_CallBack(), vsl.c line 366: Condition(sha != NULL) not true. ######## ./tests/c00022.vtc ######## errno = 2 (No such file or directory) **** top 0.0 macro def varnishd=../varnishd/varnishd **** top 0.0 macro def pwd=/mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest **** top 0.0 macro def topbuild=/mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest/../.. **** top 0.0 macro def bad_ip=10.255.255.255 **** top 0.0 macro def tmpdir=/tmp/vtc.54579.21dd1466 * top 0.0 TEST ./tests/c00022.vtc starting *** top 0.0 varnishtest * top 0.0 TEST Test banning a url with VCL ban *** top 0.0 server ** s1 0.0 Starting server **** s1 0.0 macro def s1_addr=127.0.0.1 **** s1 0.0 macro def s1_port=64893 **** s1 0.0 macro def s1_sock=127.0.0.1 64893 * s1 0.0 Listen on 127.0.0.1 64893 *** top 0.0 varnish ** s1 0.0 Started on 127.0.0.1 64893 ** v1 0.1 Launch *** v1 0.1 CMD: cd ${pwd} && ${varnishd} -d -d -n /tmp/vtc.54579.21dd1466/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.54579.21dd1466/v1/_S -M '127.0.0.1 64896' -P /tmp/vtc.54579.21dd1466/v1/varnishd.pid -sfile,/tmp/vtc.54579.21dd1466/v1,10M *** v1 0.1 CMD: cd /mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest && ../varnishd/varnishd -d -d -n /tmp/vtc.54579.21dd1466/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.54579.21dd1466/v1/_S -M '127.0.0.1 64896' -P /tmp/vtc.54579.21dd1466/v1/varnishd.pid -sfile,/tmp/vtc.54579.21dd1466/v1,10M *** v1 0.2 PID: 56127 *** v1 1.0 debug| Platform: FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n *** v1 1.0 debug| 200 236 \n *** v1 1.0 debug| -----------------------------\n *** v1 1.0 debug| Varnish Cache CLI 1.0\n *** v1 1.0 debug| -----------------------------\n *** v1 1.0 debug| FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n *** v1 1.0 debug| \n *** v1 1.0 debug| Type 'help' for command list.\n *** v1 1.0 debug| Type 'quit' to close CLI session.\n *** v1 1.0 debug| Type 'start' to launch worker process.\n *** v1 1.0 debug| \n # top TEST ./tests/c00022.vtc FAILED (1.000) signal=6 exit=0 }}} I would've filed a separate bug-report, but I can not easily reproduce the above. If -j8 is too aggressive, I'll go back to the default -j3. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 15:17:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 15:17:45 -0000 Subject: [Varnish] #1209: Intermittent failure of tests/v00017.vtc Message-ID: <040.6dddeed43b6ad4d733da8ea80d4a9c4d@varnish-cache.org> #1209: Intermittent failure of tests/v00017.vtc -------------------+------------------------- Reporter: mi | Type: defect Status: new | Priority: low Milestone: | Component: varnishtest Version: 3.0.3 | Severity: minor Keywords: | -------------------+------------------------- Although I've run `make check' on this host dozens of times by now -- investigating other test-failures (and fixes), I have not seen this one fail before. Why is the test only failing ''occasionally''? {{{ **** top 0.0 macro def varnishd=../varnishd/varnishd **** top 0.0 macro def pwd=/mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest **** top 0.0 macro def topbuild=/mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest/../.. **** top 0.0 macro def bad_ip=10.255.255.255 **** top 0.0 macro def tmpdir=/tmp/vtc.95304.0fef08a6 * top 0.0 TEST ./tests/v00017.vtc starting *** top 0.0 varnishtest * top 0.0 TEST VCL compiler coverage test: vcc_acl.c *** top 0.0 varnish ** v1 0.1 Launch *** v1 0.1 CMD: cd ${pwd} && ${varnishd} -d -d -n /tmp/vtc.95304.0fef08a6/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.95304.0fef08a6/v1/_S -M '127.0.0.1 56324' -P /tmp/vtc.95304.0fef08a6/v1/varnishd.pid -sfile,/tmp/vtc.95304.0fef08a6/v1,10M *** v1 0.1 CMD: cd /mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest && ../varnishd/varnishd -d -d -n /tmp/vtc.95304.0fef08a6/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.95304.0fef08a6/v1/_S -M '127.0.0.1 56324' -P /tmp/vtc.95304.0fef08a6/v1/varnishd.pid -sfile,/tmp/vtc.95304.0fef08a6/v1,10M *** v1 0.1 PID: 2446 *** v1 0.3 debug| Platform: FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n *** v1 0.3 debug| 200 236 \n *** v1 0.3 debug| -----------------------------\n *** v1 0.3 debug| Varnish Cache CLI 1.0\n *** v1 0.3 debug| -----------------------------\n *** v1 0.3 debug| FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n *** v1 0.3 debug| \n *** v1 0.3 debug| Type 'help' for command list.\n *** v1 0.3 debug| Type 'quit' to close CLI session.\n *** v1 0.3 debug| Type 'start' to launch worker process.\n *** v1 0.3 debug| \n **** v1 0.4 CLIPOLL 1 0x1 0x0 *** v1 0.4 CLI connection fd = 7 *** v1 0.4 CLI RX 107 **** v1 0.4 CLI RX| ysjyzfatmhgkkcxnbwnmbevdmcunqhgq\n **** v1 0.4 CLI RX| \n **** v1 0.4 CLI RX| Authentication required.\n **** v1 0.5 CLI TX| auth d996b7a0779290b12e335137cee54c549fa727d306522534e759b3fd87cfc0bb\n *** v1 0.5 CLI RX 200 **** v1 0.5 CLI RX| -----------------------------\n **** v1 0.5 CLI RX| Varnish Cache CLI 1.0\n **** v1 0.5 CLI RX| -----------------------------\n **** v1 0.5 CLI RX| FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n **** v1 0.5 CLI RX| \n **** v1 0.5 CLI RX| Type 'help' for command list.\n **** v1 0.5 CLI RX| Type 'quit' to close CLI session.\n **** v1 0.5 CLI RX| Type 'start' to launch worker process.\n **** v1 0.5 CLI TX| vcl.inline vcl1 << %XJEIFLH|)Xspa8P\n **** v1 0.5 CLI TX| \n **** v1 0.5 CLI TX| \tbackend b { .host = "127.0.0.1"; }\n **** v1 0.5 CLI TX| \tacl a { "10.1.2.3"/33; }\n **** v1 0.5 CLI TX| \tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n **** v1 0.5 CLI TX| \n **** v1 0.5 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 0.6 CLI RX 106 **** v1 0.6 CLI RX| Message from VCC-compiler:\n **** v1 0.6 CLI RX| Too wide mask (33) for IPv4 address('input' Line 3 Pos 28)\n **** v1 0.6 CLI RX| acl a { "10.1.2.3"/33; }\n **** v1 0.6 CLI RX| ---------------------------##---\n **** v1 0.6 CLI RX| \n **** v1 0.6 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 0.6 CLI RX| \n **** v1 0.6 CLI RX| VCL compilation failed ** v1 0.6 VCL compilation failed (as expected) *** top 0.6 varnish **** v1 0.6 CLI TX| vcl.inline vcl2 << %XJEIFLH|)Xspa8P\n **** v1 0.6 CLI TX| \n **** v1 0.6 CLI TX| \tbackend b { .host = "127.0.0.1"; }\n **** v1 0.6 CLI TX| \tacl a { "1::2"/129; }\n **** v1 0.6 CLI TX| \tsub vcl_recv { if (client.ip ~ a) { return(pass); } }\n **** v1 0.6 CLI TX| \n **** v1 0.6 CLI TX| %XJEIFLH|)Xspa8P\n ---- v1 20.6 CLI failed (vcl.inline vcl2 << %XJEIFLH|)Xspa8P backend b { .host = "127.0.0.1"; } acl a { "1::2"/129; } sub vcl_recv { if (client.ip ~ a) { return(pass); } } %XJEIFLH|)Xspa8P ) = -1 400 CLI communication error (hdr) ---- v1 20.6 VCL compilation got 400 expected 106 * top 20.6 RESETTING after ./tests/v00017.vtc ** v1 21.6 Wait ** v1 21.7 R 2446 Status: 0000 * top 21.7 TEST ./tests/v00017.vtc FAILED # top TEST ./tests/v00017.vtc FAILED (21.703) exit=1 }}} Perhaps, the tests should all run under valgrind, when the utility is available? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 15:42:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 15:42:45 -0000 Subject: [Varnish] #1210: Intermittent failure of tests/v00002.vtc Message-ID: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> #1210: Intermittent failure of tests/v00002.vtc -------------------+------------------------- Reporter: mi | Type: defect Status: new | Priority: low Milestone: | Component: varnishtest Version: 3.0.3 | Severity: minor Keywords: | -------------------+------------------------- Similarly to the problem described in ticket 1209, this one is intermittent and related to a test meant to check Varnish's reaction to invalid configuration ({{{backend b1 { .host = "////.";}}}}): {{{ **** top 0.0 macro def varnishd=../varnishd/varnishd **** top 0.0 macro def pwd=/mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest **** top 0.0 macro def topbuild=/mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest/../.. **** top 0.0 macro def bad_ip=10.255.255.255 **** top 0.0 macro def tmpdir=/tmp/vtc.3747.3f67dcd5 * top 0.1 TEST ./tests/v00002.vtc starting *** top 0.1 varnishtest * top 0.1 TEST VCL: test syntax/semantic checks on backend decls. (vcc_backend.c) *** top 0.1 varnish ** v1 0.5 Launch *** v1 0.5 CMD: cd ${pwd} && ${varnishd} -d -d -n /tmp/vtc.3747.3f67dcd5/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.3747.3f67dcd5/v1/_S -M '127.0.0.1 30130' -P /tmp/vtc.3747.3f67dcd5/v1/varnishd.pid -sfile,/tmp/vtc.3747.3f67dcd5/v1,10M *** v1 0.5 CMD: cd /mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest && ../varnishd/varnishd -d -d -n /tmp/vtc.3747.3f67dcd5/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.3747.3f67dcd5/v1/_S -M '127.0.0.1 30130' -P /tmp/vtc.3747.3f67dcd5/v1/varnishd.pid -sfile,/tmp/vtc.3747.3f67dcd5/v1,10M *** v1 0.5 PID: 10222 *** v1 3.2 debug| Platform: FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n *** v1 3.2 debug| 200 236 \n *** v1 3.2 debug| -----------------------------\n *** v1 3.2 debug| Varnish Cache CLI 1.0\n *** v1 3.2 debug| -----------------------------\n *** v1 3.2 debug| FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n *** v1 3.2 debug| \n *** v1 3.2 debug| Type 'help' for command list.\n *** v1 3.2 debug| Type 'quit' to close CLI session.\n *** v1 3.2 debug| Type 'start' to launch worker process.\n *** v1 3.2 debug| \n **** v1 3.3 CLIPOLL 1 0x1 0x0 *** v1 3.3 CLI connection fd = 7 *** v1 3.3 CLI RX 107 **** v1 3.3 CLI RX| yvlduqvayixuidewjdlzpezloutftlns\n **** v1 3.3 CLI RX| \n **** v1 3.3 CLI RX| Authentication required.\n **** v1 3.3 CLI TX| auth 1b03bd05670d04e404463e22b3c355f4ad48250c3482975d02167d36c45c25a8\n *** v1 3.3 CLI RX 200 **** v1 3.3 CLI RX| -----------------------------\n **** v1 3.3 CLI RX| Varnish Cache CLI 1.0\n **** v1 3.3 CLI RX| -----------------------------\n **** v1 3.3 CLI RX| FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n **** v1 3.3 CLI RX| \n **** v1 3.3 CLI RX| Type 'help' for command list.\n **** v1 3.3 CLI RX| Type 'quit' to close CLI session.\n **** v1 3.3 CLI RX| Type 'start' to launch worker process.\n **** v1 3.3 CLI TX| vcl.inline vcl1 << %XJEIFLH|)Xspa8P\n **** v1 3.3 CLI TX| \n **** v1 3.3 CLI TX| \n **** v1 3.3 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 3.4 CLI RX 106 **** v1 3.4 CLI RX| Message from VCC-compiler:\n **** v1 3.4 CLI RX| No backends or directors found in VCL program, at least one is necessary.\n **** v1 3.4 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 3.4 CLI RX| \n **** v1 3.4 CLI RX| VCL compilation failed ** v1 3.4 VCL compilation failed (as expected) *** top 3.4 varnish **** v1 3.4 CLI TX| vcl.inline vcl2 << %XJEIFLH|)Xspa8P\n **** v1 3.4 CLI TX| \n **** v1 3.4 CLI TX| \tbackend b1 {\n **** v1 3.4 CLI TX| \t\t.host = "127.0.0.1";\n **** v1 3.4 CLI TX| \t}\n **** v1 3.4 CLI TX| \tsub vcl_recv {\n **** v1 3.4 CLI TX| \t\tset req.backend = b2;\n **** v1 3.4 CLI TX| \t}\n **** v1 3.4 CLI TX| \n **** v1 3.4 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 3.4 CLI RX 106 **** v1 3.4 CLI RX| Message from VCC-compiler:\n **** v1 3.4 CLI RX| Symbol not found: 'b2' (expected type BACKEND):\n **** v1 3.4 CLI RX| ('input' Line 6 Pos 35)\n **** v1 3.4 CLI RX| set req.backend = b2;\n **** v1 3.4 CLI RX| ----------------------------------##-\n **** v1 3.4 CLI RX| \n **** v1 3.4 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 3.4 CLI RX| \n **** v1 3.4 CLI RX| VCL compilation failed ** v1 3.4 VCL compilation failed (as expected) *** top 3.4 varnish **** v1 3.4 CLI TX| vcl.inline vcl3 << %XJEIFLH|)Xspa8P\n **** v1 3.4 CLI TX| \n **** v1 3.4 CLI TX| \tbackend b1 {\n **** v1 3.4 CLI TX| \t\t.port = "http";\n **** v1 3.4 CLI TX| \t}\n **** v1 3.4 CLI TX| \n **** v1 3.4 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 3.5 CLI RX 106 **** v1 3.5 CLI RX| Message from VCC-compiler:\n **** v1 3.5 CLI RX| Mandatory field 'host' missing.\n **** v1 3.5 CLI RX| \n **** v1 3.5 CLI RX| In backend specification starting at:\n **** v1 3.5 CLI RX| ('input' Line 2 Pos 9)\n **** v1 3.5 CLI RX| backend b1 {\n **** v1 3.5 CLI RX| --------#######-----\n **** v1 3.5 CLI RX| \n **** v1 3.5 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 3.5 CLI RX| \n **** v1 3.5 CLI RX| VCL compilation failed ** v1 3.5 VCL compilation failed (as expected) *** top 3.5 varnish **** v1 3.5 CLI TX| vcl.inline vcl4 << %XJEIFLH|)Xspa8P\n **** v1 3.5 CLI TX| \n **** v1 3.5 CLI TX| \tbackend b1 {\n **** v1 3.5 CLI TX| \t\t.host = "foo";\n **** v1 3.5 CLI TX| \t\t.host = "bar";\n **** v1 3.5 CLI TX| \t}\n **** v1 3.5 CLI TX| \n **** v1 3.5 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 3.6 CLI RX 106 **** v1 3.6 CLI RX| Message from VCC-compiler:\n **** v1 3.6 CLI RX| Field 'host' redefined at:\n **** v1 3.6 CLI RX| ('input' Line 4 Pos 18)\n **** v1 3.6 CLI RX| .host = "bar";\n **** v1 3.6 CLI RX| -----------------####---------\n **** v1 3.6 CLI RX| \n **** v1 3.6 CLI RX| \n **** v1 3.6 CLI RX| First defined at:\n **** v1 3.6 CLI RX| ('input' Line 3 Pos 18)\n **** v1 3.6 CLI RX| .host = "foo";\n **** v1 3.6 CLI RX| -----------------####---------\n **** v1 3.6 CLI RX| \n **** v1 3.6 CLI RX| \n **** v1 3.6 CLI RX| In backend specification starting at:\n **** v1 3.6 CLI RX| ('input' Line 2 Pos 9)\n **** v1 3.6 CLI RX| backend b1 {\n **** v1 3.6 CLI RX| --------#######-----\n **** v1 3.6 CLI RX| \n **** v1 3.6 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 3.6 CLI RX| \n **** v1 3.6 CLI RX| VCL compilation failed ** v1 3.6 VCL compilation failed (as expected) *** top 3.6 varnish **** v1 3.6 CLI TX| vcl.inline vcl5 << %XJEIFLH|)Xspa8P\n **** v1 3.6 CLI TX| \n **** v1 3.6 CLI TX| \tbackend b1 {\n **** v1 3.6 CLI TX| \t\t.host = "foo";\n **** v1 3.6 CLI TX| \t\t.port = "http";\n **** v1 3.6 CLI TX| \t\t.port = "https";\n **** v1 3.6 CLI TX| \t}\n **** v1 3.6 CLI TX| \n **** v1 3.6 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 3.7 CLI RX 106 **** v1 3.7 CLI RX| Message from VCC-compiler:\n **** v1 3.7 CLI RX| Field 'port' redefined at:\n **** v1 3.7 CLI RX| ('input' Line 5 Pos 18)\n **** v1 3.7 CLI RX| .port = "https";\n **** v1 3.7 CLI RX| -----------------####-----------\n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| First defined at:\n **** v1 3.7 CLI RX| ('input' Line 4 Pos 18)\n **** v1 3.7 CLI RX| .port = "http";\n **** v1 3.7 CLI RX| -----------------####----------\n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| In backend specification starting at:\n **** v1 3.7 CLI RX| ('input' Line 2 Pos 9)\n **** v1 3.7 CLI RX| backend b1 {\n **** v1 3.7 CLI RX| --------#######-----\n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| VCL compilation failed ** v1 3.7 VCL compilation failed (as expected) *** top 3.7 varnish **** v1 3.7 CLI TX| vcl.inline vcl6 << %XJEIFLH|)Xspa8P\n **** v1 3.7 CLI TX| \n **** v1 3.7 CLI TX| \tbackend b1 {\n **** v1 3.7 CLI TX| \t\t.host = "foo";\n **** v1 3.7 CLI TX| \t\t.connect_timeout = 1m;\n **** v1 3.7 CLI TX| \t\t.connect_timeout = 1m;\n **** v1 3.7 CLI TX| \t}\n **** v1 3.7 CLI TX| \n **** v1 3.7 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 3.7 CLI RX 106 **** v1 3.7 CLI RX| Message from VCC-compiler:\n **** v1 3.7 CLI RX| Field 'connect_timeout' redefined at:\n **** v1 3.7 CLI RX| ('input' Line 5 Pos 18)\n **** v1 3.7 CLI RX| .connect_timeout = 1m;\n **** v1 3.7 CLI RX| -----------------###############------\n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| First defined at:\n **** v1 3.7 CLI RX| ('input' Line 4 Pos 18)\n **** v1 3.7 CLI RX| .connect_timeout = 1m;\n **** v1 3.7 CLI RX| -----------------###############------\n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| In backend specification starting at:\n **** v1 3.7 CLI RX| ('input' Line 2 Pos 9)\n **** v1 3.7 CLI RX| backend b1 {\n **** v1 3.7 CLI RX| --------#######-----\n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 3.7 CLI RX| \n **** v1 3.7 CLI RX| VCL compilation failed ** v1 3.7 VCL compilation failed (as expected) *** top 3.7 varnish **** v1 3.7 CLI TX| vcl.inline vcl7 << %XJEIFLH|)Xspa8P\n **** v1 3.7 CLI TX| \n **** v1 3.7 CLI TX| \tbackend b1 {\n **** v1 3.7 CLI TX| \t\t.host = "127.0.0.1";\n **** v1 3.7 CLI TX| \t\t.foobar = 123;\n **** v1 3.7 CLI TX| \t}\n **** v1 3.7 CLI TX| \n **** v1 3.7 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 3.8 CLI RX 106 **** v1 3.8 CLI RX| Message from VCC-compiler:\n **** v1 3.8 CLI RX| Unknown field: 'foobar' at\n **** v1 3.8 CLI RX| ('input' Line 4 Pos 18)\n **** v1 3.8 CLI RX| .foobar = 123;\n **** v1 3.8 CLI RX| -----------------######-------\n **** v1 3.8 CLI RX| \n **** v1 3.8 CLI RX| \n **** v1 3.8 CLI RX| In backend specification starting at:\n **** v1 3.8 CLI RX| ('input' Line 2 Pos 9)\n **** v1 3.8 CLI RX| backend b1 {\n **** v1 3.8 CLI RX| --------#######-----\n **** v1 3.8 CLI RX| \n **** v1 3.8 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 3.8 CLI RX| \n **** v1 3.8 CLI RX| VCL compilation failed ** v1 3.8 VCL compilation failed (as expected) *** top 3.8 varnish **** v1 3.8 CLI TX| vcl.inline vcl8 << %XJEIFLH|)Xspa8P\n **** v1 3.8 CLI TX| \n **** v1 3.8 CLI TX| \tbackend b1 { .host = "10.255.255.255"; }\n **** v1 3.8 CLI TX| \tdirector r1 random {\n **** v1 3.8 CLI TX| \t\t{ .weight = 1; .backend = b1; }\n **** v1 3.8 CLI TX| \t\t{ .weight = 1; .backend = { .host = "127.0.0.3"; } }\n **** v1 3.8 CLI TX| \t\t{ .weight = 1; .backend = 3745; } // Brownie points for getting the joke\n **** v1 3.8 CLI TX| \t}\n **** v1 3.8 CLI TX| \n **** v1 3.8 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 3.8 CLI RX 106 **** v1 3.8 CLI RX| Message from VCC-compiler:\n **** v1 3.8 CLI RX| Expected a backend host specification here, either by name or by {...}\n **** v1 3.8 CLI RX| '3745' at\n **** v1 3.8 CLI RX| ('input' Line 6 Pos 43)\n **** v1 3.8 CLI RX| { .weight = 1; .backend = 3745; } // Brownie points for getting the joke\n **** v1 3.8 CLI RX| ------------------------------------------####-------------------------------------------\n **** v1 3.8 CLI RX| \n **** v1 3.8 CLI RX| \n **** v1 3.8 CLI RX| In director specification starting at:\n **** v1 3.8 CLI RX| ('input' Line 3 Pos 9)\n **** v1 3.8 CLI RX| director r1 random {\n **** v1 3.8 CLI RX| --------########------------\n **** v1 3.8 CLI RX| \n **** v1 3.8 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 3.8 CLI RX| \n **** v1 3.8 CLI RX| VCL compilation failed ** v1 3.8 VCL compilation failed (as expected) *** top 3.8 varnish **** v1 3.8 CLI TX| vcl.inline vcl9 << %XJEIFLH|)Xspa8P\n **** v1 3.8 CLI TX| \n **** v1 3.8 CLI TX| \tbackend b1 { .host = "10.255.255.255"; }\n **** v1 3.8 CLI TX| \tbackend b2 b1;\n **** v1 3.8 CLI TX| \n **** v1 3.8 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 4.0 CLI RX 106 **** v1 4.0 CLI RX| Message from VCC-compiler:\n **** v1 4.0 CLI RX| Expected '{' got 'b1'\n **** v1 4.0 CLI RX| (program line 430), at\n **** v1 4.0 CLI RX| ('input' Line 3 Pos 20)\n **** v1 4.0 CLI RX| backend b2 b1;\n **** v1 4.0 CLI RX| -------------------##-\n **** v1 4.0 CLI RX| \n **** v1 4.0 CLI RX| \n **** v1 4.0 CLI RX| In backend specification starting at:\n **** v1 4.0 CLI RX| ('input' Line 3 Pos 9)\n **** v1 4.0 CLI RX| backend b2 b1;\n **** v1 4.0 CLI RX| --------#######-------\n **** v1 4.0 CLI RX| \n **** v1 4.0 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 4.0 CLI RX| \n **** v1 4.0 CLI RX| VCL compilation failed ** v1 4.0 VCL compilation failed (as expected) *** top 4.0 varnish **** v1 4.0 CLI TX| vcl.inline vcl10 << %XJEIFLH|)Xspa8P\n **** v1 4.0 CLI TX| \n **** v1 4.0 CLI TX| \tbackend b-1 { .host = "10.255.255.255"; }\n **** v1 4.0 CLI TX| \n **** v1 4.0 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 4.1 CLI RX 106 **** v1 4.1 CLI RX| Message from VCC-compiler:\n **** v1 4.1 CLI RX| Identifier 'b-1' contains illegal characters, use [0-9a-zA-Z_] only.\n **** v1 4.1 CLI RX| ('input' Line 2 Pos 17)\n **** v1 4.1 CLI RX| backend b-1 { .host = "10.255.255.255"; }\n **** v1 4.1 CLI RX| ----------------###------------------------------\n **** v1 4.1 CLI RX| \n **** v1 4.1 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 4.1 CLI RX| \n **** v1 4.1 CLI RX| VCL compilation failed ** v1 4.1 VCL compilation failed (as expected) *** top 4.1 varnish **** v1 4.1 CLI TX| vcl.inline vcl11 << %XJEIFLH|)Xspa8P\n **** v1 4.1 CLI TX| \n **** v1 4.1 CLI TX| \tbackend b1 { .host = "10.255.255.255"; }\n **** v1 4.1 CLI TX| \tsub vcl_recv {\n **** v1 4.1 CLI TX| \t\tset req.backend = b-1;\n **** v1 4.1 CLI TX| \t}\n **** v1 4.1 CLI TX| \n **** v1 4.1 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 4.1 CLI RX 106 **** v1 4.1 CLI RX| Message from VCC-compiler:\n **** v1 4.1 CLI RX| Symbol not found: 'b-1' (expected type BACKEND):\n **** v1 4.1 CLI RX| ('input' Line 4 Pos 35)\n **** v1 4.1 CLI RX| set req.backend = b-1;\n **** v1 4.1 CLI RX| ----------------------------------###-\n **** v1 4.1 CLI RX| \n **** v1 4.1 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 4.1 CLI RX| \n **** v1 4.1 CLI RX| VCL compilation failed ** v1 4.1 VCL compilation failed (as expected) *** top 4.1 varnish **** v1 4.1 CLI TX| vcl.inline vcl12 << %XJEIFLH|)Xspa8P\n **** v1 4.1 CLI TX| \n **** v1 4.1 CLI TX| \tbackend b1 {\n **** v1 4.1 CLI TX| \t\tset host = "127.0.0.1";\n **** v1 4.1 CLI TX| \t}\n **** v1 4.1 CLI TX| \n **** v1 4.1 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 4.3 CLI RX 106 **** v1 4.3 CLI RX| Message from VCC-compiler:\n **** v1 4.3 CLI RX| NB: Backend Syntax has changed:\n **** v1 4.3 CLI RX| Remove "set" and "backend" in front of backend fields.\n **** v1 4.3 CLI RX| 'set' at ('input' Line 3 Pos 17)\n **** v1 4.3 CLI RX| set host = "127.0.0.1";\n **** v1 4.3 CLI RX| ----------------###--------------------\n **** v1 4.3 CLI RX| \n **** v1 4.3 CLI RX| \n **** v1 4.3 CLI RX| In backend specification starting at:\n **** v1 4.3 CLI RX| ('input' Line 2 Pos 9)\n **** v1 4.3 CLI RX| backend b1 {\n **** v1 4.3 CLI RX| --------#######-----\n **** v1 4.3 CLI RX| \n **** v1 4.3 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 4.3 CLI RX| \n **** v1 4.3 CLI RX| VCL compilation failed ** v1 4.3 VCL compilation failed (as expected) *** top 4.3 varnish **** v1 4.3 CLI TX| vcl.inline vcl13 << %XJEIFLH|)Xspa8P\n **** v1 4.3 CLI TX| \n **** v1 4.3 CLI TX| \tbackend b1 {\n **** v1 4.3 CLI TX| \t\t.host = k"foo";\n **** v1 4.3 CLI TX| \t\t.connect_timeout = 1 q;\n **** v1 4.3 CLI TX| \t}\n **** v1 4.3 CLI TX| \n **** v1 4.3 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 4.3 CLI RX 106 **** v1 4.3 CLI RX| Message from VCC-compiler:\n **** v1 4.3 CLI RX| Expected CSTR got 'k'\n **** v1 4.3 CLI RX| (program line 461), at\n **** v1 4.3 CLI RX| ('input' Line 3 Pos 25)\n **** v1 4.3 CLI RX| .host = k"foo";\n **** v1 4.3 CLI RX| ------------------------#------\n **** v1 4.3 CLI RX| \n **** v1 4.3 CLI RX| \n **** v1 4.3 CLI RX| In backend specification starting at:\n **** v1 4.3 CLI RX| ('input' Line 2 Pos 9)\n **** v1 4.3 CLI RX| backend b1 {\n **** v1 4.3 CLI RX| --------#######-----\n **** v1 4.3 CLI RX| \n **** v1 4.3 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 4.3 CLI RX| \n **** v1 4.3 CLI RX| VCL compilation failed ** v1 4.3 VCL compilation failed (as expected) *** top 4.3 varnish **** v1 4.3 CLI TX| vcl.inline vcl14 << %XJEIFLH|)Xspa8P\n **** v1 4.3 CLI TX| \n **** v1 4.3 CLI TX| \tbackend b1 { .host = "127.0.0.1"; }\n **** v1 4.3 CLI TX| \tbackend b1 { .host = "127.0.0.1"; }\n **** v1 4.3 CLI TX| \n **** v1 4.3 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 4.4 CLI RX 106 **** v1 4.4 CLI RX| Message from VCC-compiler:\n **** v1 4.4 CLI RX| Backend { redefined\n **** v1 4.4 CLI RX| ('input' Line 3 Pos 17)\n **** v1 4.4 CLI RX| backend b1 { .host = "127.0.0.1"; }\n **** v1 4.4 CLI RX| ----------------##-------------------------\n **** v1 4.4 CLI RX| \n **** v1 4.4 CLI RX| \n **** v1 4.4 CLI RX| In backend specification starting at:\n **** v1 4.4 CLI RX| ('input' Line 3 Pos 9)\n **** v1 4.4 CLI RX| backend b1 { .host = "127.0.0.1"; }\n **** v1 4.4 CLI RX| --------#######----------------------------\n **** v1 4.4 CLI RX| \n **** v1 4.4 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 4.4 CLI RX| \n **** v1 4.4 CLI RX| VCL compilation failed ** v1 4.4 VCL compilation failed (as expected) *** top 4.4 varnish **** v1 4.4 CLI TX| vcl.inline vcl15 << %XJEIFLH|)Xspa8P\n **** v1 4.4 CLI TX| \n **** v1 4.4 CLI TX| \tdirector r1 anarchy { .host = "127.0.0.1"; }\n **** v1 4.4 CLI TX| \n **** v1 4.4 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 4.4 CLI RX 106 **** v1 4.4 CLI RX| Message from VCC-compiler:\n **** v1 4.4 CLI RX| Unknown director policy: 'anarchy' at\n **** v1 4.4 CLI RX| ('input' Line 2 Pos 21)\n **** v1 4.4 CLI RX| director r1 anarchy { .host = "127.0.0.1"; }\n **** v1 4.4 CLI RX| --------------------#######-------------------------\n **** v1 4.4 CLI RX| \n **** v1 4.4 CLI RX| Running VCC-compiler failed, exit 1\n **** v1 4.4 CLI RX| \n **** v1 4.4 CLI RX| VCL compilation failed ** v1 4.4 VCL compilation failed (as expected) *** top 4.4 varnish **** v1 4.4 CLI TX| vcl.inline vcl16 << %XJEIFLH|)Xspa8P\n **** v1 4.4 CLI TX| \n **** v1 4.4 CLI TX| \t/* too many IP numbers */\n **** v1 4.4 CLI TX| \tbackend b1 { .host = "v00002.freebsd.dk"; }\n **** v1 4.4 CLI TX| \n **** v1 4.4 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 4.7 CLI RX 106 **** v1 4.7 CLI RX| Message from VCC-compiler:\n **** v1 4.7 CLI RX| Backend host "v00002.freebsd.dk": resolves to multiple IPv4 addresses.\n **** v1 4.7 CLI RX| Only one address is allowed.\n **** v1 4.7 CLI RX| Please specify which exact address you want to use, we found these:\n **** v1 4.7 CLI RX| \t127.0.0.2\n **** v1 4.7 CLI RX| \t127.0.0.3\n **** v1 4.7 CLI RX| \t127.0.0.4\n **** v1 4.7 CLI RX| ('input' Line 3 Pos 30)\n **** v1 4.7 CLI RX| backend b1 { .host = "v00002.freebsd.dk"; }\n **** v1 4.7 CLI RX| -----------------------------###################---\n **** v1 4.7 CLI RX| \n **** v1 4.7 CLI RX| \n **** v1 4.7 CLI RX| In backend specification starting at:\n **** v1 4.7 CLI RX| ('input' Line 3 Pos 9)\n **** v1 4.7 CLI RX| backend b1 { .host = "v00002.freebsd.dk"; }\n **** v1 4.7 CLI RX| --------#######---------------------------... ** v1 4.7 VCL compilation failed (as expected) *** top 4.7 varnish **** v1 4.7 CLI TX| vcl.inline vcl17 << %XJEIFLH|)Xspa8P\n **** v1 4.7 CLI TX| \n **** v1 4.7 CLI TX| \tbackend b1 { .host = "////."; }\n **** v1 4.7 CLI TX| \n **** v1 4.7 CLI TX| %XJEIFLH|)Xspa8P\n ---- v1 24.7 CLI failed (vcl.inline vcl17 << %XJEIFLH|)Xspa8P backend b1 { .host = "////."; } %XJEIFLH|)Xspa8P ) = -1 400 CLI communication error (hdr) ---- v1 24.7 VCL compilation got 400 expected 106 * top 24.7 RESETTING after ./tests/v00002.vtc ** v1 25.7 Wait ** v1 25.8 R 10222 Status: 0000 * top 25.8 TEST ./tests/v00002.vtc FAILED # top TEST ./tests/v00002.vtc FAILED (25.886) exit=1 }}} Simply rerunning the test makes the problem "go away", which is troubling... Could this (and the one from ticket 1209) problems be related to running tests with {{{TESTS_PARALLELISM=-j8}}}? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 10 17:15:56 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Oct 2012 17:15:56 -0000 Subject: [Varnish] #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) In-Reply-To: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> References: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> Message-ID: <055.6facf17ea9edee1492417905bcdce73a@varnish-cache.org> #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) -------------------------+-------------------- Reporter: mi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by mi): Adding the explicit stack size, helpful though it was on i386, is causing a crash (signal 11) on amd64... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 11 01:36:49 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Oct 2012 01:36:49 -0000 Subject: [Varnish] #1115: varnishncsa spuriously logs incorrect request URLs In-Reply-To: <043.661333fba437e692c4e4ca33fc0a4b8a@varnish-cache.org> References: <043.661333fba437e692c4e4ca33fc0a4b8a@varnish-cache.org> Message-ID: <058.caa75b2f52983a2ebfbf8724f9b5bafc@varnish-cache.org> #1115: varnishncsa spuriously logs incorrect request URLs -------------------------+--------------------- Reporter: lampe | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.2 Severity: minor | Resolution: Keywords: | -------------------------+--------------------- Comment (by lampe): The culprit in this case is: {{{ qs = index(ptr, '?'); if (qs) { lp->df_U = trimline(ptr, qs); }}} ptr is not null-terminated and filled with previous contents. qs could match beyond end. The works-for-me solution is to use memchr(ptr, '?', len) instead of index() or strchr() -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 11 10:21:05 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Oct 2012 10:21:05 -0000 Subject: [Varnish] #1211: TIME + DURATION returns a DURATION Message-ID: <043.9a415e6901f6c126c4fe444505fc37bf@varnish-cache.org> #1211: TIME + DURATION returns a DURATION -------------------+-------------------- Reporter: fgsch | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | -------------------+-------------------- So `now + duration' gets displayed as a REAL instead of TIME. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 11 11:08:12 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Oct 2012 11:08:12 -0000 Subject: [Varnish] #1211: TIME + DURATION returns a DURATION In-Reply-To: <043.9a415e6901f6c126c4fe444505fc37bf@varnish-cache.org> References: <043.9a415e6901f6c126c4fe444505fc37bf@varnish-cache.org> Message-ID: <058.081e0d2d76469a867271db72bc5a8361@varnish-cache.org> #1211: TIME + DURATION returns a DURATION --------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by Poul-Henning Kamp ): In [cc513fdc6cc098fcdc378af6ec80959a5c744054]: {{{ #!CommitTicketReference repository="" revision="cc513fdc6cc098fcdc378af6ec80959a5c744054" Fix a VCL expression type error: TIME +/- DURATION should return TIME Fixes #1211 Thanks to: Federico G. Schwindt }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 12 09:16:01 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Oct 2012 09:16:01 -0000 Subject: [Varnish] #1212: Vmod with HEADER argument given a STRING asserts the VCL compiler Message-ID: <046.bcc96774919d962f09ab92b613a5a3e5@varnish-cache.org> #1212: Vmod with HEADER argument given a STRING asserts the VCL compiler ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Keywords: ----------------------+------------------- The header vmod defines append as follows: Function VOID append(HEADER,STRING_LIST) When giving it a string instead of a header the compiler doesn't handle this well and asserts: {{{ lkarsten at immer:~$ /opt/varnish/sbin/varnishd -C -f assert.vcl Message from VCC-compiler: Assert error in VCC_FindSymbol(), vcc_symb.c line 120: Condition(t->tok == ID) not true. Running VCC-compiler failed, signal 6 VCL compilation failed lkarsten at immer:~$ }}} assert.vcl content: {{{ import header; backend default { .host="127.0.0.1"; .port="8080"; } sub vcl_deliver { // incorrect, asserts the compiler header.append("Set-Cookie", "foo"); // correct, works as expected header.append(resp.http.Set-Cookie, "foo"); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 12 09:52:27 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Oct 2012 09:52:27 -0000 Subject: [Varnish] #1207: varnishd child segfaults when using dns director In-Reply-To: <046.cbd6b84dea250737a025adc3c0105555@varnish-cache.org> References: <046.cbd6b84dea250737a025adc3c0105555@varnish-cache.org> Message-ID: <061.412163be7920fc0dbf2fca1487623dc6@varnish-cache.org> #1207: varnishd child segfaults when using dns director --------------------------+-------------------- Reporter: econnell | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: dns director | --------------------------+-------------------- Comment (by kristian): Hi, This is a bit of a semi-known bug, thanks for reporting it. You can work around it by putting the 'backend default' statement below the director. This is clearly a bug though. Varnishtest that works: {{{ varnish v1 -vcl { director direc dns { .list = { .host_header = "www.myhost.com"; .port = "80"; "72.246.30.10/32"; } .ttl = 5m; } backend defult { .host = "127.0.0.7"; .port = "8081"; } sub vcl_recv { set req.backend = direc; set req.backend = defult; } } -start }}} Varnishtest that breaks: {{{ varnish v2 -vcl { backend defult { .host = "127.0.0.7"; .port = "8081"; } director direc dns { .list = { .host_header = "www.myhost.com"; .port = "80"; "72.246.30.10/32"; } .ttl = 5m; } sub vcl_recv { set req.backend = direc; set req.backend = defult; } } -start }}} I'm pretty sure docwilco already tracked this down, it's some bad assumption about indexes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 12 11:00:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Oct 2012 11:00:53 -0000 Subject: [Varnish] #1212: Vmod with HEADER argument given a STRING asserts the VCL compiler In-Reply-To: <046.bcc96774919d962f09ab92b613a5a3e5@varnish-cache.org> References: <046.bcc96774919d962f09ab92b613a5a3e5@varnish-cache.org> Message-ID: <061.eeb3d0624251b080c736f12dff84f243@varnish-cache.org> #1212: Vmod with HEADER argument given a STRING asserts the VCL compiler ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): Dag mentioned that this probably also is reproducable by passing a string to std.collect(). Prototype collect(HEADER header) I have not tested this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 15 10:21:13 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Oct 2012 10:21:13 -0000 Subject: [Varnish] #1209: Intermittent failure of tests/v00017.vtc In-Reply-To: <040.6dddeed43b6ad4d733da8ea80d4a9c4d@varnish-cache.org> References: <040.6dddeed43b6ad4d733da8ea80d4a9c4d@varnish-cache.org> Message-ID: <055.8a32305f25827ae3bb15b97c7ceb8cbb@varnish-cache.org> #1209: Intermittent failure of tests/v00017.vtc -------------------------+------------------------ Reporter: mi | Owner: Type: defect | Status: closed Priority: low | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: duplicate Keywords: | -------------------------+------------------------ Changes (by phk): * status: new => closed * resolution: => duplicate Comment: I'm folding this one into #1210 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 15 10:22:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Oct 2012 10:22:33 -0000 Subject: [Varnish] #1210: Intermittent failure of tests/v00002.vtc In-Reply-To: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> References: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> Message-ID: <055.3698938283bbb768a328c6a969c1a00b@varnish-cache.org> #1210: Intermittent failure of tests/v00002.vtc -------------------------+------------------------- Reporter: mi | Owner: Type: defect | Status: closed Priority: low | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: worksforme Keywords: | -------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I think the problem in both this and #1209 is that -j8 is too much for your machine. The parallelism of Varnishtests is limited not so much by CPUs or cores, but by the disk-I/O subsystem in creating shared memory and other tasks. I suggest you don't automatically set -j to #cpu, but rather to a credible low constant such as 2-4 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 15 11:02:59 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Oct 2012 11:02:59 -0000 Subject: [Varnish] #1115: varnishncsa spuriously logs incorrect request URLs In-Reply-To: <043.661333fba437e692c4e4ca33fc0a4b8a@varnish-cache.org> References: <043.661333fba437e692c4e4ca33fc0a4b8a@varnish-cache.org> Message-ID: <058.fa184012b60b121d6b3990ff389eb831@varnish-cache.org> #1115: varnishncsa spuriously logs incorrect request URLs -------------------------+--------------------- Reporter: lampe | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.2 Severity: minor | Resolution: Keywords: | -------------------------+--------------------- Comment (by Tollef Fog Heen ): In [b2d19c5f6d3c3d661720a4c4ed2ff0b4695e6f04]: {{{ #!CommitTicketReference repository="" revision="b2d19c5f6d3c3d661720a4c4ed2ff0b4695e6f04" Use memchr rather than strchr/index the strings we get from the libvarnishapi functions are not necessarily null-terminated, so avoid using str* functions on them. Thanks to lampe for the patch. Fixes #1115 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 15 11:03:03 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Oct 2012 11:03:03 -0000 Subject: [Varnish] #1115: varnishncsa spuriously logs incorrect request URLs In-Reply-To: <043.661333fba437e692c4e4ca33fc0a4b8a@varnish-cache.org> References: <043.661333fba437e692c4e4ca33fc0a4b8a@varnish-cache.org> Message-ID: <058.0477decb0377a60c62f3a96a9014dd1c@varnish-cache.org> #1115: varnishncsa spuriously logs incorrect request URLs -------------------------+--------------------- Reporter: lampe | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.2 Severity: minor | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [b2d19c5f6d3c3d661720a4c4ed2ff0b4695e6f04]) Use memchr rather than strchr/index the strings we get from the libvarnishapi functions are not necessarily null-terminated, so avoid using str* functions on them. Thanks to lampe for the patch. Fixes #1115 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 15 11:17:04 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Oct 2012 11:17:04 -0000 Subject: [Varnish] #1117: error - varnishncsa[473]: segfault at 0 ip 00007fd645a00022 In-Reply-To: <047.78536ce4e57383a6a091e8d8777b70f6@varnish-cache.org> References: <047.78536ce4e57383a6a091e8d8777b70f6@varnish-cache.org> Message-ID: <062.7c7e589b93a3442a980ed3f175714b36@varnish-cache.org> #1117: error - varnishncsa[473]: segfault at 0 ip 00007fd645a00022 -------------------------+-------------------- Reporter: webmaster | Owner: Type: defect | Status: new Priority: highest | Milestone: Component: varnishncsa | Version: 3.0.0 Severity: critical | Resolution: Keywords: | -------------------------+-------------------- Comment (by tfheen): Sorry for not getting around to this earlier; any chance you could run varnishncsa under gdb and get a backtrace when this happens? Also, which version of Varnish is this with? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 15 11:32:31 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Oct 2012 11:32:31 -0000 Subject: [Varnish] #1213: varnishtop leaks file descriptors and deleted files Message-ID: <041.2d8171f36cc44c5bebb5df3eab15cbd1@varnish-cache.org> #1213: varnishtop leaks file descriptors and deleted files -------------------+------------------------ Reporter: mha | Type: defect Status: new | Priority: normal Milestone: | Component: varnishtop Version: 3.0.3 | Severity: normal Keywords: | -------------------+------------------------ varnishtop leaks an open file descriptor to the shmlog, which makes it not go away when varnishd is restarted while varnishtop runs. This is a problem e.g. when running with the shmlog on tmpfs with a limited size. Repro: 1. start varnish 2. start varnishtop 3. `service varnish restart` 4. 5. `lsof /var/lib/varnish` shows varnishtop still has an open fd against the old shm-log, and thus it leaks the space If you change varnishtop for varnishlog, the problem does not appear - so varnishlog deals with it properly. As does varnishtstat. Both close the file after a few seconds. In my case, it happened on CentOS 6.3 with the Varnish RPMs installed from repo.varnish-cache.org. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 15 11:44:41 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Oct 2012 11:44:41 -0000 Subject: [Varnish] #1214: s_bodybytes and range: header issue Message-ID: <044.a58f5d0e9a88ea3d4b7ad9a85cf21498@varnish-cache.org> #1214: s_bodybytes and range: header issue ------------------------------------+---------------------- Reporter: emilio | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: normal Keywords: s_bodybytes range: 206 | ------------------------------------+---------------------- when using the range: header to partially download a file s_bodybytes is incremented by the full size needed to finish the download instead of the actually downloaded size. this create huge s_bodybytes error (even 20 time the correct data) with client like the iphone podcast app which split the file in many chunks, each of them counted as the whole size of the missing download to the end of the file. also I see we have no size in the logs created by varnishncsa for partially delivered (http 206) contents (but I can understand this is due to not having the data available when the logs is written) PS thanks for the great software! emilio brambilla -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 15 12:58:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Oct 2012 12:58:52 -0000 Subject: [Varnish] #1210: Intermittent failure of tests/v00002.vtc In-Reply-To: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> References: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> Message-ID: <055.240775bde377d8926aadf73697f18af0@varnish-cache.org> #1210: Intermittent failure of tests/v00002.vtc -------------------------+------------------------- Reporter: mi | Owner: Type: defect | Status: closed Priority: low | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: worksforme Keywords: | -------------------------+------------------------- Comment (by mi): Ok... But is the observed reaction to this suspected resource shortage normal? In other words, should not the resource-shortage be properly reported? Is it not a bug to simply fail like this? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 16 10:12:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Oct 2012 10:12:00 -0000 Subject: [Varnish] #1215: cache object stub Message-ID: <047.11ae9a7f8310cf1f2f74afe7341507cb@varnish-cache.org> #1215: cache object stub -----------------------+-------------------- Reporter: stavrinov | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.3 | Severity: normal Keywords: | -----------------------+-------------------- This problem exists with permanent storage only. When there are no enough space in the storage for new fetched from back-end file, varnish delivers to client truncated, broken file. Tested for both 3.0.2 and 3.0.3 versions. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 16 12:52:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Oct 2012 12:52:16 -0000 Subject: [Varnish] #1210: Intermittent failure of tests/v00002.vtc In-Reply-To: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> References: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> Message-ID: <055.61475a91702c7253f3fcf1d1e9722032@varnish-cache.org> #1210: Intermittent failure of tests/v00002.vtc -------------------------+----------------------- Reporter: mi | Owner: Type: defect | Status: reopened Priority: low | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: Keywords: | -------------------------+----------------------- Changes (by mi): * status: closed => reopened * resolution: worksforme => Comment: Running with -j'''1''' I just had another failure. This time it is b00030.vtc: {{{ ./varnishtest -i -j1 ./tests/*.vtc # top TEST ./tests/a00000.vtc passed (0.004) # top TEST ./tests/a00001.vtc passed (0.003) # top TEST ./tests/a00002.vtc passed (0.004) # top TEST ./tests/a00003.vtc passed (0.006) .... # top TEST ./tests/b00028.vtc passed (1.133) # top TEST ./tests/b00029.vtc passed (4.134) ######## ./tests/b00030.vtc ######## Assert error in VSL_Open_CallBack(), vsl.c line 366: Condition(sha != NULL) not true. ######## ./tests/b00030.vtc ######## errno = 2 (No such file or directory) **** top 0.0 macro def varnishd=../varnishd/varnishd **** top 0.0 macro def pwd=/mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest **** top 0.0 macro def topbuild=/mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest/../.. **** top 0.0 macro def bad_ip=10.255.255.255 **** top 0.0 macro def tmpdir=/tmp/vtc.33839.0679e193 * top 0.0 TEST ./tests/b00030.vtc starting *** top 0.0 varnishtest * top 0.0 TEST Test formatting of timestamps *** top 0.0 server ** s1 0.0 Starting server **** s1 0.0 macro def s1_addr=127.0.0.1 **** s1 0.0 macro def s1_port=20321 **** s1 0.0 macro def s1_sock=127.0.0.1 20321 * s1 0.0 Listen on 127.0.0.1 20321 *** top 0.0 varnish ** s1 0.0 Started on 127.0.0.1 20321 ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && ${varnishd} -d -d -n /tmp/vtc.33839.0679e193/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.33839.0679e193/v1/_S -M '127.0.0.1 54824' -P /tmp/vtc.33839.0679e193/v1/varnishd.pid -sfile,/tmp/vtc.33839.0679e193/v1,10M *** v1 0.0 CMD: cd /mi/ports/www/varnish/work/varnish-3.0.3/bin/varnishtest && ../varnishd/varnishd -d -d -n /tmp/vtc.33839.0679e193/v1 -l 10m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -a '127.0.0.1:0' -S /tmp/vtc.33839.0679e193/v1/_S -M '127.0.0.1 54824' -P /tmp/vtc.33839.0679e193/v1/varnishd.pid -sfile,/tmp/vtc.33839.0679e193/v1,10M *** v1 0.0 PID: 34746 *** v1 0.1 debug| Platform: FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n *** v1 0.1 debug| 200 236 \n *** v1 0.1 debug| -----------------------------\n *** v1 0.1 debug| Varnish Cache CLI 1.0\n *** v1 0.1 debug| -----------------------------\n *** v1 0.1 debug| FreeBSD,8.3-STABLE,i386,-sfile,-smalloc,-hcritbit\n *** v1 0.1 debug| \n *** v1 0.1 debug| Type 'help' for command list.\n *** v1 0.1 debug| Type 'quit' to close CLI session.\n *** v1 0.1 debug| Type 'start' to launch worker process.\n *** v1 0.1 debug| \n # top TEST ./tests/b00030.vtc FAILED (0.358) signal=6 exit=0 }}} Something is not right about the test-framework... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 17 08:25:55 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Oct 2012 08:25:55 -0000 Subject: [Varnish] #1166: Varnishadm throws an assert In-Reply-To: <051.5814c781387d31eb173c4ed622e0ca4c@varnish-cache.org> References: <051.5814c781387d31eb173c4ed622e0ca4c@varnish-cache.org> Message-ID: <066.eeedf1930d7685e86ebe1c9678aec7e0@varnish-cache.org> #1166: Varnishadm throws an assert ------------------------+----------------------- Reporter: rj@? | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishadm | Version: 3.0.2 Severity: normal | Resolution: Keywords: varnishadm | ------------------------+----------------------- Changes (by lampe): * status: closed => reopened * resolution: worksforme => Comment: Hi. I get the same assert when resizing the window with the running varnishadm. varnishadm receives a SIGWINCH signal and aborts: {{{ varnish> Assert error in pass(), varnishadm.c line 226: Condition(i > 0) not true. errno = 4 (Interrupted system call) Aborted }}} Here's the strace output: {{{ write(1, "varnish> ", 9varnish> ) = 9 poll([{fd=4, events=POLLIN}, {fd=0, events=POLLIN}], 2, -1) = ? ERESTART_RESTARTBLOCK (To be restarted) --- SIGWINCH (Window changed) @ 0 (0) --- rt_sigprocmask(SIG_BLOCK, [WINCH], [WINCH], 8) = 0 rt_sigprocmask(SIG_BLOCK, [WINCH], [WINCH], 8) = 0 ioctl(0, TIOCGWINSZ, {ws_row=50, ws_col=131, ws_xpixel=0, ws_ypixel=0}) = 0 rt_sigprocmask(SIG_SETMASK, [WINCH], NULL, 8) = 0 rt_sigaction(SIGWINCH, {SIG_DFL, [WINCH], SA_RESTORER|SA_RESTART, 0x7f28c82b0230}, {0x7f28c8cd50d0, [WINCH], SA_RESTORER|SA_RESTART, 0x7f28c82b0230}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [WINCH], NULL, 8) = 0 kill(0, SIGWINCH) = 0 rt_sigreturn(0) = -1 EINTR (Interrupted system call) --- SIGWINCH (Window changed) @ 0 (0) --- write(2, "Assert error in pass(), varnisha"..., 76Assert error in pass(), varnishadm.c line 226: Condition(i > 0) not true. ) = 76 write(2, " errno = 4 (Interrupted system "..., 38 errno = 4 (Interrupted system call) ) = 38 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(23330, 23330, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- +++ killed by SIGABRT +++ Aborted }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 17 10:04:39 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Oct 2012 10:04:39 -0000 Subject: [Varnish] #1212: Vmod with HEADER argument given a STRING asserts the VCL compiler In-Reply-To: <046.bcc96774919d962f09ab92b613a5a3e5@varnish-cache.org> References: <046.bcc96774919d962f09ab92b613a5a3e5@varnish-cache.org> Message-ID: <061.6d25702c39fabc0ff0aa0b27eecf5d2f@varnish-cache.org> #1212: Vmod with HEADER argument given a STRING asserts the VCL compiler ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Poul-Henning Kamp ): In [6a9d2f2fa1140e8e41a45f44c6c2a4ee6c1afcfe]: {{{ #!CommitTicketReference repository="" revision="6a9d2f2fa1140e8e41a45f44c6c2a4ee6c1afcfe" Emit a regular error, rather than a VCC assert. Found & Fixed by: Federico G. Schwindt Fixes #1212 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 17 10:04:41 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Oct 2012 10:04:41 -0000 Subject: [Varnish] #1212: Vmod with HEADER argument given a STRING asserts the VCL compiler In-Reply-To: <046.bcc96774919d962f09ab92b613a5a3e5@varnish-cache.org> References: <046.bcc96774919d962f09ab92b613a5a3e5@varnish-cache.org> Message-ID: <061.db68fbda1720a176c379cc643e17ea12@varnish-cache.org> #1212: Vmod with HEADER argument given a STRING asserts the VCL compiler ----------------------+--------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [6a9d2f2fa1140e8e41a45f44c6c2a4ee6c1afcfe]) Emit a regular error, rather than a VCC assert. Found & Fixed by: Federico G. Schwindt Fixes #1212 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 17 10:25:05 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Oct 2012 10:25:05 -0000 Subject: [Varnish] #1206: Pass shouldn't honor IMS/INM if the backend doesn't In-Reply-To: <045.056ef3b3c7a98c4fb026f4180bff25e1@varnish-cache.org> References: <045.056ef3b3c7a98c4fb026f4180bff25e1@varnish-cache.org> Message-ID: <060.2d66b8764a793f00f6669d3b0edf11b0@varnish-cache.org> #1206: Pass shouldn't honor IMS/INM if the backend doesn't ----------------------+--------------------- Reporter: drwilco | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [ff2647b2828888f3e39637f3688dad6a05354500]) Don't do conditional processing for hit-for-pass objects. Fixes #1206 Found & Fixed by: DocWilco -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 17 10:25:03 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Oct 2012 10:25:03 -0000 Subject: [Varnish] #1206: Pass shouldn't honor IMS/INM if the backend doesn't In-Reply-To: <045.056ef3b3c7a98c4fb026f4180bff25e1@varnish-cache.org> References: <045.056ef3b3c7a98c4fb026f4180bff25e1@varnish-cache.org> Message-ID: <060.927c52f71c80a99c50229f4a3fe48055@varnish-cache.org> #1206: Pass shouldn't honor IMS/INM if the backend doesn't ----------------------+-------------------- Reporter: drwilco | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Poul-Henning Kamp ): In [ff2647b2828888f3e39637f3688dad6a05354500]: {{{ #!CommitTicketReference repository="" revision="ff2647b2828888f3e39637f3688dad6a05354500" Don't do conditional processing for hit-for-pass objects. Fixes #1206 Found & Fixed by: DocWilco }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 18 02:18:26 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Oct 2012 02:18:26 -0000 Subject: [Varnish] #1216: Bug:'error': not a valid action in method 'vcl_deliver'. Message-ID: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> #1216: Bug:'error': not a valid action in method 'vcl_deliver'. ------------------------+---------------------- Reporter: z329224946 | Type: defect Status: new | Priority: highest Milestone: | Component: varnishd Version: 3.0.3 | Severity: critical Keywords: | ------------------------+---------------------- hello,I use the action error code [reason] in the vcl_deliver,but it return an error that: 'error': not a valid action in method 'vcl_deliver'. Thank you! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 18 10:24:30 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Oct 2012 10:24:30 -0000 Subject: [Varnish] #1217: compress with ttl=0 returns invalid content-length Message-ID: <047.51edc8834c8b776fe852c4ea9225ca1d@varnish-cache.org> #1217: compress with ttl=0 returns invalid content-length -----------------------+---------------------- Reporter: prymitive | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: normal Keywords: | -----------------------+---------------------- I have val as below. {{{ sub vcl_fetch { if (beresp.http.x-cachable == "0") { set beresp.ttl = 0s; } if (beresp.http.content-type ~ "(text|javascript|json)") { set beresp.do_gzip = true; } } sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } } }}} My backend sends "X-Cachable: 0" header for some apps. First I get an answer without Content-Length header: {{{ curl -H "Accept-Encoding: gzip" -I http://my.app.com/static/js/jquery.qtip.js HTTP/1.1 200 OK Content-Type: application/javascript Content-Encoding: gzip X-Cache: MISS }}} After that varnish starts to repond with Content-Length header set to size of uncompressed jquery.qtip.js {{{ curl -H "Accept-Encoding: gzip" -I http://my.app.com/static/js/jquery.qtip.js HTTP/1.1 200 OK Content-Type: application/javascript Content-Length: 97197 Content-Encoding: gzip X-Cache: MISS }}} Without valid encoding Content-Length is the same {{{ curl -H "Accept-Encoding: xgzip" -I http://my.app.com/static/js/jquery.qtip.js HTTP/1.1 200 OK Content-Type: application/javascript Content-Length: 97197 X-Cache: MISS }}} This only happens with '''set beresp.ttl = 0s''', when I don't disable caching with backend headers is works fine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 18 16:13:04 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Oct 2012 16:13:04 -0000 Subject: [Varnish] #1216: Bug:'error': not a valid action in method 'vcl_deliver'. In-Reply-To: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> References: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> Message-ID: <063.1f2cc999250d95ad52cfc84601498977@varnish-cache.org> #1216: Bug:'error': not a valid action in method 'vcl_deliver'. ------------------------+-------------------- Reporter: z329224946 | Owner: Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: Keywords: | ------------------------+-------------------- Comment (by fgsch): error from vcl_deliver is not allowed. The documentation needs to be updated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 18 21:19:18 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Oct 2012 21:19:18 -0000 Subject: [Varnish] #1218: String concatenation operator '+' doesn't work on empty strings Message-ID: <047.ad22a222473e230158b9f34ebf490693@varnish-cache.org> #1218: String concatenation operator '+' doesn't work on empty strings -----------------------+---------------------- Reporter: jafcobend | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: normal Keywords: | -----------------------+---------------------- I tried doing something like this in vcl_recv(): set req.http.Cookie = req.http.Cookie+" "+req.http.Cookie-sess; I discovered that this only works if req.http.Cookie already has a value. In my VCL it may or may not have a value by the time it gets here. I was able to do this instead: if(req.http.Cookie) { set req.http.Cookie = req.http.Cookie+" "+req.http.Cookie-sess; } else { set req.http.Cookie = req.http.Cookie-sess; } But it sure would be nice if the first one-liner worked. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 18 22:09:02 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Oct 2012 22:09:02 -0000 Subject: [Varnish] #1218: String concatenation operator '+' doesn't work on empty strings In-Reply-To: <047.ad22a222473e230158b9f34ebf490693@varnish-cache.org> References: <047.ad22a222473e230158b9f34ebf490693@varnish-cache.org> Message-ID: <062.1d25d6c8d4539ebdef47ab22b59fda1f@varnish-cache.org> #1218: String concatenation operator '+' doesn't work on empty strings -----------------------+-------------------- Reporter: jafcobend | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by Poul-Henning Kamp ): In [0e984bd491faa3742601ee8c64a69955445bc7a0]: {{{ #!CommitTicketReference repository="" revision="0e984bd491faa3742601ee8c64a69955445bc7a0" Make set req.http.Cookie = req.http.Cookie + " " + req.http.Cookie-sess; do the obvious thing, even if req.http.Cookie does not exist. The underlying issue was a badly though through overloading of the NULL value to mean "Unset". Now it has its own magic marker. Fixes #1218 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 18 22:09:04 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Oct 2012 22:09:04 -0000 Subject: [Varnish] #1218: String concatenation operator '+' doesn't work on empty strings In-Reply-To: <047.ad22a222473e230158b9f34ebf490693@varnish-cache.org> References: <047.ad22a222473e230158b9f34ebf490693@varnish-cache.org> Message-ID: <062.a40d56ac775112f8c7c09d1dba779660@varnish-cache.org> #1218: String concatenation operator '+' doesn't work on empty strings -----------------------+--------------------- Reporter: jafcobend | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | -----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [0e984bd491faa3742601ee8c64a69955445bc7a0]) Make set req.http.Cookie = req.http.Cookie + " " + req.http.Cookie-sess; do the obvious thing, even if req.http.Cookie does not exist. The underlying issue was a badly though through overloading of the NULL value to mean "Unset". Now it has its own magic marker. Fixes #1218 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 19 07:07:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Oct 2012 07:07:53 -0000 Subject: [Varnish] #1219: degraded speed with persistent storage Message-ID: <047.d33cc554f18272c8c3e85a89b7fa6dd4@varnish-cache.org> #1219: degraded speed with persistent storage -----------------------+---------------------- Reporter: stavrinov | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: normal Keywords: | -----------------------+---------------------- With stream support tuned on the both fetching and delivering (while fetching) speeds with persistent storage are of 10 times less then compared to ones with file storage. The test was done on 1 Gbit/s port where throughput of test download exceed about 80% of bandwidth. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 19 07:44:38 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Oct 2012 07:44:38 -0000 Subject: [Varnish] #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check Message-ID: <057.dbb04d60a18cae71789693faca361b5c@varnish-cache.org> #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check -------------------------+------------------------- Reporter: jinjian.1@? | Type: defect Status: new | Priority: high Milestone: | Component: varnishncsa Version: 3.0.2 | Severity: critical Keywords: stream Gzip | -------------------------+------------------------- Stream is enabled to forward response ASAP. log below, i removed the host name because of potential business secret policy. 79 TxRequest b GET 79 TxURL b /504403b47a6c8777da011aaf/*******.com/v~80/_images/collections/3/4856.jpg 79 TxProtocol b HTTP/1.1 79 TxHeader b Host: system-2.yottaa.net 79 TxHeader b User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 Safari/536.26.14 79 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 79 TxHeader b Accept-Language: en-us 79 TxHeader b Cookie: yvts=1350566984282; km_ai=6SqgaCrNmzK%2FyJRnVEWlkrbiNBE%3D; km_lv=1348671534; km_uq=; mp_3aa8ae394f21ef02134f93c80b02d5bd_mixpanel=%7B%22distinct_id%22%3A%20%2213a03166e738a7-05067b594-376c6050-1fa400-13a03166e741115%22%2C%22%24initial_referrer%22 79 TxHeader b X-Host: s-ff0102-504403b47a6c8777da011aaf-0.yottaa.net 79 TxHeader b X-Forwarded-Proto: http 79 TxHeader b Via: HTTP/1.1 ECS (jfk/25C0) 79 TxHeader b X-Forwarded-For: 70.109.156.55, 68.232.37.192 79 TxHeader b X-Yottaa-SessionId: 1333429556 79 TxHeader b Accept-Encoding: gzip 79 RxProtocol b HTTP/1.1 79 RxStatus b 200 79 RxResponse b OK 79 RxHeader b Date: Thu, 18 Oct 2012 13:31:11 GMT 79 RxHeader b Server: Apache 79 RxHeader b Last-Modified: Wed, 17 Oct 2012 11:11:56 GMT 79 RxHeader b Accept-Ranges: bytes 79 RxHeader b Cache-Control: max-age=3600 79 RxHeader b Expires: Thu, 18 Oct 2012 14:31:11 GMT 79 RxHeader b Vary: Accept-Encoding 79 RxHeader b Keep-Alive: timeout=15, max=92 79 RxHeader b Content-Type: image/jpeg 79 RxHeader b X-Yottaa-Optimizations: ob/0 si/1333429556 ts/1350562509213 79 RxHeader b Content-Encoding: gzip 79 RxHeader b X-Yottaa-Metrics: 01216b174f46/[194,191,-] 01116b172e2c/[199,198,-] 79 RxHeader b Transfer-Encoding: chunked 79 RxHeader b Connection: keep-alive 79 Fetch_Body b 3(chunked) cls -1 mklen 1 79 BackendClose b a 42 SessionOpen c 68.232.37.192 53862 :80 42 ReqStart c 68.232.37.192 53862 1333429556 42 RxRequest c GET 42 RxURL c /504403b47a6c8777da011aaf/********.com/v~80/_images/collections/3/4856.jpg 42 RxProtocol c HTTP/1.1 42 RxHeader c Host: system-2.yottaa.net 42 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 Safari/536.26.14 42 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 42 RxHeader c Accept-Language: en-us 42 RxHeader c Accept-Encoding: gzip, deflate 42 RxHeader c Cookie: yvts=1350566984282; km_ai=6SqgaCrNmzK%2FyJRnVEWlkrbiNBE%3D; km_lv=1348671534; km_uq=; mp_3aa8ae394f21ef02134f93c80b02d5bd_mixpanel=%7B%22distinct_id%22%3A%20%2213a03166e738a7-05067b594-376c6050-1fa400-13a03166e741115%22%2C%22%24initial_referrer%22 42 RxHeader c X-Forwarded-For: 70.109.156.55 42 RxHeader c X-Host: s-ff0102-504403b47a6c8777da011aaf-0.yottaa.net 42 RxHeader c X-Forwarded-Proto: http 42 RxHeader c Via: HTTP/1.1 ECS (jfk/25C0) 42 VCL_call c recv lookup 42 VCL_call c hash 42 Hash c /504403b47a6c8777da011aaf/********.com/v~80/_images/collections/3/4856.jpg 42 Hash c system-2.yottaa.net 42 Hash c http 42 VCL_return c hash 42 VCL_call c miss fetch 42 Backend c 79 yo a 42 TTL c 1333429556 RFC 3600 -1 -1 1350567072 0 1350567071 1350570671 3600 42 VCL_call c fetch 42 TTL c 1333429556 VCL 3600 3600 -1 1350567072 -0 42 VCL_Log c enter fetch 42 VCL_Log c streaming enabled. 42 TTL c 1333429556 VCL -1 -1 -1 1350567072 -0 42 VCL_return c hit_for_pass 42 ObjProtocol c HTTP/1.1 42 ObjResponse c OK 42 ObjHeader c Date: Thu, 18 Oct 2012 13:31:11 GMT 42 ObjHeader c Server: Apache 42 ObjHeader c Last-Modified: Wed, 17 Oct 2012 11:11:56 GMT 42 ObjHeader c Accept-Ranges: bytes 42 ObjHeader c Cache-Control: max-age=3600 42 ObjHeader c Expires: Thu, 18 Oct 2012 14:31:11 GMT 42 ObjHeader c Vary: Accept-Encoding 42 ObjHeader c Content-Type: image/jpeg 42 ObjHeader c X-Yottaa-Optimizations: ob/0 si/1333429556 ts/1350562509213 42 ObjHeader c Content-Encoding: gzip 42 ObjHeader c X-Yottaa-Metrics: 01216b174f46/[194,191,-] 01116b172e2c/[199,198,-] 42 ObjHeader c x-host: system-2.yottaa.net 42 VCL_call c deliver deliver 42 TxProtocol c HTTP/1.1 42 TxStatus c 200 42 TxResponse c OK 42 TxHeader c Server: Apache 42 TxHeader c Last-Modified: Wed, 17 Oct 2012 11:11:56 GMT 42 TxHeader c Accept-Ranges: bytes 42 TxHeader c Cache-Control: max-age=3600 42 TxHeader c Expires: Thu, 18 Oct 2012 14:31:11 GMT 42 TxHeader c Vary: Accept-Encoding 42 TxHeader c Content-Type: image/jpeg 42 TxHeader c X-Yottaa-Optimizations: ob/0 si/1333429556 ts/1350562509213 42 TxHeader c Content-Encoding: gzip 42 TxHeader c X-Yottaa-Metrics: 01216b174f46/[194,191,-] 01116b172e2c/[199,198,-] 42 TxHeader c Transfer-Encoding: chunked 42 TxHeader c Date: Thu, 18 Oct 2012 13:31:11 GMT 42 TxHeader c Age: 0 42 TxHeader c Connection: keep-alive 42 Traffic c traffic stats, host:********.com,requests:1,traffic:472,is_https:0,state:0 42 Traffic c message_bytes:472 42 Traffic c traffic stats, host:********.com,requests:0,traffic:8192,is_https:0,state:1 42 Traffic c message_bytes:8192 42 FetchError c Invalid Gzip data: incorrect header check 42 FetchError c chunked read_error: 0 (See other message) 42 Gzip c u F - 2 0 0 0 0 42 Length c 0 42 ReqEnd c 1333429556 1350567071.527108192 1350567071.727841377 0.000091314 0.199551105 0.001182079 42 SessionClose c Stream error 42 StatSess c 68.232.37.192 53862 0 1 1 0 0 1 472 0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 19 07:49:10 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Oct 2012 07:49:10 -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.9897e459adecfb4ec72ec20b09900533@varnish-cache.org> #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check -------------------------+-------------------- Reporter: jinjian.1@? | Owner: Type: defect | Status: new Priority: high | Milestone: Component: varnishncsa | Version: 3.0.2 Severity: critical | Resolution: Keywords: stream Gzip | -------------------------+-------------------- Comment (by jinjian.1@?): Sorry the componet i set is incorrect, it should be varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 19 12:06:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Oct 2012 12:06:33 -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.230a395e6378c2233f3f01e06e9907fa@varnish-cache.org> #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check -------------------------+-------------------- Reporter: jinjian.1@? | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: stream Gzip | -------------------------+-------------------- Changes (by tfheen): * priority: high => normal * component: varnishncsa => varnishd * severity: critical => normal Old description: > Stream is enabled to forward response ASAP. > > log below, i removed the host name because of potential business secret > policy. > > 79 TxRequest b GET > 79 TxURL b > /504403b47a6c8777da011aaf/*******.com/v~80/_images/collections/3/4856.jpg > 79 TxProtocol b HTTP/1.1 > 79 TxHeader b Host: system-2.yottaa.net > 79 TxHeader b User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X > 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 > Safari/536.26.14 > 79 TxHeader b Accept: > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > 79 TxHeader b Accept-Language: en-us > 79 TxHeader b Cookie: yvts=1350566984282; > km_ai=6SqgaCrNmzK%2FyJRnVEWlkrbiNBE%3D; km_lv=1348671534; km_uq=; > mp_3aa8ae394f21ef02134f93c80b02d5bd_mixpanel=%7B%22distinct_id%22%3A%20%2213a03166e738a7-05067b594-376c6050-1fa400-13a03166e741115%22%2C%22%24initial_referrer%22 > 79 TxHeader b X-Host: s-ff0102-504403b47a6c8777da011aaf-0.yottaa.net > 79 TxHeader b X-Forwarded-Proto: http > 79 TxHeader b Via: HTTP/1.1 ECS (jfk/25C0) > 79 TxHeader b X-Forwarded-For: 70.109.156.55, 68.232.37.192 > 79 TxHeader b X-Yottaa-SessionId: 1333429556 > 79 TxHeader b Accept-Encoding: gzip > 79 RxProtocol b HTTP/1.1 > 79 RxStatus b 200 > 79 RxResponse b OK > 79 RxHeader b Date: Thu, 18 Oct 2012 13:31:11 GMT > 79 RxHeader b Server: Apache > 79 RxHeader b Last-Modified: Wed, 17 Oct 2012 11:11:56 GMT > 79 RxHeader b Accept-Ranges: bytes > 79 RxHeader b Cache-Control: max-age=3600 > 79 RxHeader b Expires: Thu, 18 Oct 2012 14:31:11 GMT > 79 RxHeader b Vary: Accept-Encoding > 79 RxHeader b Keep-Alive: timeout=15, max=92 > 79 RxHeader b Content-Type: image/jpeg > 79 RxHeader b X-Yottaa-Optimizations: ob/0 si/1333429556 > ts/1350562509213 > 79 RxHeader b Content-Encoding: gzip > 79 RxHeader b X-Yottaa-Metrics: 01216b174f46/[194,191,-] > 01116b172e2c/[199,198,-] > 79 RxHeader b Transfer-Encoding: chunked > 79 RxHeader b Connection: keep-alive > 79 Fetch_Body b 3(chunked) cls -1 mklen 1 > 79 BackendClose b a > 42 SessionOpen c 68.232.37.192 53862 :80 > 42 ReqStart c 68.232.37.192 53862 1333429556 > 42 RxRequest c GET > 42 RxURL c > /504403b47a6c8777da011aaf/********.com/v~80/_images/collections/3/4856.jpg > 42 RxProtocol c HTTP/1.1 > 42 RxHeader c Host: system-2.yottaa.net > 42 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X > 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 > Safari/536.26.14 > 42 RxHeader c Accept: > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > 42 RxHeader c Accept-Language: en-us > 42 RxHeader c Accept-Encoding: gzip, deflate > 42 RxHeader c Cookie: yvts=1350566984282; > km_ai=6SqgaCrNmzK%2FyJRnVEWlkrbiNBE%3D; km_lv=1348671534; km_uq=; > mp_3aa8ae394f21ef02134f93c80b02d5bd_mixpanel=%7B%22distinct_id%22%3A%20%2213a03166e738a7-05067b594-376c6050-1fa400-13a03166e741115%22%2C%22%24initial_referrer%22 > 42 RxHeader c X-Forwarded-For: 70.109.156.55 > 42 RxHeader c X-Host: s-ff0102-504403b47a6c8777da011aaf-0.yottaa.net > 42 RxHeader c X-Forwarded-Proto: http > 42 RxHeader c Via: HTTP/1.1 ECS (jfk/25C0) > 42 VCL_call c recv lookup > 42 VCL_call c hash > 42 Hash c > /504403b47a6c8777da011aaf/********.com/v~80/_images/collections/3/4856.jpg > 42 Hash c system-2.yottaa.net > 42 Hash c http > 42 VCL_return c hash > 42 VCL_call c miss fetch > 42 Backend c 79 yo a > 42 TTL c 1333429556 RFC 3600 -1 -1 1350567072 0 1350567071 1350570671 > 3600 > 42 VCL_call c fetch > 42 TTL c 1333429556 VCL 3600 3600 -1 1350567072 -0 > 42 VCL_Log c enter fetch > 42 VCL_Log c streaming enabled. > 42 TTL c 1333429556 VCL -1 -1 -1 1350567072 -0 > 42 VCL_return c hit_for_pass > 42 ObjProtocol c HTTP/1.1 > 42 ObjResponse c OK > 42 ObjHeader c Date: Thu, 18 Oct 2012 13:31:11 GMT > 42 ObjHeader c Server: Apache > 42 ObjHeader c Last-Modified: Wed, 17 Oct 2012 11:11:56 GMT > 42 ObjHeader c Accept-Ranges: bytes > 42 ObjHeader c Cache-Control: max-age=3600 > 42 ObjHeader c Expires: Thu, 18 Oct 2012 14:31:11 GMT > 42 ObjHeader c Vary: Accept-Encoding > 42 ObjHeader c Content-Type: image/jpeg > 42 ObjHeader c X-Yottaa-Optimizations: ob/0 si/1333429556 > ts/1350562509213 > 42 ObjHeader c Content-Encoding: gzip > 42 ObjHeader c X-Yottaa-Metrics: 01216b174f46/[194,191,-] > 01116b172e2c/[199,198,-] > 42 ObjHeader c x-host: system-2.yottaa.net > 42 VCL_call c deliver deliver > 42 TxProtocol c HTTP/1.1 > 42 TxStatus c 200 > 42 TxResponse c OK > 42 TxHeader c Server: Apache > 42 TxHeader c Last-Modified: Wed, 17 Oct 2012 11:11:56 GMT > 42 TxHeader c Accept-Ranges: bytes > 42 TxHeader c Cache-Control: max-age=3600 > 42 TxHeader c Expires: Thu, 18 Oct 2012 14:31:11 GMT > 42 TxHeader c Vary: Accept-Encoding > 42 TxHeader c Content-Type: image/jpeg > 42 TxHeader c X-Yottaa-Optimizations: ob/0 si/1333429556 > ts/1350562509213 > 42 TxHeader c Content-Encoding: gzip > 42 TxHeader c X-Yottaa-Metrics: 01216b174f46/[194,191,-] > 01116b172e2c/[199,198,-] > 42 TxHeader c Transfer-Encoding: chunked > 42 TxHeader c Date: Thu, 18 Oct 2012 13:31:11 GMT > 42 TxHeader c Age: 0 > 42 TxHeader c Connection: keep-alive > 42 Traffic c traffic stats, > host:********.com,requests:1,traffic:472,is_https:0,state:0 > 42 Traffic c message_bytes:472 > 42 Traffic c traffic stats, > host:********.com,requests:0,traffic:8192,is_https:0,state:1 > 42 Traffic c message_bytes:8192 > 42 FetchError c Invalid Gzip data: incorrect header check > 42 FetchError c chunked read_error: 0 (See other message) > 42 Gzip c u F - 2 0 0 0 0 > 42 Length c 0 > 42 ReqEnd c 1333429556 1350567071.527108192 1350567071.727841377 > 0.000091314 0.199551105 0.001182079 > 42 SessionClose c Stream error > 42 StatSess c 68.232.37.192 53862 0 1 1 0 0 1 472 0 New description: Stream is enabled to forward response ASAP. log below, i removed the host name because of potential business secret policy. {{{ 79 TxRequest b GET 79 TxURL b /504403b47a6c8777da011aaf/*******.com/v~80/_images/collections/3/4856.jpg 79 TxProtocol b HTTP/1.1 79 TxHeader b Host: system-2.yottaa.net 79 TxHeader b User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 Safari/536.26.14 79 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 79 TxHeader b Accept-Language: en-us 79 TxHeader b Cookie: yvts=1350566984282; km_ai=6SqgaCrNmzK%2FyJRnVEWlkrbiNBE%3D; km_lv=1348671534; km_uq=; mp_3aa8ae394f21ef02134f93c80b02d5bd_mixpanel=%7B%22distinct_id%22%3A%20%2213a03166e738a7-05067b594-376c6050-1fa400-13a03166e741115%22%2C%22%24initial_referrer%22 79 TxHeader b X-Host: s-ff0102-504403b47a6c8777da011aaf-0.yottaa.net 79 TxHeader b X-Forwarded-Proto: http 79 TxHeader b Via: HTTP/1.1 ECS (jfk/25C0) 79 TxHeader b X-Forwarded-For: 70.109.156.55, 68.232.37.192 79 TxHeader b X-Yottaa-SessionId: 1333429556 79 TxHeader b Accept-Encoding: gzip 79 RxProtocol b HTTP/1.1 79 RxStatus b 200 79 RxResponse b OK 79 RxHeader b Date: Thu, 18 Oct 2012 13:31:11 GMT 79 RxHeader b Server: Apache 79 RxHeader b Last-Modified: Wed, 17 Oct 2012 11:11:56 GMT 79 RxHeader b Accept-Ranges: bytes 79 RxHeader b Cache-Control: max-age=3600 79 RxHeader b Expires: Thu, 18 Oct 2012 14:31:11 GMT 79 RxHeader b Vary: Accept-Encoding 79 RxHeader b Keep-Alive: timeout=15, max=92 79 RxHeader b Content-Type: image/jpeg 79 RxHeader b X-Yottaa-Optimizations: ob/0 si/1333429556 ts/1350562509213 79 RxHeader b Content-Encoding: gzip 79 RxHeader b X-Yottaa-Metrics: 01216b174f46/[194,191,-] 01116b172e2c/[199,198,-] 79 RxHeader b Transfer-Encoding: chunked 79 RxHeader b Connection: keep-alive 79 Fetch_Body b 3(chunked) cls -1 mklen 1 79 BackendClose b a 42 SessionOpen c 68.232.37.192 53862 :80 42 ReqStart c 68.232.37.192 53862 1333429556 42 RxRequest c GET 42 RxURL c /504403b47a6c8777da011aaf/********.com/v~80/_images/collections/3/4856.jpg 42 RxProtocol c HTTP/1.1 42 RxHeader c Host: system-2.yottaa.net 42 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 Safari/536.26.14 42 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 42 RxHeader c Accept-Language: en-us 42 RxHeader c Accept-Encoding: gzip, deflate 42 RxHeader c Cookie: yvts=1350566984282; km_ai=6SqgaCrNmzK%2FyJRnVEWlkrbiNBE%3D; km_lv=1348671534; km_uq=; mp_3aa8ae394f21ef02134f93c80b02d5bd_mixpanel=%7B%22distinct_id%22%3A%20%2213a03166e738a7-05067b594-376c6050-1fa400-13a03166e741115%22%2C%22%24initial_referrer%22 42 RxHeader c X-Forwarded-For: 70.109.156.55 42 RxHeader c X-Host: s-ff0102-504403b47a6c8777da011aaf-0.yottaa.net 42 RxHeader c X-Forwarded-Proto: http 42 RxHeader c Via: HTTP/1.1 ECS (jfk/25C0) 42 VCL_call c recv lookup 42 VCL_call c hash 42 Hash c /504403b47a6c8777da011aaf/********.com/v~80/_images/collections/3/4856.jpg 42 Hash c system-2.yottaa.net 42 Hash c http 42 VCL_return c hash 42 VCL_call c miss fetch 42 Backend c 79 yo a 42 TTL c 1333429556 RFC 3600 -1 -1 1350567072 0 1350567071 1350570671 3600 42 VCL_call c fetch 42 TTL c 1333429556 VCL 3600 3600 -1 1350567072 -0 42 VCL_Log c enter fetch 42 VCL_Log c streaming enabled. 42 TTL c 1333429556 VCL -1 -1 -1 1350567072 -0 42 VCL_return c hit_for_pass 42 ObjProtocol c HTTP/1.1 42 ObjResponse c OK 42 ObjHeader c Date: Thu, 18 Oct 2012 13:31:11 GMT 42 ObjHeader c Server: Apache 42 ObjHeader c Last-Modified: Wed, 17 Oct 2012 11:11:56 GMT 42 ObjHeader c Accept-Ranges: bytes 42 ObjHeader c Cache-Control: max-age=3600 42 ObjHeader c Expires: Thu, 18 Oct 2012 14:31:11 GMT 42 ObjHeader c Vary: Accept-Encoding 42 ObjHeader c Content-Type: image/jpeg 42 ObjHeader c X-Yottaa-Optimizations: ob/0 si/1333429556 ts/1350562509213 42 ObjHeader c Content-Encoding: gzip 42 ObjHeader c X-Yottaa-Metrics: 01216b174f46/[194,191,-] 01116b172e2c/[199,198,-] 42 ObjHeader c x-host: system-2.yottaa.net 42 VCL_call c deliver deliver 42 TxProtocol c HTTP/1.1 42 TxStatus c 200 42 TxResponse c OK 42 TxHeader c Server: Apache 42 TxHeader c Last-Modified: Wed, 17 Oct 2012 11:11:56 GMT 42 TxHeader c Accept-Ranges: bytes 42 TxHeader c Cache-Control: max-age=3600 42 TxHeader c Expires: Thu, 18 Oct 2012 14:31:11 GMT 42 TxHeader c Vary: Accept-Encoding 42 TxHeader c Content-Type: image/jpeg 42 TxHeader c X-Yottaa-Optimizations: ob/0 si/1333429556 ts/1350562509213 42 TxHeader c Content-Encoding: gzip 42 TxHeader c X-Yottaa-Metrics: 01216b174f46/[194,191,-] 01116b172e2c/[199,198,-] 42 TxHeader c Transfer-Encoding: chunked 42 TxHeader c Date: Thu, 18 Oct 2012 13:31:11 GMT 42 TxHeader c Age: 0 42 TxHeader c Connection: keep-alive 42 Traffic c traffic stats, host:********.com,requests:1,traffic:472,is_https:0,state:0 42 Traffic c message_bytes:472 42 Traffic c traffic stats, host:********.com,requests:0,traffic:8192,is_https:0,state:1 42 Traffic c message_bytes:8192 42 FetchError c Invalid Gzip data: incorrect header check 42 FetchError c chunked read_error: 0 (See other message) 42 Gzip c u F - 2 0 0 0 0 42 Length c 0 42 ReqEnd c 1333429556 1350567071.527108192 1350567071.727841377 0.000091314 0.199551105 0.001182079 42 SessionClose c Stream error 42 StatSess c 68.232.37.192 53862 0 1 1 0 0 1 472 0 }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 19 12:23:26 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Oct 2012 12:23:26 -0000 Subject: [Varnish] #1215: cache object stub In-Reply-To: <047.11ae9a7f8310cf1f2f74afe7341507cb@varnish-cache.org> References: <047.11ae9a7f8310cf1f2f74afe7341507cb@varnish-cache.org> Message-ID: <062.1314b2a7080202f77163c843cb8327ee@varnish-cache.org> #1215: cache object stub -----------------------+-------------------- Reporter: stavrinov | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by stavrinov): In this state storage become totally broken and after few requests varnish shut down: Panic message: Assert error in smp_oc_getobj(), storage_persistent_silo.c line 400:#012 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Oct 20 10:32:12 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 20 Oct 2012 10:32:12 -0000 Subject: [Varnish] #1214: s_bodybytes and range: header issue In-Reply-To: <044.a58f5d0e9a88ea3d4b7ad9a85cf21498@varnish-cache.org> References: <044.a58f5d0e9a88ea3d4b7ad9a85cf21498@varnish-cache.org> Message-ID: <059.9f5e072ad4f14c384617add662082fd1@varnish-cache.org> #1214: s_bodybytes and range: header issue ------------------------------------+-------------------- Reporter: emilio | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: s_bodybytes range: 206 | ------------------------------------+-------------------- Comment (by emilio): I made some more test and the problem is more generic than I wrote before: I have the same problem without the range: header... if I try downloading a file (let's say a 10 Mb file) s_bodybytes will be incremented by 10Mb even if I stop the download after a few bytes (of course if my client uses heavily the range: header to split a file in many chunks the overall stats will be more inaccurates) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 10:08:42 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 10:08:42 -0000 Subject: [Varnish] #1215: cache object stub In-Reply-To: <047.11ae9a7f8310cf1f2f74afe7341507cb@varnish-cache.org> References: <047.11ae9a7f8310cf1f2f74afe7341507cb@varnish-cache.org> Message-ID: <062.b8fa0ef742f62267a2b9384c7412d3bf@varnish-cache.org> #1215: cache object stub -----------------------+--------------------- Reporter: stavrinov | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -----------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 10:10:18 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 10:10:18 -0000 Subject: [Varnish] #1214: s_bodybytes and range: header issue In-Reply-To: <044.a58f5d0e9a88ea3d4b7ad9a85cf21498@varnish-cache.org> References: <044.a58f5d0e9a88ea3d4b7ad9a85cf21498@varnish-cache.org> Message-ID: <059.b839e452c4b7e06d77317bf908450f06@varnish-cache.org> #1214: s_bodybytes and range: header issue ------------------------------------+--------------------- Reporter: emilio | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: s_bodybytes range: 206 | ------------------------------------+--------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 10:12:07 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 10:12:07 -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.fd4fc190057d18ec103d55080b84003f@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 | -------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 10:13:36 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 10:13:36 -0000 Subject: [Varnish] #1219: degraded speed with persistent storage In-Reply-To: <047.d33cc554f18272c8c3e85a89b7fa6dd4@varnish-cache.org> References: <047.d33cc554f18272c8c3e85a89b7fa6dd4@varnish-cache.org> Message-ID: <062.ef7334cd80720fe216a95430cbe0cec2@varnish-cache.org> #1219: degraded speed with persistent storage -----------------------+--------------------- Reporter: stavrinov | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -----------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 10:15:25 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 10:15:25 -0000 Subject: [Varnish] #1216: Bug:'error': not a valid action in method 'vcl_deliver'. In-Reply-To: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> References: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> Message-ID: <063.c59f83ab4a48daaf1522f850c3cb402c@varnish-cache.org> #1216: Bug:'error': not a valid action in method 'vcl_deliver'. ------------------------+-------------------- Reporter: z329224946 | Owner: daghf Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: Keywords: | ------------------------+-------------------- Changes (by tfheen): * owner: => daghf -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 10:26:10 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 10:26:10 -0000 Subject: [Varnish] #1166: Varnishadm throws an assert In-Reply-To: <051.5814c781387d31eb173c4ed622e0ca4c@varnish-cache.org> References: <051.5814c781387d31eb173c4ed622e0ca4c@varnish-cache.org> Message-ID: <066.f6c57f26310fdb176e7257bef37cbf61@varnish-cache.org> #1166: Varnishadm throws an assert ------------------------+--------------------- Reporter: rj@? | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishadm | Version: 3.0.2 Severity: normal | Resolution: Keywords: varnishadm | ------------------------+--------------------- Changes (by martin): * owner: => martin * status: reopened => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 10:28:05 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 10:28:05 -0000 Subject: [Varnish] #1210: Intermittent failure of tests/v00002.vtc In-Reply-To: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> References: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> Message-ID: <055.5588c8c16855964ba5e180b85dc895c8@varnish-cache.org> #1210: Intermittent failure of tests/v00002.vtc -------------------------+-------------------- Reporter: mi | Owner: phk Type: defect | Status: new Priority: low | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: Keywords: | -------------------------+-------------------- Changes (by phk): * status: reopened => new * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 10:34:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 10:34:00 -0000 Subject: [Varnish] #1207: varnishd child segfaults when using dns director In-Reply-To: <046.cbd6b84dea250737a025adc3c0105555@varnish-cache.org> References: <046.cbd6b84dea250737a025adc3c0105555@varnish-cache.org> Message-ID: <061.d407af3a066a9a3de45df999b0a7cbc8@varnish-cache.org> #1207: varnishd child segfaults when using dns director --------------------------+----------------------- Reporter: econnell | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: dns director | --------------------------+----------------------- Changes (by martin): * owner: => kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 10:36:40 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 10:36:40 -0000 Subject: [Varnish] #1195: varnishd child will not start In-Reply-To: <044.48db3ff1db939e16a6de9b07a5cee214@varnish-cache.org> References: <044.48db3ff1db939e16a6de9b07a5cee214@varnish-cache.org> Message-ID: <059.50c57c2a7a5c5a190c5a3e00af00acb7@varnish-cache.org> #1195: varnishd child will not start ---------------------------------------+------------------------- Reporter: chrcol | Owner: martin Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.2 Severity: critical | Resolution: worksforme Keywords: child process start crash | ---------------------------------------+------------------------- Changes (by martin): * status: new => closed * resolution: => worksforme Comment: Not been able to reproduce these findings, and no reply on requests for further information from the ticket submitter. Closing ticket. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 10:49:04 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 10:49:04 -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.169f3f446ddac8daa849f2b198f13565@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 martin): Hi, Exactly which version of Varnish are you using when seeing this? Is it the regular Varnish streaming fetch you are using? Or are you using the background thread streaming found in 3.0.2s (of 3.0.3-plus)? Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 11:37:38 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 11:37:38 -0000 Subject: [Varnish] #1213: varnishtop leaks file descriptors and deleted files In-Reply-To: <041.2d8171f36cc44c5bebb5df3eab15cbd1@varnish-cache.org> References: <041.2d8171f36cc44c5bebb5df3eab15cbd1@varnish-cache.org> Message-ID: <056.78c862524104d1eaa93976ee6851a4cc@varnish-cache.org> #1213: varnishtop leaks file descriptors and deleted files ------------------------+-------------------- Reporter: mha | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishtop | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ------------------------+-------------------- Comment (by Tollef Fog Heen ): In [7157107e77432bb6824899032a93ff1c742ca07f]: {{{ #!CommitTicketReference repository="" revision="7157107e77432bb6824899032a93ff1c742ca07f" Reopen log file in varnishtop if varnish restarts Use VSL_Dispatch instead of VSL_NextSLT in varnishtop, which does this automatically for us. Clean up accumulate() a bit in the process. Fixes #1213 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 22 11:37:39 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Oct 2012 11:37:39 -0000 Subject: [Varnish] #1213: varnishtop leaks file descriptors and deleted files In-Reply-To: <041.2d8171f36cc44c5bebb5df3eab15cbd1@varnish-cache.org> References: <041.2d8171f36cc44c5bebb5df3eab15cbd1@varnish-cache.org> Message-ID: <056.3d56b46aceef472c75797be8235fae3f@varnish-cache.org> #1213: varnishtop leaks file descriptors and deleted files ------------------------+--------------------- Reporter: mha | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtop | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [7157107e77432bb6824899032a93ff1c742ca07f]) Reopen log file in varnishtop if varnish restarts Use VSL_Dispatch instead of VSL_NextSLT in varnishtop, which does this automatically for us. Clean up accumulate() a bit in the process. Fixes #1213 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 23 10:44:30 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Oct 2012 10:44:30 -0000 Subject: [Varnish] #1221: 304 not modified response with body makes next request fail Message-ID: <046.ecb5a2da46fec560f98e7683b87fb29c@varnish-cache.org> #1221: 304 not modified response with body makes next request fail ------------------------------+-------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: 304 chunked body | ------------------------------+-------------------- If a backend sends a "304 not modified" response which includes a body, encoded as chunked, varnish logs body into garbage but next request fails with "http format error". Here are the logs: Request n?1 {{{ 588 TxRequest b GET 588 TxURL b /webmail/20121016184402/img/inbox_progressbar.png 588 TxProtocol b HTTP/1.1 588 TxHeader b Accept: */* 588 TxHeader b Accept-Language: fr-FR 588 TxHeader b User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Med 588 TxHeader b If-Modified-Since: Tue, 16 Oct 2012 16:46:10 GMT 588 TxHeader b Proxy-Connection: Keep-Alive 588 TxHeader b Host: xxx.s-sfr.fr 588 TxHeader b Cookie: _sm_au_c=iVVDKjVQjbQKkVrq0d 588 TxHeader b X-Forwarded-For: 77.242.201.53, 77.242.201.53 588 TxHeader b X-Varnish: 1284584803 588 RxProtocol b HTTP/1.1 588 RxStatus b 304 588 RxResponse b Not Modified 588 RxHeader b Server: Apache 588 RxHeader b Transfer-Encoding: chunked 588 RxHeader b Date: Tue, 23 Oct 2012 09:44:02 GMT 588 RxHeader b X-Varnish: 1153195315 588 RxHeader b Age: 0 588 RxHeader b Connection: keep-alive 588 RxHeader b Via: 1.1 varnish, 1.1 bou2-ncdn-cache06 588 Fetch_Body b 0(none) cls 0 mklen 0 588 Length b 0 588 BackendReuse b pop_storage }}} Capture with tcpdump, the backend response n?1: {{{ HTTP/1.1 304 Not Modified^M Server: Apache^M Transfer-Encoding: chunked^M Date: Tue, 23 Oct 2012 09:44:02 GMT^M X-Varnish: 1153195315^M Age: 0^M Connection: keep-alive^M Via: 1.1 varnish, 1.1 bou2-ncdn-cache06^M ^M 0^M ^M }}} Request n?2: {{{ 588 TxRequest b GET 588 TxURL b /192653626-bfm_business_1256k1376.ts 588 TxProtocol b HTTP/1.1 588 TxHeader b Host: xxx.sfr.fr 588 TxHeader b User-Agent: AppleCoreMedia/1.0.0.11E53 (Macintosh; U; Intel Mac OS X 10_7_4; fr_fr) 588 TxHeader b Accept: */* 588 TxHeader b X-Playback-Session-Id: 33105B46-96CF-4EB6-8EBA- 1D13D07FBBB5 588 TxHeader b X-Real-IP: 86.72.72.122 588 TxHeader b X-Forwarded-For: 86.72.72.122, 86.72.72.122 588 TxHeader b X-Varnish: 1284584825 588 TxHeader b Accept-Encoding: gzip 588 HttpGarbage b 0^M ^M 588 BackendClose b pop_storage 719 ReqStart c 86.72.72.122 51666 1284584825 719 RxRequest c GET 719 RxURL c /192653626-bfm_business_1256k1376.ts 719 RxProtocol c HTTP/1.1 719 RxHeader c Host: ncdn.adam.sfr.fr 719 RxHeader c User-Agent: AppleCoreMedia/1.0.0.11E53 (Macintosh; U; Intel Mac OS X 10_7_4; fr_fr) 719 RxHeader c Accept: */* 719 RxHeader c Accept-Encoding: identity 719 RxHeader c X-Playback-Session-Id: 33105B46-96CF-4EB6-8EBA- 1D13D07FBBB5 719 RxHeader c Cookie: session_id=601c; authent=JCvjFa5FRocCF2l; c_m=%5B%5BB%5D%5D; evar28=1_1349343177365_1929597724229097; ext_ref=; s_cc=true; s_pp 719 RxHeader c Connection: keep-alive 719 VCL_call c recv 719 VCL_Log c X-SessionId: 9569e746601c 719 VCL_Log c X-Backend: adam_director 719 VCL_return c lookup 719 VCL_call c hash 719 Hash c /192653626-bfm_business_1256k1376.ts 719 Hash c ncdn.adam.sfr.fr 719 VCL_return c hash 719 VCL_call c miss fetch 719 Backend c 588 ncdn_storage pop_storage 719 FetchError c http format error 719 VCL_call c error deliver 719 VCL_call c deliver deliver 719 TxProtocol c HTTP/1.1 719 TxStatus c 503 719 TxResponse c Service Unavailable 719 TxHeader c Server: Varnish 719 TxHeader c Content-Type: text/html; charset=utf-8 719 TxHeader c Retry-After: 5 719 TxHeader c Content-Length: 419 719 TxHeader c Accept-Ranges: bytes 719 TxHeader c Date: Tue, 23 Oct 2012 09:44:02 GMT 719 TxHeader c X-Varnish: 1284584825 719 TxHeader c Age: 0 719 TxHeader c Connection: close 719 TxHeader c Via: 1.1 varnish, 1.1 bou2-ncdn-cache00 719 Length c 419 719 ReqEnd c 1284584825 1350985442.104519367 1350985442.104895592 0.030051947 0.000344038 0.000032187 719 SessionClose c error 719 StatSess c 86.72.72.122 51666 0 1 2 0 1 1 693 632 }}} Backend response n?2: {{{ HTTP/1.1 200 OK^M Server: nginx/0.7.67^M Content-Type: application/octet-stream^M Last-Modified: Tue, 23 Oct 2012 09:43:57 GMT^M Content-Length: 1389712^M Accept-Ranges: bytes^M Date: Tue, 23 Oct 2012 09:44:02 GMT^M X-Varnish: 1153195320 1153195119^M Age: 2^M Connection: keep-alive^M Via: 1.1 varnish, 1.1 bou2-ncdn-cache06^M }}} So varnish takes garbage from the previous request as body of the second request. Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 23 13:31:24 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Oct 2012 13:31:24 -0000 Subject: [Varnish] #1221: 304 not modified response with body makes next request fail In-Reply-To: <046.ecb5a2da46fec560f98e7683b87fb29c@varnish-cache.org> References: <046.ecb5a2da46fec560f98e7683b87fb29c@varnish-cache.org> Message-ID: <061.9bc344b03014765e60abaa121bc026cd@varnish-cache.org> #1221: 304 not modified response with body makes next request fail ------------------------------+-------------------- Reporter: tmagnien | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: Keywords: 304 chunked body | ------------------------------+-------------------- Comment (by tmagnien): Here is the testcase : {{{ varnishtest "Bug #1221 '304 Not modified' with transfer-encoding chunked" # The first request, open the connection on the backend (the need a open # connection) # The second request, return a 304 with chunked encoding # The third failed. server s1 { rxreq txresp -body "cool" rxreq txresp -status 304 -nolen -hdr "Transfer-Encoding: chunked" chunkedlen 0 rxreq txresp -body "cool" } -start varnish v1 -vcl+backend { } -start client c1 { txreq -req GET -url /1 rxresp expect resp.status == 200 txreq -req GET -url /2 \ -hdr "If-Modified-Since: Tue, 16 Oct 2012 16:46:10 GMT" rxresp expect resp.status == 304 expect resp.bodylen == 0 txreq -req GET -url /3 rxresp expect resp.status == 200 } -run }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 24 13:23:33 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Oct 2012 13:23:33 -0000 Subject: [Varnish] #1222: std.collect() doesn't work on resp.http (e.g. in vcl_deliver) Message-ID: <042.c9461de71037fad1dbccd1350fff076f@varnish-cache.org> #1222: std.collect() doesn't work on resp.http (e.g. in vcl_deliver) -------------------+-------------------- Reporter: mark | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.3 | Severity: normal Keywords: | -------------------+-------------------- VMOD std's collect() function doesn't work on resp.http headers, so it cannot be used to cleanup headers to be sent to the client in vcl_deliver currently. Patch attached which fixes this for 3.0.3. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 24 14:42:24 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Oct 2012 14:42:24 -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.cff5fa87dc921c47663eb5dfb2dd46ad@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 jinjian.1@?): We are using varnish 3.0.2 regular streaming. Today we greped our log on production cluster, we found 141 such error in one hour's log. Is this an issue when varnish try to unzip the data? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 24 14:50:21 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Oct 2012 14:50:21 -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.9a2d407c930d2ce1904bb984cf8967be@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 jinjian.1@?): No matter the respose is chunked or not, we all could see such issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 26 00:33:15 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Oct 2012 00:33:15 -0000 Subject: [Varnish] #1223: Talking to local backend via PF_LOCAL Message-ID: <040.3b8e775d1b4e491d1a78f00efeae1c09@varnish-cache.org> #1223: Talking to local backend via PF_LOCAL -------------------+------------------------- Reporter: mi | Type: enhancement Status: new | Priority: low Milestone: | Component: varnishd Version: trunk | Severity: minor Keywords: | -------------------+------------------------- It would seem, running Varnish on the same host as the web-server is a fairly common use-case. Indeed, the pkg-message of FreeBSD's www/varnish explains how to quickly set up the proxy in such a manner, when one is getting slashdotted :-) However, the best currently-available way to set such coexistence up is via localhost. I'd like to suggest, Varnish allowed backends of the PF_LOCAL type. To start, it can simply treat backend.host as a local path, when the string begins with '/'. I started hacking up a patch, but got bogged down... Do others think, it may be a good idea? If Varnish offered such functionality, I may be able to hack Apache to allow it to "listen" on such ports and try to come up with some benchmarks... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 26 10:33:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Oct 2012 10:33:52 -0000 Subject: [Varnish] #1224: Long backend name asserts the varnishd child Message-ID: <046.c4f71086627c182e1c792186110e4c5e@varnish-cache.org> #1224: Long backend name asserts the varnishd child ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Keywords: ----------------------+------------------- If a user creates a VCL with a backend name which is really long, the VCL compiler happily compiles the VCL but the Varnish child process asserts. According to the source the limit is 44 characters. (untested) {{{ lkarsten at immer:~$ cat longname.vcl backend abcdefghijklmnopqrstuvwxyz__abcdefghijklmnopqrstuvwxyz { .host="127.0.0.1"; .port="8080"; } sub vcl_recv { error 200 "OK"; } }}} When running varnishd: {{{ lkarsten at immer:~$ /opt/varnish/sbin/varnishd -n fo -F -a :1400 -f longname.vcl Message from dlopen: Not running as root, no priv-sep child (2384) Started Pushing vcls failed: CLI communication error (hdr) Stopping Child Child (2384) died signal=6 Child (2384) Panic message: Assert error in VSM__Alloc(), vsm.c line 185: Condition(snprintf(sha->ident, sizeof sha->ident, "%s", ident) < sizeof sha->ident) not true. thread = (cache-main) ident = Linux,3.2.0-3-amd64,x86_64,-sfile,-smalloc,-hcritbit,no_waiter Backtrace: 0x43ce88: pan_backtrace+28 0x43d17a: pan_ic+1bd 0x46b557: VSM__Alloc+2d6 0x4443c2: VSM_Alloc+78 0x4134b9: VBE_AddBackend+433 0x41284b: VRT_init_dir_simple+1b6 0x4139b6: VRT_init_dir+95 0x7fa1a87fc843: _end+7fa1a815cad3 0x4456d3: VCL_Load+244 0x445cd5: ccf_config_load+87 Child (-1) said Not running as root, no priv-sep Child (-1) said Child starts Child (-1) said SMF.s0 mmap'ed 104857600 bytes of 104857600 Child cleanup complete manager dies }} Discovered by Abhishek Kumar. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 26 10:39:20 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Oct 2012 10:39:20 -0000 Subject: [Varnish] #1224: Long backend name asserts the varnishd child In-Reply-To: <046.c4f71086627c182e1c792186110e4c5e@varnish-cache.org> References: <046.c4f71086627c182e1c792186110e4c5e@varnish-cache.org> Message-ID: <061.1f57c9003d895c77a7754ea7ecdec208@varnish-cache.org> #1224: Long backend name asserts the varnishd child ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Description changed by lkarsten: Old description: > If a user creates a VCL with a backend name which is really long, the VCL > compiler happily compiles the VCL but the Varnish child process asserts. > > According to the source the limit is 44 characters. (untested) > > {{{ > lkarsten at immer:~$ cat longname.vcl > > backend abcdefghijklmnopqrstuvwxyz__abcdefghijklmnopqrstuvwxyz { > .host="127.0.0.1"; .port="8080"; } > > sub vcl_recv { > error 200 "OK"; > } > }}} > > When running varnishd: > {{{ > lkarsten at immer:~$ /opt/varnish/sbin/varnishd -n fo -F -a :1400 -f > longname.vcl > > Message from dlopen: > Not running as root, no priv-sep > child (2384) Started > Pushing vcls failed: > CLI communication error (hdr) > Stopping Child > Child (2384) died signal=6 > Child (2384) Panic message: Assert error in VSM__Alloc(), vsm.c line 185: > Condition(snprintf(sha->ident, sizeof sha->ident, "%s", ident) < sizeof > sha->ident) not true. > thread = (cache-main) > ident = Linux,3.2.0-3-amd64,x86_64,-sfile,-smalloc,-hcritbit,no_waiter > Backtrace: > 0x43ce88: pan_backtrace+28 > 0x43d17a: pan_ic+1bd > 0x46b557: VSM__Alloc+2d6 > 0x4443c2: VSM_Alloc+78 > 0x4134b9: VBE_AddBackend+433 > 0x41284b: VRT_init_dir_simple+1b6 > 0x4139b6: VRT_init_dir+95 > 0x7fa1a87fc843: _end+7fa1a815cad3 > 0x4456d3: VCL_Load+244 > 0x445cd5: ccf_config_load+87 > > Child (-1) said Not running as root, no priv-sep > Child (-1) said Child starts > Child (-1) said SMF.s0 mmap'ed 104857600 bytes of 104857600 > Child cleanup complete > manager dies > }} > > Discovered by Abhishek Kumar. New description: If a user creates a VCL with a backend name which is really long, the VCL compiler happily compiles the VCL but the Varnish child process asserts. According to the source the limit is 44 characters. (untested) {{{ lkarsten at immer:~$ cat longname.vcl backend abcdefghijklmnopqrstuvwxyz__abcdefghijklmnopqrstuvwxyz { .host="127.0.0.1"; .port="8080"; } sub vcl_recv { error 200 "OK"; } }}} When running varnishd: {{{ lkarsten at immer:~$ /opt/varnish/sbin/varnishd -n fo -F -a :1400 -f longname.vcl Message from dlopen: Not running as root, no priv-sep child (2384) Started Pushing vcls failed: CLI communication error (hdr) Stopping Child Child (2384) died signal=6 Child (2384) Panic message: Assert error in VSM__Alloc(), vsm.c line 185: Condition(snprintf(sha->ident, sizeof sha->ident, "%s", ident) < sizeof sha->ident) not true. thread = (cache-main) ident = Linux,3.2.0-3-amd64,x86_64,-sfile,-smalloc,-hcritbit,no_waiter Backtrace: 0x43ce88: pan_backtrace+28 0x43d17a: pan_ic+1bd 0x46b557: VSM__Alloc+2d6 0x4443c2: VSM_Alloc+78 0x4134b9: VBE_AddBackend+433 0x41284b: VRT_init_dir_simple+1b6 0x4139b6: VRT_init_dir+95 0x7fa1a87fc843: _end+7fa1a815cad3 0x4456d3: VCL_Load+244 0x445cd5: ccf_config_load+87 Child (-1) said Not running as root, no priv-sep Child (-1) said Child starts Child (-1) said SMF.s0 mmap'ed 104857600 bytes of 104857600 Child cleanup complete manager dies }}} Discovered by Abhishek Kumar. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 26 11:02:01 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Oct 2012 11:02:01 -0000 Subject: [Varnish] #1217: compress with ttl=0 returns invalid content-length In-Reply-To: <047.51edc8834c8b776fe852c4ea9225ca1d@varnish-cache.org> References: <047.51edc8834c8b776fe852c4ea9225ca1d@varnish-cache.org> Message-ID: <062.3696bd0ef159b90762fffcca9d8f9f42@varnish-cache.org> #1217: compress with ttl=0 returns invalid content-length -----------------------+-------------------- Reporter: prymitive | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by prymitive): This is probably backend issue -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 26 11:03:29 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Oct 2012 11:03:29 -0000 Subject: [Varnish] #1224: Long backend name asserts the varnishd child In-Reply-To: <046.c4f71086627c182e1c792186110e4c5e@varnish-cache.org> References: <046.c4f71086627c182e1c792186110e4c5e@varnish-cache.org> Message-ID: <061.863d1be79ff5a4f106a435da074be87d@varnish-cache.org> #1224: Long backend name asserts the varnishd child ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): Scoof points out that it might be related to #1144. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 08:43:41 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 08:43:41 -0000 Subject: [Varnish] #1216: Bug:'error': not a valid action in method 'vcl_deliver'. In-Reply-To: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> References: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> Message-ID: <063.6720dda565f2cc92080ac07291ddd701@varnish-cache.org> #1216: Bug:'error': not a valid action in method 'vcl_deliver'. ------------------------+-------------------- Reporter: z329224946 | Owner: daghf Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: Keywords: | ------------------------+-------------------- Comment (by daghf): This is a documentation issue. Thanks to Federico G. Schwindt for providing a patch. That said - do you have a specific use case for a problem that cannot be solved without doing error from vcl_deliver? The reason error from vcl_deliver is invalid is because vcl_error goes to vcl_deliver, so one might end up with unwanted looping. Rather than adding in extra complexity for dealing with this, it is simply decided that you can't error from vcl_deliver. The typical "hack"/workaround for this is to set some flag like req.http.x -do-error, issue a return(restart) and then error from vcl_recv. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 09:00:23 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 09:00:23 -0000 Subject: [Varnish] #1216: Bug:'error': not a valid action in method 'vcl_deliver'. In-Reply-To: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> References: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> Message-ID: <063.a130ce83f4e12f3901f3bc3f27d7c38f@varnish-cache.org> #1216: Bug:'error': not a valid action in method 'vcl_deliver'. ------------------------+-------------------- Reporter: z329224946 | Owner: daghf Type: defect | Status: new Priority: highest | Milestone: Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: Keywords: | ------------------------+-------------------- Comment (by Dag Haavi Finstad ): In [ee1af675bab963920014e60d1076042ae6c7caea]: {{{ #!CommitTicketReference repository="" revision="ee1af675bab963920014e60d1076042ae6c7caea" Documentation fix for error in vcl_deliver. Fixed by: Federico G. Schwindt Fixes: #1216 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 09:00:26 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 09:00:26 -0000 Subject: [Varnish] #1216: Bug:'error': not a valid action in method 'vcl_deliver'. In-Reply-To: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> References: <048.d46ca20c3103a652481aa50bc7738177@varnish-cache.org> Message-ID: <063.a937e22c9dcf9e7eed5f59ba7255c9b8@varnish-cache.org> #1216: Bug:'error': not a valid action in method 'vcl_deliver'. ------------------------+--------------------- Reporter: z329224946 | Owner: daghf Type: defect | Status: closed Priority: highest | Milestone: Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: fixed Keywords: | ------------------------+--------------------- Changes (by Dag Haavi Finstad ): * status: new => closed * resolution: => fixed Comment: (In [ee1af675bab963920014e60d1076042ae6c7caea]) Documentation fix for error in vcl_deliver. Fixed by: Federico G. Schwindt Fixes: #1216 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 09:36:06 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 09:36:06 -0000 Subject: [Varnish] #1217: compress with ttl=0 returns invalid content-length In-Reply-To: <047.51edc8834c8b776fe852c4ea9225ca1d@varnish-cache.org> References: <047.51edc8834c8b776fe852c4ea9225ca1d@varnish-cache.org> Message-ID: <062.60cd0e3b015c7176bb4f9535ae9abc1b@varnish-cache.org> #1217: compress with ttl=0 returns invalid content-length -----------------------+-------------------- Reporter: prymitive | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by daghf): I have not been able to reproduce this. Could you perhaps provide some more detail, e.g. relevant varnishlog output? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 09:39:02 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 09:39:02 -0000 Subject: [Varnish] #1217: compress with ttl=0 returns invalid content-length In-Reply-To: <047.51edc8834c8b776fe852c4ea9225ca1d@varnish-cache.org> References: <047.51edc8834c8b776fe852c4ea9225ca1d@varnish-cache.org> Message-ID: <062.0fcf7cff9c93d22844357294ba1f18a7@varnish-cache.org> #1217: compress with ttl=0 returns invalid content-length -----------------------+-------------------- Reporter: prymitive | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by prymitive): As I said in first comment this is probably backend issue (uWSGI, https://github.com/unbit/uwsgi/issues/22), but I can't close this ticket. Sorry for the noise. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 11:11:48 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 11:11:48 -0000 Subject: [Varnish] #1021: varnishtop -1 takes a long time to run In-Reply-To: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> References: <042.f53afc6d35433ecef5894155802a4d56@varnish-cache.org> Message-ID: <057.6fdb761b9c438560fa89197714e9f154@varnish-cache.org> #1021: varnishtop -1 takes a long time to run ------------------------+--------------------- Reporter: yves | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: Keywords: varnishlog | ------------------------+--------------------- Changes (by phk): * owner: => martin Comment: This may be because of the way the VSL api works. If it is kept busy, the varnishtop program may not notice that a second has expired. This should go into the VSL API redesign/rewrite which Martin works on. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 11:12:07 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 11:12:07 -0000 Subject: [Varnish] #1052: Persistent storage: less scary message when a silo is freshly created In-Reply-To: <046.a299a393f221b68cf1b4dd30204576e2@varnish-cache.org> References: <046.a299a393f221b68cf1b4dd30204576e2@varnish-cache.org> Message-ID: <061.ad09590bcba1ec563db710f5f927286a@varnish-cache.org> #1052: Persistent storage: less scary message when a silo is freshly created -------------------------+--------------------- Reporter: dumbbell | Owner: martin Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: trivial | Resolution: Keywords: | -------------------------+--------------------- Changes (by phk): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 11:17:10 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 11:17:10 -0000 Subject: [Varnish] #1083: Persistent Varnish crashes since using bans and lurker In-Reply-To: <049.21c55906d3bd67b40377e9353f5dd9ce@varnish-cache.org> References: <049.21c55906d3bd67b40377e9353f5dd9ce@varnish-cache.org> Message-ID: <064.d3df1f250518bf2cc5c273f376933755@varnish-cache.org> #1083: Persistent Varnish crashes since using bans and lurker -------------------------+--------------------- Reporter: rmohrbacher | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 3.0.2 Severity: major | Resolution: Keywords: | -------------------------+--------------------- Changes (by phk): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 11:18:02 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 11:18:02 -0000 Subject: [Varnish] #1083: Persistent Varnish crashes since using bans and lurker In-Reply-To: <049.21c55906d3bd67b40377e9353f5dd9ce@varnish-cache.org> References: <049.21c55906d3bd67b40377e9353f5dd9ce@varnish-cache.org> Message-ID: <064.6bb13ed951015422d7362dfc8053c98e@varnish-cache.org> #1083: Persistent Varnish crashes since using bans and lurker -------------------------+--------------------- Reporter: rmohrbacher | Owner: martin Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 3.0.2 Severity: major | Resolution: Keywords: | -------------------------+--------------------- Description changed by tfheen: Old description: > We use a farm with three persistent Varnishes (-s > persistent,/cms/varnish_cache/persistent/varnish_storage.bin,204800M"). > > This Varnishes runs since 3 months without any crashes (in the moment not > in production, but stressed with several stress tests). > > Since some days, we use bans and the lurker process (lurker-friendly bans > via: ban("obj.http.x-url ~ " + req.url); > We have about 250 bans/hour. > > Now we have the big problem, that the varnishes crashes after some hours. > Curios: all three Varnishes crashes in the same moment. And they runs on > three different Servers! > > The follow part from syslog suggest, that there is an problem with an > invalid ban: > > Jan 9 19:40:32 ece-fe1 /var/lib/varnish/persistent[19622]: Child (19623) > said CHK(0x7f91ffd261a0 BAN 2 0x7f34724f4000 ) = 1 > Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (19623) > died signal=6 > Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (19623) > Panic message: Missing errorhandling code in smp_append_sign(), > storage_persistent_subr.c line 128:#012 Condition((smp_chk_sign(ctx)) == > 0) not true.thread = (cache-worker)#012ident = > Linux,2.6.32-131.2.1.el6.x86_64,x86_64,-spersistent,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x42c7a6: /usr/sbin/varnishd() [0x42c7a6]#012 0x44a346: > /usr/sbin/varnishd(smp_append_sign+0x126) [0x44a346]#012 0x447b6d: > /usr/sbin/varnishd(SMP_NewBan+0x3d) [0x447b6d]#012 0x4125c7: > /usr/sbin/varnishd(BAN_Insert+0x1a7) [0x4125c7]#012 0x433bd5: > /usr/sbin/varnishd(VRT_ban_string+0xc5) [0x433bd5]#012 0x7f91f39fa4be: > ./vcl.PNU3fGhs.so(+0x24be) [0x7f91f39fa4be]#012 0x433863: > /usr/sbin/varnishd(VCL_recv_method+0x43) [0x433863]#012 0x417c22: > /usr/sbin/varnishd(CNT_Session+0xb62) [0x417c22]#012 0x42efb8: > /usr/sbin/varnishd() [0x42efb8]#012 0x42e19b: /usr/sbin/varnishd() > [0x42e19b]#012sp = 0x7f91ed4ab008 {#012 fd = 15, id = 15, xid = > 683670119,#012 client = 172.27.70.103 36115,#012 step = STP_RECV,#012 > handling = deliver,#012 restarts = 0, esi_level = 0#012 flags = #012 > bodystatus = 4#012 ws = 0x7f91ed4ab080 { #012 id = "sess",#012 > {s,f,r,e} = {0x7f91ed4abc90,+56,(nil),+65536},#012 },#012 http[req] = > {#012 ws = 0x7f91ed4ab080[sess]#012 "PURGE",#012 > "105867846",#012 "HTTP/1.0",#012 },#012 worker = 0x7f91ef1faa80 > {#012 ws = 0x7f91ef1facc0 { #012 id = "wrk",#012 {s,f,r,e} = > {0x7f91ef1e8a30,+32,(nil),+65536},#012 },#012 },#012 vcl = {#012 > srcname = {#012 "input",#012 "Default",#012 },#012 > },#012},#012 > Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: child (6907) > Started > Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Pushing vcls > failed:#012CLI communication error (hdr) > Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (6907) > died signal=6 > Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (6907) > Panic message: Assert error in smp_open(), storage_persistent.c line > 320:#012 Condition((smp_valid_silo(sc)) == 0) not true.#012thread = > (cache-main)#012ident = > Linux,2.6.32-131.2.1.el6.x86_64,x86_64,-spersistent,-smalloc,-hcritbit,no_waiter#012Backtrace:#012 > 0x42c7a6: /usr/sbin/varnishd() [0x42c7a6]#012 0x44756a: > /usr/sbin/varnishd() [0x44756a]#012 0x444d57: > /usr/sbin/varnishd(STV_open+0x27) [0x444d57]#012 0x42b525: > /usr/sbin/varnishd(child_main+0xc5) [0x42b525]#012 0x43d5ec: > /usr/sbin/varnishd() [0x43d5ec]#012 0x43de7c: /usr/sbin/varnishd() > [0x43de7c]#012 0x7f92015684c7: /usr/lib64/varnish/libvarnish.so(+0x94c7) > [0x7f92015684c7]#012 0x7f9201568b58: > /usr/lib64/varnish/libvarnish.so(vev_schedule+0x88) [0x7f9201568b58]#012 > 0x43d7c2: /usr/sbin/varnishd(MGT_Run+0x132) [0x43d7c2]#012 0x44cacb: > /usr/sbin/varnishd(main+0xd1b) [0x44cacb]#012 > Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (-1) > said Child starts > Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (-1) > said CHK(0x7f91ffd26120 BAN 1 0x7f34723f4000 BAN 1) = 4 > Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (-1) > said CHK(0x7f91ffd261a0 BAN 2 0x7f34724f4000 ) = 1 New description: We use a farm with three persistent Varnishes (-s persistent,/cms/varnish_cache/persistent/varnish_storage.bin,204800M"). This Varnishes runs since 3 months without any crashes (in the moment not in production, but stressed with several stress tests). Since some days, we use bans and the lurker process (lurker-friendly bans via: ban("obj.http.x-url ~ " + req.url); We have about 250 bans/hour. Now we have the big problem, that the varnishes crashes after some hours. Curios: all three Varnishes crashes in the same moment. And they runs on three different Servers! The follow part from syslog suggest, that there is an problem with an invalid ban: {{{ Jan 9 19:40:32 ece-fe1 /var/lib/varnish/persistent[19622]: Child (19623) said CHK(0x7f91ffd261a0 BAN 2 0x7f34724f4000 ) = 1 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (19623) died signal=6 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (19623) Panic message: Missing errorhandling code in smp_append_sign(), storage_persistent_subr.c line 128:#012 Condition((smp_chk_sign(ctx)) == 0) not true.thread = (cache-worker)#012ident = Linux,2.6.32-131.2.1.el6.x86_64,x86_64,-spersistent,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x42c7a6: /usr/sbin/varnishd() [0x42c7a6]#012 0x44a346: /usr/sbin/varnishd(smp_append_sign+0x126) [0x44a346]#012 0x447b6d: /usr/sbin/varnishd(SMP_NewBan+0x3d) [0x447b6d]#012 0x4125c7: /usr/sbin/varnishd(BAN_Insert+0x1a7) [0x4125c7]#012 0x433bd5: /usr/sbin/varnishd(VRT_ban_string+0xc5) [0x433bd5]#012 0x7f91f39fa4be: ./vcl.PNU3fGhs.so(+0x24be) [0x7f91f39fa4be]#012 0x433863: /usr/sbin/varnishd(VCL_recv_method+0x43) [0x433863]#012 0x417c22: /usr/sbin/varnishd(CNT_Session+0xb62) [0x417c22]#012 0x42efb8: /usr/sbin/varnishd() [0x42efb8]#012 0x42e19b: /usr/sbin/varnishd() [0x42e19b]#012sp = 0x7f91ed4ab008 {#012 fd = 15, id = 15, xid = 683670119,#012 client = 172.27.70.103 36115,#012 step = STP_RECV,#012 handling = deliver,#012 restarts = 0, esi_level = 0#012 flags = #012 bodystatus = 4#012 ws = 0x7f91ed4ab080 { #012 id = "sess",#012 {s,f,r,e} = {0x7f91ed4abc90,+56,(nil),+65536},#012 },#012 http[req] = {#012 ws = 0x7f91ed4ab080[sess]#012 "PURGE",#012 "105867846",#012 "HTTP/1.0",#012 },#012 worker = 0x7f91ef1faa80 {#012 ws = 0x7f91ef1facc0 { #012 id = "wrk",#012 {s,f,r,e} = {0x7f91ef1e8a30,+32,(nil),+65536},#012 },#012 },#012 vcl = {#012 srcname = {#012 "input",#012 "Default",#012 },#012 },#012},#012 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: child (6907) Started Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Pushing vcls failed:#012CLI communication error (hdr) Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (6907) died signal=6 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (6907) Panic message: Assert error in smp_open(), storage_persistent.c line 320:#012 Condition((smp_valid_silo(sc)) == 0) not true.#012thread = (cache-main)#012ident = Linux,2.6.32-131.2.1.el6.x86_64,x86_64,-spersistent,-smalloc,-hcritbit,no_waiter#012Backtrace:#012 0x42c7a6: /usr/sbin/varnishd() [0x42c7a6]#012 0x44756a: /usr/sbin/varnishd() [0x44756a]#012 0x444d57: /usr/sbin/varnishd(STV_open+0x27) [0x444d57]#012 0x42b525: /usr/sbin/varnishd(child_main+0xc5) [0x42b525]#012 0x43d5ec: /usr/sbin/varnishd() [0x43d5ec]#012 0x43de7c: /usr/sbin/varnishd() [0x43de7c]#012 0x7f92015684c7: /usr/lib64/varnish/libvarnish.so(+0x94c7) [0x7f92015684c7]#012 0x7f9201568b58: /usr/lib64/varnish/libvarnish.so(vev_schedule+0x88) [0x7f9201568b58]#012 0x43d7c2: /usr/sbin/varnishd(MGT_Run+0x132) [0x43d7c2]#012 0x44cacb: /usr/sbin/varnishd(main+0xd1b) [0x44cacb]#012 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (-1) said Child starts Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (-1) said CHK(0x7f91ffd26120 BAN 1 0x7f34723f4000 BAN 1) = 4 Jan 9 19:40:33 ece-fe1 /var/lib/varnish/persistent[19622]: Child (-1) said CHK(0x7f91ffd261a0 BAN 2 0x7f34724f4000 ) = 1 }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 11:22:31 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 11:22:31 -0000 Subject: [Varnish] #1077: "Assert error in smp_open_segs" panic with persistent storage In-Reply-To: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> References: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> Message-ID: <058.2a7bec04bc32b100d400efde7fa98d2b@varnish-cache.org> #1077: "Assert error in smp_open_segs" panic with persistent storage ----------------------+--------------------- Reporter: acdha | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: critical | Resolution: Keywords: | ----------------------+--------------------- Changes (by phk): * owner: phk => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 11:36:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 11:36:43 -0000 Subject: [Varnish] #1139: default_keep makes objects stay around too long In-Reply-To: <044.8c1a9c748ce289914d1adcd0203efe6a@varnish-cache.org> References: <044.8c1a9c748ce289914d1adcd0203efe6a@varnish-cache.org> Message-ID: <059.b9470be08525a064bff20b6ee5257be7@varnish-cache.org> #1139: default_keep makes objects stay around too long ----------------------+-------------------- Reporter: martin | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 11:36:56 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 11:36:56 -0000 Subject: [Varnish] #1130: varnishncsa -d makes it exit(0) after processing old entries In-Reply-To: <040.07815af94e0e42afed90f4fadb228259@varnish-cache.org> References: <040.07815af94e0e42afed90f4fadb228259@varnish-cache.org> Message-ID: <055.555ab27e2d2f652021eaf9926f7a4062@varnish-cache.org> #1130: varnishncsa -d makes it exit(0) after processing old entries -------------------------+-------------------- Reporter: bz | Owner: daghf Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 3.0.2 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Changes (by daghf): * owner: => daghf -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 11:46:08 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 11:46:08 -0000 Subject: [Varnish] #1170: varnishlog processes old entries on startup In-Reply-To: <052.c67882da1b5fc7914959e9ebd3d551c4@varnish-cache.org> References: <052.c67882da1b5fc7914959e9ebd3d551c4@varnish-cache.org> Message-ID: <067.d254180f4038b4a1b1ee41b2db88f705@varnish-cache.org> #1170: varnishlog processes old entries on startup ------------------------------+--------------------- Reporter: desperate_john | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: revision 7d9ca7d | ------------------------------+--------------------- Changes (by phk): * owner: => martin Comment: tested, trunk does this as of today. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 11:52:18 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 11:52:18 -0000 Subject: [Varnish] #1217: compress with ttl=0 returns invalid content-length In-Reply-To: <047.51edc8834c8b776fe852c4ea9225ca1d@varnish-cache.org> References: <047.51edc8834c8b776fe852c4ea9225ca1d@varnish-cache.org> Message-ID: <062.639c9b21d792a6cbf0dd2caac6e61e04@varnish-cache.org> #1217: compress with ttl=0 returns invalid content-length -----------------------+------------------------- Reporter: prymitive | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: worksforme Keywords: | -----------------------+------------------------- Changes (by daghf): * status: new => closed * resolution: => worksforme Comment: Alright, thanks for following up. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 20:35:50 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 20:35:50 -0000 Subject: [Varnish] #1170: varnishlog processes old entries on startup In-Reply-To: <052.c67882da1b5fc7914959e9ebd3d551c4@varnish-cache.org> References: <052.c67882da1b5fc7914959e9ebd3d551c4@varnish-cache.org> Message-ID: <067.ba41b1e374e7dad4f3b065b420334031@varnish-cache.org> #1170: varnishlog processes old entries on startup ------------------------------+--------------------- Reporter: desperate_john | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: revision 7d9ca7d | ------------------------------+--------------------- Comment (by Poul-Henning Kamp ): In [a3533dae312582657c519a9f8ce7da6d906ad53f]: {{{ #!CommitTicketReference repository="" revision="a3533dae312582657c519a9f8ce7da6d906ad53f" Remember to initialize the version number, so we don't start out processing all the old entries, unless -d was specified. Fixes #1170 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 20:35:51 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 20:35:51 -0000 Subject: [Varnish] #1170: varnishlog processes old entries on startup In-Reply-To: <052.c67882da1b5fc7914959e9ebd3d551c4@varnish-cache.org> References: <052.c67882da1b5fc7914959e9ebd3d551c4@varnish-cache.org> Message-ID: <067.cacb7434380bc0daaeaa896fc5ebc271@varnish-cache.org> #1170: varnishlog processes old entries on startup ------------------------------+--------------------- Reporter: desperate_john | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: revision 7d9ca7d | ------------------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [a3533dae312582657c519a9f8ce7da6d906ad53f]) Remember to initialize the version number, so we don't start out processing all the old entries, unless -d was specified. Fixes #1170 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 20:38:42 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 20:38:42 -0000 Subject: [Varnish] #1224: Long backend name asserts the varnishd child In-Reply-To: <046.c4f71086627c182e1c792186110e4c5e@varnish-cache.org> References: <046.c4f71086627c182e1c792186110e4c5e@varnish-cache.org> Message-ID: <061.0731ac6b50e72346bb85e39e53f6defe@varnish-cache.org> #1224: Long backend name asserts the varnishd child ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by phk): Correct, this is fixed in -trunk, see 1144 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 20:44:49 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 20:44:49 -0000 Subject: [Varnish] #1196: TEST ./tests/b00028.vtc FAILED In-Reply-To: <050.7dfb1133942f8dc4a563cd156da4525a@varnish-cache.org> References: <050.7dfb1133942f8dc4a563cd156da4525a@varnish-cache.org> Message-ID: <065.3c5838474e8eebbe89dc2b2164109c89@varnish-cache.org> #1196: TEST ./tests/b00028.vtc FAILED --------------------------+--------------------- Reporter: plamenpetrov | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | --------------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I think this is a spurious test-failure related to the PCRE JRE code which we have now disabled, for exactly this reason. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 20:48:28 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 20:48:28 -0000 Subject: [Varnish] #1210: Intermittent failure of tests/v00002.vtc In-Reply-To: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> References: <040.31a51481ec9dabf303613f9002721ca5@varnish-cache.org> Message-ID: <055.ecd046a60e7b69b188404d3de2f59b8b@varnish-cache.org> #1210: Intermittent failure of tests/v00002.vtc -------------------------+------------------------- Reporter: mi | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: worksforme Keywords: | -------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Sorry, I still don't see any signs of systematic failure in this. The Varnishtests are not 100% water-tight, in the sense that they are timing-sensitive, expect sufficient resources and can be made to fail for reasons related to this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 20:51:28 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 20:51:28 -0000 Subject: [Varnish] #1202: Test r01036.vtc warns of assertion-failure, but succeeds In-Reply-To: <040.6f79c78bd1b252d620cc7f7f25bb02b3@varnish-cache.org> References: <040.6f79c78bd1b252d620cc7f7f25bb02b3@varnish-cache.org> Message-ID: <055.84469d911c1f23c05b6a8a8710b5b34b@varnish-cache.org> #1202: Test r01036.vtc warns of assertion-failure, but succeeds -------------------------+--------------------- Reporter: mi | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: This was fixed in 6460036898caf29c6be27e5bec9722f27b5edf44 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:04:17 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:04:17 -0000 Subject: [Varnish] #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) In-Reply-To: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> References: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> Message-ID: <055.b9ca75789e8841fa83fdc6e49d15edf3@varnish-cache.org> #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) -------------------------+-------------------- Reporter: mi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by Poul-Henning Kamp ): In [f2367b221d99babf54ad8e565afeaf3ef107c40f]: {{{ #!CommitTicketReference repository="" revision="f2367b221d99babf54ad8e565afeaf3ef107c40f" Increase stack-size for the benefit of i386 Fixes #1201 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:04:19 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:04:19 -0000 Subject: [Varnish] #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) In-Reply-To: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> References: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> Message-ID: <055.72f3f9e479f01e2cb41f89f5b37f1673@varnish-cache.org> #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) -------------------------+--------------------- Reporter: mi | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [f2367b221d99babf54ad8e565afeaf3ef107c40f]) Increase stack-size for the benefit of i386 Fixes #1201 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:05:09 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:05:09 -0000 Subject: [Varnish] #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) In-Reply-To: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> References: <040.82b06dc48a52240ce65050f7e25e7021@varnish-cache.org> Message-ID: <055.bdfd8265b657f3d0e5029b164f75921b@varnish-cache.org> #1201: Test r01109.vtc reliably fails on FreeBSD (32bit) -------------------------+--------------------- Reporter: mi | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Comment (by phk): I don't see trouble on amd64, so I'm adding this fix and closing the ticket. Reopen if there is contrary information. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:13:37 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:13:37 -0000 Subject: [Varnish] #1223: Talking to local backend via PF_LOCAL In-Reply-To: <040.3b8e775d1b4e491d1a78f00efeae1c09@varnish-cache.org> References: <040.3b8e775d1b4e491d1a78f00efeae1c09@varnish-cache.org> Message-ID: <055.f5b339c771f6c8301311d2148a5da2ca@varnish-cache.org> #1223: Talking to local backend via PF_LOCAL -------------------------+---------------------- Reporter: mi | Owner: Type: enhancement | Status: closed Priority: low | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: invalid Keywords: | -------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: It is a good idea, that's why we've had it in our future plans literally forever [[Future_Feature]] but your patch is not enough to implement it. You should not overload the "hosthdr" field, it has valid uses even if the backend is on the same machine. We generally do not use our ticket system for enhancements or patch- management, so I'm closing this ticket, please mail future (preferably working :-) versions to the -dev mailing list where our patch-tracker will pick it up. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:33:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:33:52 -0000 Subject: [Varnish] #1199: c00045.vtc may fail intermittently depending on compiler and optimization In-Reply-To: <040.142f68a1a38937f0fa2e389fb4c02db6@varnish-cache.org> References: <040.142f68a1a38937f0fa2e389fb4c02db6@varnish-cache.org> Message-ID: <055.cf28eab71a2c896b33930e8df87537ab@varnish-cache.org> #1199: c00045.vtc may fail intermittently depending on compiler and optimization -------------------------+------------------------- Reporter: mi | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 3.0.3 Severity: minor | Resolution: worksforme Keywords: | -------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Make check is not a 100% deterministic test, and making it 100% deterministic is often a very tedious and time-consuming affair. In general I do not think that "make check" should be part of automated package building, but rather part of the manual QA process of the built packages. Maybe what we need is a version of "make check" which accepts a trivial number of failures, simply to cope with the non-determinism inherent in the tests execution ? Either way, I'm closing this ticket, as it is not actionable in any way I can see. If you see very high failure frequencies on specific tests, please let us know, and we will try to stabilize those, so we get high success rates from "make check", just don't expect us to reach 100%. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:44:54 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:44:54 -0000 Subject: [Varnish] #1070: varnishlog -k requires -O In-Reply-To: <046.5aa0fd0a659518b6d1c4b1f4337ca280@varnish-cache.org> References: <046.5aa0fd0a659518b6d1c4b1f4337ca280@varnish-cache.org> Message-ID: <061.bb6187a0ee29832a09ebf98d6207f55d@varnish-cache.org> #1070: varnishlog -k requires -O ------------------------+--------------------- Reporter: kristian | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ------------------------+--------------------- Changes (by phk): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:45:06 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:45:06 -0000 Subject: [Varnish] #1071: Varnishlog -m includes NOISE In-Reply-To: <046.9c810e03f23c7c76d4cf7a124260e531@varnish-cache.org> References: <046.9c810e03f23c7c76d4cf7a124260e531@varnish-cache.org> Message-ID: <061.e7b158e7b7c799674bf029289c36e843@varnish-cache.org> #1071: Varnishlog -m includes NOISE ------------------------+--------------------- Reporter: kristian | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ------------------------+--------------------- Changes (by phk): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:49:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:49:00 -0000 Subject: [Varnish] #1107: Add ignore_saintmode to req In-Reply-To: <044.55eb1578247b1b264abd611b623e69b7@varnish-cache.org> References: <044.55eb1578247b1b264abd611b623e69b7@varnish-cache.org> Message-ID: <059.dc3ede1545196f135c0d6ab9f005183b@varnish-cache.org> #1107: Add ignore_saintmode to req -------------------------------+---------------------- Reporter: ismell | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: saintmode restart | -------------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: I'm sorry for the delay on this ticket. We're sort of trying to get away from the "magic-knob" concept inherent in all the "do foobar" options, so I'm not really keen on this addition. We're currently discussing (low volume indeed) an idea for a new "vcl_lookup" method, where things like purge, grace and saint could be implemented in a more "VCL-like" way. I'd appreciate if we could find a way to roll this idea into that work, rather than add yet a magic knob. Finally, we don't use our ticket system for feature requests, (we have "patchwork" running on the -dev list for that now) so I'm closing this ticket as invalid. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:50:12 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:50:12 -0000 Subject: [Varnish] #1188: Assert error in hcb_insert(), hash_critbit.c line 212: Condition((y)->magic == 0x125c4bd2) not true. In-Reply-To: <043.ed04adf9eca4049815e8098fa06e0c6c@varnish-cache.org> References: <043.ed04adf9eca4049815e8098fa06e0c6c@varnish-cache.org> Message-ID: <058.ec62fea728908d2b0e5db897e9707d64@varnish-cache.org> #1188: Assert error in hcb_insert(), hash_critbit.c line 212: Condition((y)->magic == 0x125c4bd2) not true. ----------------------+------------------------- Reporter: flies | Owner: Type: defect | Status: closed Priority: lowest | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: timing out this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:54:44 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:54:44 -0000 Subject: [Varnish] #1221: 304 not modified response with body makes next request fail In-Reply-To: <046.ecb5a2da46fec560f98e7683b87fb29c@varnish-cache.org> References: <046.ecb5a2da46fec560f98e7683b87fb29c@varnish-cache.org> Message-ID: <061.5fed2956e9e446f8996304d924cc4cdd@varnish-cache.org> #1221: 304 not modified response with body makes next request fail ------------------------------+------------------------- Reporter: tmagnien | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: normal | Resolution: worksforme Keywords: 304 chunked body | ------------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: RFC2616 makes it painfully clear that this is a bug in the backends behaviour: [[[ 4.4 Message Length The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence): 1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message. ]]] I'm not quite sure if you can work around this from VCL, you probably can from inline-C or a VMOD by marking the backend connection as "to be closed" behind the back of the normal logic. If you want to write a patch which makes varnish detect this bogus behaviour, please submit it to the -dev mailing list, but put a reference to this ticket in the description, even though I am closing the ticket now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:56:35 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:56:35 -0000 Subject: [Varnish] #1186: Varnish crashing with "Assert error in hcb_insert(), hash_critbit.c line 217" In-Reply-To: <043.61629f460ae9ccde797d449c5dc85940@varnish-cache.org> References: <043.61629f460ae9ccde797d449c5dc85940@varnish-cache.org> Message-ID: <058.6928b0e4af38ab74eb3a60f9aabff3ab@varnish-cache.org> #1186: Varnish crashing with "Assert error in hcb_insert(), hash_critbit.c line 217" --------------------+------------------------ Reporter: flies | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.1.5 Severity: normal | Resolution: duplicate Keywords: | --------------------+------------------------ Changes (by phk): * status: new => closed * resolution: => duplicate Comment: This looks like a twin or duplicate of #1188 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 29 21:57:04 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Oct 2012 21:57:04 -0000 Subject: [Varnish] #1185: Assert error in VRT_IP_string(), cache/cache_vrt.c line 313 In-Reply-To: <046.e5c96159b15b686ce58184b16ef1fb92@varnish-cache.org> References: <046.e5c96159b15b686ce58184b16ef1fb92@varnish-cache.org> Message-ID: <061.726f419bec67db186c7a0cc682f3259d@varnish-cache.org> #1185: Assert error in VRT_IP_string(), cache/cache_vrt.c line 313 ----------------------+----------------------- Reporter: kristian | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Changes (by phk): * owner: => kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 31 14:39:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 31 Oct 2012 14:39:45 -0000 Subject: [Varnish] #1225: bans_req counter doesn't take into account bans loaded from persistent silos Message-ID: <044.c3e690e72f98e366d80cf1c56138fc63@varnish-cache.org> #1225: bans_req counter doesn't take into account bans loaded from persistent silos ----------------------+------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- On BAN_Reload, bans from persistent silos that references req.* values won't increment the bans_req counter. This causes the counter to wrap below zero when these bans are removed. See attached test case. -- Ticket URL: Varnish The Varnish HTTP Accelerator