From varnish-bugs at varnish-cache.org Mon Feb 1 01:54:41 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Feb 2016 01:54:41 -0000 Subject: [Varnish] #736: Migration to Cygwin plataform In-Reply-To: <043.2fae29ad1d069a3849cfd6e02ce26d66@varnish-cache.org> References: <043.2fae29ad1d069a3849cfd6e02ce26d66@varnish-cache.org> Message-ID: <058.1ec6887b1fff985b7e310303e24c9fa9@varnish-cache.org> #736: Migration to Cygwin plataform -----------------------------+---------------------- Reporter: jdzst | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: Severity: normal | Resolution: invalid Keywords: cygwin, windows | -----------------------------+---------------------- Comment (by Alex): [https://crooksandliars.com/user/buy-beats-online crooksandliars] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 1 13:56:58 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Feb 2016 13:56:58 -0000 Subject: [Varnish] #1794: varnish*-tools do not die when terminal disconnects In-Reply-To: <041.5e0136e0890c547547da2629f527e416@varnish-cache.org> References: <041.5e0136e0890c547547da2629f527e416@varnish-cache.org> Message-ID: <056.d4e56b32096620dc5b73593e115d80fc@varnish-cache.org> #1794: varnish*-tools do not die when terminal disconnects --------------------+--------------------------------------------- Reporter: kwy | Owner: Federico G. Schwindt Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 4.0.3 Severity: normal | Resolution: Keywords: | --------------------+--------------------------------------------- Comment (by martin): I have been discussing this issue with both Federico and Lasse, and these are the conclusions: * The current behaviour of exiting on sighup when in foreground mode is the correct one. * The main issue is for the startup scripts for running varnishlog and varnishncsa as daemons. These scripts are part of the packages. * The scripts want to start the utilities as the Varnish user (both because they shouldn't run as root, and because the need to be the Varnish user in order to get read access to the shmlog). * When running as the Varnish user, they utilities will not be able to write a PID file in /run, as /run is owned by root. This can be worked around by having the scripts prepare a /run/varnishutils directory owned by the Varnish user, and make the utils store the PID file in there. But the real issue is that the utils only implements half of what proper daemonizing programs should be doing. The utils should have user/group arguments and changed to that u/g upon daemonizing. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 1 14:33:05 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Feb 2016 14:33:05 -0000 Subject: [Varnish] #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. Message-ID: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. -------------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 4.1.1 Severity: normal | Keywords: -------------------------+------------------- In 4.1.1, varnishncsa and varnishncsa running from systemd will exit when receiving SIGHUP from (for example) logrotate. The official packaging for 4.1.1 runs varnishncsa and varnishlog in this mode. Expected: varnishncsa and varnishlog daemons not to stop unintentionally every night. In #1794 there is a discussion about SIGHUP handling, and that the tools exit successfully in SIGHUP if they are running in foreground mode. This means that -D must be used for daemons. Possible workarounds: * Moving back to -D, which means we need a varnish:varnishlog owned directory in /run to write to. * Extending the daemons with chuid/chgid support. Write pidfile before dropping privs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 1 15:36:44 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Feb 2016 15:36:44 -0000 Subject: [Varnish] #1851: Varnish 4.1.1 fails to build on i386 Message-ID: <042.3b3edf26ed9fdf5c93dfc7efdd85550f@varnish-cache.org> #1851: Varnish 4.1.1 fails to build on i386 -------------------+-------------------- Reporter: feld | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.1.1 | Severity: normal Keywords: | -------------------+-------------------- Varnish 4.1.1 fails to build on FreeBSD i386. Varnish 4.1.0 built successfully. {{{ CCLD varnishncsa_opt2rst gmake[4]: Leaving directory '/wrkdirs/usr/ports/www/varnish4/work/varnish-4.1.1/bin/varnishncsa' Making all in varnishstat gmake[4]: Entering directory '/wrkdirs/usr/ports/www/varnish4/work/varnish-4.1.1/bin/varnishstat' CC varnishstat.o CC varnishstat_curses.o varnishstat_curses.c:544:6: error: format specifies type 'unsigned long' but the argument has type 'int' [-Werror,-Wformat] t / 86400, (t % 86400) / 3600, (t % 3600) / 60, t % 60); ^~~~~~~~~ varnishstat_curses.c:544:17: error: format specifies type 'unsigned long' but the argument has type 'int' [-Werror,-Wformat] t / 86400, (t % 86400) / 3600, (t % 3600) / 60, t % 60); ^~~~~~~~~~~~~~~~~~ varnishstat_curses.c:544:37: error: format specifies type 'unsigned long' but the argument has type 'int' [-Werror,-Wformat] t / 86400, (t % 86400) / 3600, (t % 3600) / 60, t % 60); ^~~~~~~~~~~~~~~ varnishstat_curses.c:544:54: error: format specifies type 'unsigned long' but the argument has type 'int' [-Werror,-Wformat] t / 86400, (t % 86400) / 3600, (t % 3600) / 60, t % 60); ^~~~~~ 4 errors generated. Makefile:478: recipe for target 'varnishstat_curses.o' failed gmake[4]: *** [varnishstat_curses.o] Error 1 gmake[4]: Leaving directory '/wrkdirs/usr/ports/www/varnish4/work/varnish-4.1.1/bin/varnishstat' Makefile:400: recipe for target 'all-recursive' failed gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory '/wrkdirs/usr/ports/www/varnish4/work/varnish-4.1.1/bin' Makefile:533: recipe for target 'all-recursive' failed gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory '/wrkdirs/usr/ports/www/varnish4/work/varnish-4.1.1' Makefile:419: recipe for target 'all' failed gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/www/varnish4/work/varnish-4.1.1' *** Error code 1 Stop. make: stopped in /usr/ports/www/varnish4 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 1 16:53:59 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Feb 2016 16:53:59 -0000 Subject: [Varnish] #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. In-Reply-To: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> References: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> Message-ID: <061.15f656039c4f878ea4f1ea4a6a5dfa3a@varnish-cache.org> #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. -------------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 4.1.1 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by lkarsten): So far it looks like RuntimeDirectory is the best bet. (man systemd.exec) See https://github.com/varnishcache/pkg-varnish- cache/commit/95082859075ac97cb0fed8aa099cc998c5b80aa2 for implemented workaround. While going through the logrotate setup to make sure this works, I found that ownership of /var/log/varnish would be wrong in the default installation of 4.1 on EL7. This may also have been the case on EL6. Fix in https://github.com/varnishcache/pkg-varnish- cache/commit/07585b3a71140bb6ed5f0500d9545d09f2182021 . Installation from scratch, varnishncsa start and a logrotate run verified on EL6 and EL7. Planned for repo.v-c.o in 4.1.1-2. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 1 18:35:40 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Feb 2016 18:35:40 -0000 Subject: [Varnish] #1851: Varnish 4.1.1 fails to build on i386 In-Reply-To: <042.3b3edf26ed9fdf5c93dfc7efdd85550f@varnish-cache.org> References: <042.3b3edf26ed9fdf5c93dfc7efdd85550f@varnish-cache.org> Message-ID: <057.4ccfce1b77e66e54a16ad7973c004035@varnish-cache.org> #1851: Varnish 4.1.1 fails to build on i386 --------------------+--------------------------------------------- Reporter: feld | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.1.1 Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * status: new => closed * owner: => Federico G. Schwindt * resolution: => fixed Comment: In [6694bea3b2c0c4e6ef0cc723f03e07b1d9731502]: {{{ #!CommitTicketReference repository="" revision="6694bea3b2c0c4e6ef0cc723f03e07b1d9731502" Cast time_t to work with 32 bit time_t Fixes #1851. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 1 18:45:40 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Feb 2016 18:45:40 -0000 Subject: [Varnish] #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. In-Reply-To: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> References: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> Message-ID: <061.236f77b57ec20a1fc28955576460c661@varnish-cache.org> #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. -------------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 4.1.1 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by fgsch): This does break log rotation if the logrotate configuration is not updated. Shouldn't we go for a more conservative approach in this case an aim to fix this properly later? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 1 18:47:25 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Feb 2016 18:47:25 -0000 Subject: [Varnish] #1849: Panic running s00002.vtc on travis In-Reply-To: <043.a5a9edefc26b146b1981774bd9837b70@varnish-cache.org> References: <043.a5a9edefc26b146b1981774bd9837b70@varnish-cache.org> Message-ID: <058.537fb1c77e13932fa6baca13507bb8c4@varnish-cache.org> #1849: Panic running s00002.vtc on travis ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): Also seen in jenkins: https://jenkins.varnish-software.com/view/varnish-master/job/varnish- master-gitbuild-debian-wheezy-amd64/1138/console -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 1 19:18:05 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Feb 2016 19:18:05 -0000 Subject: [Varnish] #1852: Use-after-free situtation on ESI include Message-ID: <043.79d149d9c9be29b19daaef9aa20dc43b@varnish-cache.org> #1852: Use-after-free situtation on ESI include ----------------------+------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Spotted a use after free situation by running make check with Address Sanitizer enabled. Triggered in e00011.vtc, e00018.vtc, r00590.vtc, r00612.vtc and r00961.vtc. Full test log attached. Excerpt below. {{{ ==12171==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000af50 at pc 0x7f0c62cd3666 bp 0x7f0c5ba56bd0 sp 0x7f0c5ba56380\n READ of size 14 at 0x60200000af50 thread T14 (cache-worker)\n #0 0x7f0c62cd3665 (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x45665)\n #1 0x7f0c62cd39fc in writev (/usr/lib/x86_64-linux- gnu/libasan.so.2+0x459fc)\n #2 0x4daa6a in V1L_Flush http1/cache_http1_line.c:186\n #3 0x4d3d4c in v1d_bytes http1/cache_http1_deliver.c:54\n #4 0x430b3b in VDP_bytes cache/cache_deliver_proc.c:51\n #5 0x436cac in VDP_ESI cache/cache_esi_deliver.c:374\n #6 0x430b3b in VDP_bytes cache/cache_deliver_proc.c:51\n #7 0x431842 in vdp_objiterator cache/cache_deliver_proc.c:120\n #8 0x51d631 in sml_iterator storage/storage_simple.c:250\n #9 0x47851c in ObjIterate cache/cache_obj.c:76\n #10 0x431998 in VDP_DeliverObj cache/cache_deliver_proc.c:129\n #11 0x4d4a3d in V1D_Deliver http1/cache_http1_deliver.c:131\n #12 0x486845 in cnt_vdp cache/cache_req_fsm.c:108\n #13 0x487b7d in cnt_deliver cache/cache_req_fsm.c:202\n #14 0x48eb12 in CNT_Request ../../include/tbl/steps.h:54\n #15 0x4d916e in HTTP1_Session http1/cache_http1_fsm.c:267\n #16 0x4948be in SES_Proto_Req cache/cache_session.c:318\n #17 0x4c6b83 in Pool_Work_Thread cache/cache_wrk.c:341\n #18 0x4c3480 in WRK_Thread cache/cache_wrk.c:121\n #19 0x4c6f88 in pool_thread cache/cache_wrk.c:371\n #20 0x7f0c617df283 in start_thread (/lib/x86_64-linux- gnu/libpthread.so.0+0x7283)\n #21 0x7f0c6151c74c in clone (/lib/x86_64-linux- gnu/libc.so.6+0xe874c)\n \n 0x60200000af50 is located 0 bytes inside of 14-byte region [0x60200000af50,0x60200000af5e)\n freed by thread T14 (cache-worker) here:\n #0 0x7f0c62d21bfa in __interceptor_free (/usr/lib/x86_64-linux- gnu/libasan.so.2+0x93bfa)\n #1 0x50c447 in sma_free storage/storage_malloc.c:146\n #2 0x51bbe3 in sml_stv_free storage/storage_simple.c:79\n #3 0x51ceb7 in sml_slim storage/storage_simple.c:194\n #4 0x479db8 in ObjSlim cache/cache_obj.c:242\n #5 0x487d7e in cnt_deliver cache/cache_req_fsm.c:214\n #6 0x48eb12 in CNT_Request ../../include/tbl/steps.h:54\n #7 0x434f90 in ved_include cache/cache_esi_deliver.c:161\n #8 0x4366f9 in VDP_ESI cache/cache_esi_deliver.c:335\n #9 0x430b3b in VDP_bytes cache/cache_deliver_proc.c:51\n #10 0x431842 in vdp_objiterator cache/cache_deliver_proc.c:120\n #11 0x51d631 in sml_iterator storage/storage_simple.c:250\n #12 0x47851c in ObjIterate cache/cache_obj.c:76\n #13 0x431998 in VDP_DeliverObj cache/cache_deliver_proc.c:129\n #14 0x4d4a3d in V1D_Deliver http1/cache_http1_deliver.c:131\n #15 0x486845 in cnt_vdp cache/cache_req_fsm.c:108\n #16 0x487b7d in cnt_deliver cache/cache_req_fsm.c:202\n #17 0x48eb12 in CNT_Request ../../include/tbl/steps.h:54\n #18 0x4d916e in HTTP1_Session http1/cache_http1_fsm.c:267\n #19 0x4948be in SES_Proto_Req cache/cache_session.c:318\n #20 0x4c6b83 in Pool_Work_Thread cache/cache_wrk.c:341\n #21 0x4c3480 in WRK_Thread cache/cache_wrk.c:121\n #22 0x4c6f88 in pool_thread cache/cache_wrk.c:371\n #23 0x7f0c617df283 in start_thread (/lib/x86_64-linux- gnu/libpthread.so.0+0x7283)\n \n previously allocated by thread T13 (cache-worker) here:\n #0 0x7f0c62d21e9a in malloc (/usr/lib/x86_64-linux- gnu/libasan.so.2+0x93e9a)\n #1 0x50ba5c in sma_alloc storage/storage_malloc.c:95\n #2 0x51b8d3 in sml_stv_alloc storage/storage_simple.c:59\n #3 0x51e144 in objallocwithnuke storage/storage_simple.c:334\n #4 0x51e884 in sml_getspace storage/storage_simple.c:370\n #5 0x4787f7 in ObjGetSpace cache/cache_obj.c:99\n #6 0x456a10 in VFP_GetStorage cache/cache_fetch_proc.c:86\n #7 0x44f97a in vbf_fetch_body_helper cache/cache_fetch.c:505\n #8 0x451a91 in vbf_stp_fetch cache/cache_fetch.c:660\n #9 0x454e7f in vbf_fetch_thread ../../include/tbl/steps.h:63\n #10 0x4c6b83 in Pool_Work_Thread cache/cache_wrk.c:341\n #11 0x4c3480 in WRK_Thread cache/cache_wrk.c:121\n #12 0x4c6f88 in pool_thread cache/cache_wrk.c:371\n #13 0x7f0c617df283 in start_thread (/lib/x86_64-linux- gnu/libpthread.so.0+0x7283)\n \n Thread T14 (cache-worker) created by T5 here:\n #0 0x7f0c62cc3ef4 in pthread_create (/usr/lib/x86_64-linux- gnu/libasan.so.2+0x35ef4)\n #1 0x4c73b0 in pool_breed cache/cache_wrk.c:396\n #2 0x4c7a51 in pool_herder cache/cache_wrk.c:445\n #3 0x7f0c617df283 in start_thread (/lib/x86_64-linux- gnu/libpthread.so.0+0x7283)\n \n Thread T5 created by T4 (pool_herder) here:\n #0 0x7f0c62cc3ef4 in pthread_create (/usr/lib/x86_64-linux- gnu/libasan.so.2+0x35ef4)\n #1 0x4814f3 in pool_mkpool cache/cache_pool.c:167\n #2 0x481639 in pool_poolherder cache/cache_pool.c:199\n #3 0x7f0c617df283 in start_thread (/lib/x86_64-linux- gnu/libpthread.so.0+0x7283)\n \n Thread T4 (pool_herder) created by T0 (cache-main) here:\n #0 0x7f0c62cc3ef4 in pthread_create (/usr/lib/x86_64-linux- gnu/libasan.so.2+0x35ef4)\n #1 0x481933 in Pool_Init cache/cache_pool.c:239\n #2 0x4741e1 in child_main cache/cache_main.c:246\n #3 0x4e6955 in mgt_launch_child mgt/mgt_child.c:379\n #4 0x4e7eff in mcf_server_startstop mgt/mgt_child.c:610\n #5 0x7f0c62a5d1fb in cls_dispatch /home/daghf/varnish- master/lib/libvarnish/cli_serve.c:235\n #6 0x7f0c62a5da61 in cls_vlu2 /home/daghf/varnish- master/lib/libvarnish/cli_serve.c:295\n #7 0x7f0c62a5e524 in cls_vlu /home/daghf/varnish- master/lib/libvarnish/cli_serve.c:360\n #8 0x7f0c62a70456 in LineUpProcess /home/daghf/varnish- master/lib/libvarnish/vlu.c:98\n #9 0x7f0c62a708d7 in VLU_Fd /home/daghf/varnish- master/lib/libvarnish/vlu.c:123\n #10 0x7f0c62a60b42 in VCLS_PollFd /home/daghf/varnish- master/lib/libvarnish/cli_serve.c:513\n #11 0x4ea1c4 in mgt_cli_callback2 mgt/mgt_cli.c:373\n #12 0x7f0c62a6d7f2 in vev_schedule_one /home/daghf/varnish- master/lib/libvarnish/vev.c:502\n #13 0x7f0c62a6c3a8 in vev_schedule /home/daghf/varnish- master/lib/libvarnish/vev.c:367\n #14 0x4e8987 in MGT_Run mgt/mgt_child.c:721\n #15 0x4f37db in main mgt/mgt_main.c:829\n #16 0x7f0c6145486f in __libc_start_main (/lib/x86_64-linux- gnu/libc.so.6+0x2086f)\n \n Thread T13 (cache-worker) created by T5 here:\n #0 0x7f0c62cc3ef4 in pthread_create (/usr/lib/x86_64-linux- gnu/libasan.so.2+0x35ef4)\n #1 0x4c73b0 in pool_breed cache/cache_wrk.c:396\n #2 0x4c7a51 in pool_herder cache/cache_wrk.c:445\n #3 0x7f0c617df283 in start_thread (/lib/x86_64-linux- gnu/libpthread.so.0+0x7283)\n \n SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ??\n Shadow bytes around the buggy address:\n 0x0c047fff9590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n 0x0c047fff95a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n 0x0c047fff95b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n 0x0c047fff95c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n 0x0c047fff95d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n =>0x0c047fff95e0: fa fa fa fa fa fa fa fa fa fa[fd]fd fa fa fd fd\n 0x0c047fff95f0: fa fa 00 05 fa fa fd fd fa fa fd fd fa fa 00 07\n 0x0c047fff9600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n 0x0c047fff9610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n 0x0c047fff9620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n 0x0c047fff9630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n Shadow byte legend (one shadow byte represents 8 application bytes):\n Addressable: 00\n Partially addressable: 01 02 03 04 05 06 07 \n Heap left redzone: fa\n Heap right redzone: fb\n Freed heap region: fd\n Stack left redzone: f1\n Stack mid redzone: f2\n Stack right redzone: f3\n Stack partial redzone: f4\n Stack after return: f5\n Stack use after scope: f8\n Global redzone: f9\n Global init order: f6\n Poisoned by user: f7\n Container overflow: fc\n Array cookie: ac\n Intra object redzone: bb\n ASan internal: fe\n ==12171==ABORTING\n }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 00:23:27 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 00:23:27 -0000 Subject: [Varnish] #1852: Use-after-free situtation on ESI include In-Reply-To: <043.79d149d9c9be29b19daaef9aa20dc43b@varnish-cache.org> References: <043.79d149d9c9be29b19daaef9aa20dc43b@varnish-cache.org> Message-ID: <058.4ad940c2f3b243c496f94a0cb3f8cb72@varnish-cache.org> #1852: Use-after-free situtation on ESI include ----------------------+---------------------------------------- Reporter: daghf | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [776c8386b063b53ef40317a3d8a98ef495ff709f]: {{{ #!CommitTicketReference repository="" revision="776c8386b063b53ef40317a3d8a98ef495ff709f" Add a missing VDP flush operation after ESI:includes. In incredibly seldom circumstances this bug would cause ESI:include data to be bad. Fixes: #1852 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 08:44:23 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 08:44:23 -0000 Subject: [Varnish] #1849: Panic running s00002.vtc on travis In-Reply-To: <043.a5a9edefc26b146b1981774bd9837b70@varnish-cache.org> References: <043.a5a9edefc26b146b1981774bd9837b70@varnish-cache.org> Message-ID: <058.b26e271811cc71e74b89ebef5c43f152@varnish-cache.org> #1849: Panic running s00002.vtc on travis ----------------------+---------------------------------------- Reporter: fgsch | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [a26fdcd6071a6938759039f2513ca624a21b0e72]: {{{ #!CommitTicketReference repository="" revision="a26fdcd6071a6938759039f2513ca624a21b0e72" Hold a ref on the oc for BACKGROUND fetches until we have checked that we can continue. Fixes #1849 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 09:22:33 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 09:22:33 -0000 Subject: [Varnish] #1843: HTTP/1.0 POST without C-L should error out earlier In-Reply-To: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> References: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> Message-ID: <058.f363786eaf92ce5780463831ec5d1edd@varnish-cache.org> #1843: HTTP/1.0 POST without C-L should error out earlier ----------------------+--------------------------------------------- Reporter: fgsch | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * owner: => Federico G. Schwindt * status: new => closed * resolution: => fixed Comment: In [bbf5a3409842039a48b5fd04d98d0c136d575777]: {{{ #!CommitTicketReference repository="" revision="bbf5a3409842039a48b5fd04d98d0c136d575777" Fail HTTP/1.0 POST and PUT requests without C-L It is not allowed by the spec and we incorrectly assumed chunked and eventually timed out. OK'd by phk at . Fixes #1843. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 09:22:32 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 09:22:32 -0000 Subject: [Varnish] #1837: Error compiling VCL if probe is referenced before it is defined In-Reply-To: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> References: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> Message-ID: <058.64d6c8678275caaa5b1a8b64e972fa18@varnish-cache.org> #1837: Error compiling VCL if probe is referenced before it is defined ----------------------+--------------------------------------------- Reporter: fgsch | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * owner: => Federico G. Schwindt * status: new => closed * resolution: => fixed Comment: In [1ca122e4f9099e2d4b8d3d740783bced1151d78b]: {{{ #!CommitTicketReference repository="" revision="1ca122e4f9099e2d4b8d3d740783bced1151d78b" Error earlier if we cannot find the probe We don't have forward declarations in VCL. OK'd by phk at . Fixes #1837. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 09:36:23 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 09:36:23 -0000 Subject: [Varnish] #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. In-Reply-To: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> References: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> Message-ID: <061.083847e5dd311b4bb1aa26e11ee25139@varnish-cache.org> #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. -------------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 4.1.1 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by lkarsten): I don't see that there is any conservative approach. Can you expand a bit on what you mean? logrotate configuration was updated (on el6/el7). See 5d4517d in pkg- varnish-cache. Main issue here is that logrotate.d/varnish is %config(noreplace), so any installation with local modifications won't get the update. However, in that case I expect the sysadmin to have cleaned up our mess and got it working already. Anyway. 4.1.1-2 went out to the repository yesterday, both for enterprise linux and debian/ubuntu. Leaving this open for comments a few more days. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 09:41:17 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 09:41:17 -0000 Subject: [Varnish] #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. In-Reply-To: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> References: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> Message-ID: <061.5b37ec80c1b4473cc734da63daf241c7@varnish-cache.org> #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. -------------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishncsa | Version: 4.1.1 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by fgsch): That's the issue I'm talking about wrt logrotate configuration (noreplace). The more conservative approach is using tmpfiles. No manual intervention is required besides updating. I've also left several comments on one commit at the pkg-varnish-cache repository. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 09:51:13 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 09:51:13 -0000 Subject: [Varnish] #1750: Fail more gracefully on -l >= 4GB In-Reply-To: <043.043bbd8ec6de89449726e0316939ec56@varnish-cache.org> References: <043.043bbd8ec6de89449726e0316939ec56@varnish-cache.org> Message-ID: <058.8ce90b5faa41600478ef38e640b79ac9@varnish-cache.org> #1750: Fail more gracefully on -l >= 4GB ----------------------+---------------------------------- Reporter: geoff | Owner: martin Type: defect | Status: new Priority: low | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: minor | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by phk): As I understand this, this is a limitation in the VSL api which uses uint32_t for offset/index? That really should be size_t... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 10:17:03 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 10:17:03 -0000 Subject: [Varnish] #1847: HTTP1_DissectRequest doesn't handle https In-Reply-To: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> References: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> Message-ID: <062.64f74c0ada17230cc69fda4f8ae062a0@varnish-cache.org> #1847: HTTP1_DissectRequest doesn't handle https -----------------------+-------------------- Reporter: gquintard | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by gquintard): FYI, I checked nginx and HAProxy and they have two diametrically opposed behaviors: - HAProxy doesn't touch the request line, at all, and just blast it to the backend - NGINX on the other hand will deconstruct any url with scheme as long as it finds "://", and will send only the path in the request line And Varnish stands in the middle :-) @phk: we talked about a enable_https flag, should we consider an enable_all flags to have the nginx behavior? (I'm guessing no, but who knows?) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 11:57:57 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 11:57:57 -0000 Subject: [Varnish] #1841: r01801.vtc panic on OSX: vwk_thread(), waiter/cache_waiter_kqueue.c line 109: In-Reply-To: <046.6046354ab122696fa0a1985521776750@varnish-cache.org> References: <046.6046354ab122696fa0a1985521776750@varnish-cache.org> Message-ID: <061.5cdb589e6746cbf34c7287e04e4cf913@varnish-cache.org> #1841: r01801.vtc panic on OSX: vwk_thread(), waiter/cache_waiter_kqueue.c line 109: ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [0311c78353cbacbec73a155807d3777749dd0802]: {{{ #!CommitTicketReference repository="" revision="0311c78353cbacbec73a155807d3777749dd0802" Replace alien FD's with /dev/null rather than just closing them When we fork the worker process, we close all filedescriptors we have not explictly marked for it to inherit, for security reasons. Operating system libraries may have open filedescriptors (see end*ent(3)) and there is no way to chase these down. At least on OSX something related to DNS lookups leaves such a FD around, and when that code later discovers the FD doesn't work, it closes it, even though it no longer owns it. In ticket 1841, that happens to be FD7 which is one of our kqueue FDs. Normally such library code should set 'close-on-exec' status with fcntl(2) but that doesn't seem to be the case here, and this bit of wisdom seems neglegted about 50/50, so it probably wouldn't help us to examine this. The fix here is to close the FDs, and replace them with a FD open to /dev/null, so that there is no risk of information leak, but we don't reuse the FD for something else until the library has properly closed it. Fixes #1841 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 15:24:25 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 15:24:25 -0000 Subject: [Varnish] #1750: Fail more gracefully on -l >= 4GB In-Reply-To: <043.043bbd8ec6de89449726e0316939ec56@varnish-cache.org> References: <043.043bbd8ec6de89449726e0316939ec56@varnish-cache.org> Message-ID: <058.531b76ea2a1fbbbc5e4a37aaa64c317b@varnish-cache.org> #1750: Fail more gracefully on -l >= 4GB ----------------------+---------------------------------- Reporter: geoff | Owner: martin Type: defect | Status: new Priority: low | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: minor | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by geoff): size_t is a "natural" type for something like that, and is almost certainly large enough for anything that anyone might want to have for -l. But there's also the matter of graceful failure. It would still be necessary to reject -l values that are too large (> SIZE_MAX in the case of size_t), and the reasonable expectation would be that varnish doesn't start at all, neither master or child process, as soon as the command line parsed, with a message to stderr. As it is, the master process starts when -l is too large, but the child process is aborted and then the master process stops. A message about the abort goes to syslog, but nothing says what the problem was. Automated deployments see the master process starting, and then have every reason to assume that everything's fine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 2 15:40:22 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Feb 2016 15:40:22 -0000 Subject: [Varnish] #1750: Fail more gracefully on -l >= 4GB In-Reply-To: <043.043bbd8ec6de89449726e0316939ec56@varnish-cache.org> References: <043.043bbd8ec6de89449726e0316939ec56@varnish-cache.org> Message-ID: <058.224fec019e9e8460926569c48eb4d8b4@varnish-cache.org> #1750: Fail more gracefully on -l >= 4GB ----------------------+---------------------------------- Reporter: geoff | Owner: martin Type: defect | Status: new Priority: low | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: minor | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by phk): size_t is big enough to cover the address-space of the CPU. You will, by definition, never mmap anything larger. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 3 10:24:07 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Feb 2016 10:24:07 -0000 Subject: [Varnish] #1853: Assert error in Lck_CondWait(), cache/cache_lck.c line 203 (on Mac OS X) Message-ID: <051.97b8df5531f8bd75d8e6679ba7777595@varnish-cache.org> #1853: Assert error in Lck_CondWait(), cache/cache_lck.c line 203 (on Mac OS X) ---------------------------+---------------------- Reporter: Jastrzebowski | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.1.0 | Severity: normal Keywords: | ---------------------------+---------------------- We are trying to migrate local dev to Varnish 4.1.0 (from Brew) but it?s keep crashing after a couple of page reloads throwing an error: {{{ Assert error in Lck_CondWait(), cache/cache_lck.c line 203: Condition((pthread_cond_wait(cond, &ilck->mtx)) == 0) not true. thread = (cache-worker) version = varnish-4.1.0 revision 3041728 ident = Darwin,15.4.0,x86_64,-jnone,-smalloc,-smalloc,-hcritbit,kqueue Backtrace: 0x106c48706: 0 varnishd 0x0000000106c48706 pan_ic + 405 0x106c445e6: 0 varnishd 0x0000000106c445e6 Lck_CondWait + 171 0x106c2afe8: 0 varnishd 0x0000000106c2afe8 VBT_Wait + 157 0x106c262c7: 0 varnishd 0x0000000106c262c7 vbe_dir_gethdrs + 284 0x106c2f9f7: 0 varnishd 0x0000000106c2f9f7 VDI_GetHdr + 102 0x106c382a0: 0 varnishd 0x0000000106c382a0 vbf_fetch_thread + 2860 0x106c5f740: 0 varnishd 0x0000000106c5f740 WRK_Thread + 1527 0x106c5f0f1: 0 varnishd 0x0000000106c5f0f1 pool_thread + 51 0x7fff915d399d: 0 libsystem_pthread.dylib 0x00007fff915d399d _pthread_body + 131 0x7fff915d391a: 0 libsystem_pthread.dylib 0x00007fff915d391a _pthread_body + 0 busyobj = 0x7feef4872620 { ws = 0x7feef48726e0 { id = "bo", {s,f,r,e} = {0x7feef4874598,+1136,0x0,+57440}, }, refcnt = 2, retries = 0, failed = 0, state = 1, flags = {do_stream}, http_conn = 0x7feef4874958 { fd = 13, doclose = NULL, ws = 0x0, {rxbuf_b, rxbuf_e} = {0x0, 0x0}, {pipeline_b, pipeline_e} = {0x0, 0x0}, content_length = 0, body_status = none, first_byte_timeout = 60.000000, between_bytes_timeout = 60.000000, }, director_req = 0x7feef3c09290 { vcl_name = goldenline_production, type = random { }, }, director_resp = 0x7feef3f01088 { vcl_name = php, type = backend { display_name = boot.php, ipv4 = 127.0.0.1, port = 8080, hosthdr = 127.0.0.1, health=healthy, admin_health=probe, changed=1454427684.4, n_conn = 1, }, }, http[bereq] = 0x7feef4872ca8 { ws[bo] = 0x7feef48726e0, hdrs { "GET", "/_fragment?_path=type%3Donline%26path%3D%252Fpracodawcy%26locale%3Den%26_format%3Dhtml%26_locale%3Den%26_controller%3DHomepageBundle%253ALayout%253Afooter&token=1db840338dc9998350313087cac23d3b&_hash=sx%2FuowyHne7J%2BOdXavQfwHEen4TDsqO2Bq2gv8%2FVwrQ%3D", "HTTP/1.1", "Host: www.goldenline.pl.127.0.0.1.xip.io", "X-Real-IP: 127.0.0.1", "X-Forwarded-Port: 443", "X-Forwarded-Protocol: https", "X-Forwarded-Proto: https", "accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8", "upgrade-insecure-requests: 1", "user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.97 Safari/537.36", "X-Forwarded-For: 127.0.0.1, 127.0.0.1", "X-Varnish-Accept-Language: en", "X-UA-Device: desktop", "X-Environment: production", "X-HQ: 1", "Accept-Language: en", "Surrogate-Capability: abc=ESI/1.0", "Accept-Encoding: gzip", "X-Varnish: 524305", }, }, http[beresp] = 0x7feef4873120 { ws[bo] = 0x7feef48726e0, hdrs { }, }, objcore[fetch] = 0x7feef3e176a0 { refcnt = 2, flags = 0x2, objhead = 0x7feef3e147b0, stevedore = 0x0, }, vcl = { temp = warm srcname = { "input", "Builtin", "backends.4.vcl", "accept_language.4.vcl", "devicedetect.vcl", }, }, }, }}} Varnish 4.1.0, Mac OS 10.11.(3|4). meanwhile linux V4.1.1 with the same config runs perfectly normal -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 4 10:31:32 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Feb 2016 10:31:32 -0000 Subject: [Varnish] #1754: n_objecthead increase just before oomkill In-Reply-To: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> References: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> Message-ID: <061.96826ddaf0fb8aabf8ba8b590b305c07@varnish-cache.org> #1754: n_objecthead increase just before oomkill ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by dmz): We're seeing a similar issue on 4.1.1 running on bare metal, khugepaged disabled. High throughput configured for 56G is slowly leaking up to a 90G commit over a week, fortunately we monitor and usually manage to restart before OOM. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 4 16:33:35 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Feb 2016 16:33:35 -0000 Subject: [Varnish] #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. In-Reply-To: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> References: <046.0395fe2de92f3245377f2846e3d45f55@varnish-cache.org> Message-ID: <061.95d6e60cb8005ce750f774c8ef284e98@varnish-cache.org> #1850: logrotate stops varnishncsa/varnishlog permanently under systemd. -------------------------+--------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: 4.1.1 Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 5 00:15:41 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 05 Feb 2016 00:15:41 -0000 Subject: [Varnish] #1854: Feature request: leastconn director Message-ID: <046.890339f25dd8d079c2f3748842f8b011@varnish-cache.org> #1854: Feature request: leastconn director -----------------------+------------------------- Reporter: BenMorel | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: leastconn | -----------------------+------------------------- I've recently moved from Varnish + HAProxy to Varnish only, to handle the cache + the load balancing with a single software. I'm pretty happy with it. The only feature I've been missing from HAProxy is the leastconn load balancing algorithm. Their documentation describes it as: > for long connections, pick the least recently used of the servers with the lowest connection count In some situations, this is preferable to round robin, for example when the number of open connections to a backend is directly related to its load (this is the case when the backend performs CPU-intensive tasks) and the workload is uneven across requests. In this case, round-robin might end up sending several small workloads to a backend server, and several big workloads to another. The leastconn algorithm comes to the rescue by keeping the number of connections, and therefore the load, at a minimum on every server. Would you consider adding a leastconn director to Varnish? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 5 12:35:27 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 05 Feb 2016 12:35:27 -0000 Subject: [Varnish] #1855: varnishstat width is limited to 999GB (12 chars) for byte counters Message-ID: <043.645c04c96f766732bf122865b24e378a@varnish-cache.org> #1855: varnishstat width is limited to 999GB (12 chars) for byte counters -------------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Keywords: -------------------------+------------------- We should consider increasing it handle bigger sizes or add some hint to signal that the displayed value was truncated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 8 08:48:25 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Feb 2016 08:48:25 -0000 Subject: [Varnish] #1838: Cannot include synthetic content on ESI request if esi:include is in plaintext In-Reply-To: <043.b7c207dfb366eab7d8c8d9c9f7bc15a0@varnish-cache.org> References: <043.b7c207dfb366eab7d8c8d9c9f7bc15a0@varnish-cache.org> Message-ID: <058.6c0f696ff12fa6b55093c30639cbddba@varnish-cache.org> #1838: Cannot include synthetic content on ESI request if esi:include is in plaintext ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by phk): I cannot reproduce this in -trunk today. Can you recheck ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 8 09:42:19 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Feb 2016 09:42:19 -0000 Subject: [Varnish] #1838: Cannot include synthetic content on ESI request if esi:include is in plaintext In-Reply-To: <043.b7c207dfb366eab7d8c8d9c9f7bc15a0@varnish-cache.org> References: <043.b7c207dfb366eab7d8c8d9c9f7bc15a0@varnish-cache.org> Message-ID: <058.9bceedb10ec9e202606bc645228c0a93@varnish-cache.org> #1838: Cannot include synthetic content on ESI request if esi:include is in plaintext ----------------------+--------------------- Reporter: fgsch | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by fgsch): * status: new => closed * resolution: => fixed Comment: This turned to be due to #1852. Fixed in commit 776c8386b063b53ef40317a3d8a98ef495ff709f. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 8 10:42:34 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Feb 2016 10:42:34 -0000 Subject: [Varnish] #1779: Test std.ip (m00011) failing on OS X In-Reply-To: <045.c141d2673f9da9e64a8a20409a51199a@varnish-cache.org> References: <045.c141d2673f9da9e64a8a20409a51199a@varnish-cache.org> Message-ID: <060.897df1becc06acc6de437765f33d2f77@varnish-cache.org> #1779: Test std.ip (m00011) failing on OS X ---------------------+--------------------- Reporter: espebra | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I think this was same issue as #1841 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 8 10:44:29 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Feb 2016 10:44:29 -0000 Subject: [Varnish] #1670: assert: default_oc_getobj(), storage/stevedore.c line 68 In-Reply-To: <046.effee11bf6ff3d79ffdf705e9fe5a83f@varnish-cache.org> References: <046.effee11bf6ff3d79ffdf705e9fe5a83f@varnish-cache.org> Message-ID: <061.21db8500a0c1d8b906fd8d51f6830930@varnish-cache.org> #1670: assert: default_oc_getobj(), storage/stevedore.c line 68 ----------------------+---------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: Keywords: | ----------------------+---------------------- Comment (by phk): From #1793 which is dup of this: {{{ webcache09:~# varnishadm panic.show Last panic at: Sun, 13 Sep 2015 17:04:10 GMT Assert error in default_oc_getobj(), storage/stevedore.c line 60: Condition(((o))->magic == (0x32851d42)) not true. thread = (cache-timeout) version = varnish-4.1.0-tp1 revision 0e4e1bc ident = Linux,3.2.0-4-amd64,x86_64,-junix,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x4343a4: pan_ic+0x134 0x45ca28: default_oc_getobj+0x78 0x433033: ObjGetattr+0xa3 0x433922: ObjGetU32+0x12 0x433980: ObjGetXID+0x10 0x421c84: exp_thread+0x444 0x448faf: wrk_bgthread+0x5f 0x7f5516bd2b50: libpthread.so.0(+0x6b50) [0x7f5516bd2b50] 0x7f551691c95d: libc.so.6(clone+0x6d) [0x7f551691c95d] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 8 10:44:48 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Feb 2016 10:44:48 -0000 Subject: [Varnish] #1793: Assert error in default_oc_getobj() In-Reply-To: <045.597d8a2e6b21666e8f19cff1d3e7a950@varnish-cache.org> References: <045.597d8a2e6b21666e8f19cff1d3e7a950@varnish-cache.org> Message-ID: <060.09374261f66abca553a49ca011650aca@varnish-cache.org> #1793: Assert error in default_oc_getobj() --------------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: duplicate Keywords: assert error | --------------------------+------------------------ Changes (by phk): * status: new => closed * resolution: => duplicate -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 8 12:07:34 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Feb 2016 12:07:34 -0000 Subject: [Varnish] #1704: fetch_failed not incremented In-Reply-To: <043.7d196a75b21578116bfbb31eaaec7a7e@varnish-cache.org> References: <043.7d196a75b21578116bfbb31eaaec7a7e@varnish-cache.org> Message-ID: <058.0fbfaa130b17778803db49151f8a963e@varnish-cache.org> #1704: fetch_failed not incremented ----------------------+----------------------- Reporter: fgsch | Owner: fgsch Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Changes (by fgsch): * status: new => assigned * owner: => fgsch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 8 12:08:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Feb 2016 12:08:15 -0000 Subject: [Varnish] #1725: backend_conn is no longer incremented In-Reply-To: <043.78e7f027254fb82cf2802850327b40a2@varnish-cache.org> References: <043.78e7f027254fb82cf2802850327b40a2@varnish-cache.org> Message-ID: <058.33e8f4d5800c04f1fa3ae99728271058@varnish-cache.org> #1725: backend_conn is no longer incremented ----------------------+----------------------- Reporter: fgsch | Owner: fgsch Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Changes (by fgsch): * owner: => fgsch * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 8 12:11:49 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Feb 2016 12:11:49 -0000 Subject: [Varnish] #1758: Open ended range request results in truncated images In-Reply-To: <042.59608046e2c72aa2a96dbec825189975@varnish-cache.org> References: <042.59608046e2c72aa2a96dbec825189975@varnish-cache.org> Message-ID: <057.fa88d778975e49c5fd426c35abcdd426@varnish-cache.org> #1758: Open ended range request results in truncated images -----------------------------+--------------------- Reporter: jafa | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: range truncated | -----------------------------+--------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: Hi. This should be fixed in the 4.1.1. No backport necessary. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 8 12:15:42 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Feb 2016 12:15:42 -0000 Subject: [Varnish] #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) In-Reply-To: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> References: <041.e56b1a3851d9f7bdf2bd9a4fc99aa3a7@varnish-cache.org> Message-ID: <056.1bdf8050fee65396ae990f69af8aa78b@varnish-cache.org> #1772: first_byte_timeout is ignored when re-using a backend connection (HTTP Keep Alive) ----------------------+-------------------- Reporter: tnt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by phk): See also #1806 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 8 12:17:53 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Feb 2016 12:17:53 -0000 Subject: [Varnish] #1733: Unstable test-cases In-Reply-To: <041.e3e9abd44efc9f6e731fb370c77db66e@varnish-cache.org> References: <041.e3e9abd44efc9f6e731fb370c77db66e@varnish-cache.org> Message-ID: <056.1502276de6c8a4ce518109754f47fd85@varnish-cache.org> #1733: Unstable test-cases -------------------------+--------------------- Reporter: phk | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Currently no unstable test-cases known. Reopen if you observe any. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 9 13:04:29 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Feb 2016 13:04:29 -0000 Subject: [Varnish] #1856: LostHeader with regsub Message-ID: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> #1856: LostHeader with regsub ------------------------+--------------------- Reporter: gdelacroix | Type: defect Status: new | Priority: normal Milestone: | Component: regress Version: 4.1.1 | Severity: normal Keywords: | ------------------------+--------------------- With 4.1.1, I get a "LostHeader req.url" and "Error workspace_client overflow" when using this line: set req.url = regsub(req.url, "/([?])?$", "\1"); ...that I took there a while ago: https://www.varnish- cache.org/trac/wiki/VCLExampleNormalizingReqUrl I didn't get this issue with 4.0.3 The issue occurs because the regsub actually removes the url when it's just "/". Adding 'if (req.url != "/")...' or changing the regexp by "(?<=.)/([?])?$" to check there's something before the removed slash fixes the issue but the fact this error appears in 4.1.1 and not in 4.0.3 (didn't check 4.1.0) maybe an unexpected behavior... Anyway, the wiki page should be fixed ;o) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 9 13:10:03 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Feb 2016 13:10:03 -0000 Subject: [Varnish] #1856: LostHeader with regsub In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.29ec6f865027e6ae53bd8bb07ae26033@varnish-cache.org> #1856: LostHeader with regsub ------------------------+-------------------- Reporter: gdelacroix | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: regress | Version: 4.1.1 Severity: normal | Resolution: Keywords: | ------------------------+-------------------- Comment (by gdelacroix): Brackets in regexps have been removed by Trac but I used the syntax as shown in the wiki page, with brackets around "(?)". I only added "(?<=.)" in front of the second one. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 9 22:43:09 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Feb 2016 22:43:09 -0000 Subject: [Varnish] #1857: Session herding is broken. Message-ID: <041.d54997163bc44fe4c8f05f71f8038661@varnish-cache.org> #1857: Session herding is broken. ----------------------+------------------- Reporter: phk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Probably broken in commit a40ceb077e58c1d35f5e27568e745959be8e5007 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 9 22:51:31 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Feb 2016 22:51:31 -0000 Subject: [Varnish] #1857: Session herding is broken. In-Reply-To: <041.d54997163bc44fe4c8f05f71f8038661@varnish-cache.org> References: <041.d54997163bc44fe4c8f05f71f8038661@varnish-cache.org> Message-ID: <056.6d2a7754c814df08f827d9f37556242f@varnish-cache.org> #1857: Session herding is broken. ----------------------+---------------------------------------- Reporter: phk | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [644bf0801c94fd85278d8612f8b4d6a6b23a8f51]: {{{ #!CommitTicketReference repository="" revision="644bf0801c94fd85278d8612f8b4d6a6b23a8f51" Fix timeout calculation to give session-herding a chance. Fixes: #1857 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 10 22:42:06 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 10 Feb 2016 22:42:06 -0000 Subject: [Varnish] #1856: LostHeader with regsub In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.1e8a14a199b11763de4c67359120cc9b@varnish-cache.org> #1856: LostHeader with regsub ------------------------+----------------------- Reporter: gdelacroix | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: regress | Version: 4.1.1 Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Changes (by fgsch): * status: new => needinfo Comment: I cannot reproduce it. Can you supply a testcase (.vtc) or more details, i.e. the requested URL? Also, which pcre version are you using? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 08:32:20 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 08:32:20 -0000 Subject: [Varnish] #1856: LostHeader with regsub In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.baaaf86fcab56577e8b6beb4e880237f@varnish-cache.org> #1856: LostHeader with regsub ------------------------+----------------------- Reporter: gdelacroix | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: regress | Version: 4.1.1 Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Comment (by gdelacroix): Sorry, it's not clear in my message: it only occurs when URL is "/". I'm using pcre 8.32. I'm not firendly with VTC but you only have to apply the example from the wiki. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 10:26:46 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 10:26:46 -0000 Subject: [Varnish] #1856: LostHeader with regsub In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.8a00005950bfd679cd3bfcb400923ae7@varnish-cache.org> #1856: LostHeader with regsub ------------------------+----------------------- Reporter: gdelacroix | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: regress | Version: 4.1.1 Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Comment (by fgsch): Test attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 11:22:46 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 11:22:46 -0000 Subject: [Varnish] #1856: LostHeader with regsub In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.9836f56a1ebd7e65f91e162d7dee5524@varnish-cache.org> #1856: LostHeader with regsub ------------------------+----------------------- Reporter: gdelacroix | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: regress | Version: 4.1.1 Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Comment (by fgsch): Ok, this is not related to regsub. The following construct will trigger the same workspace exhaustion: {{{ set req.url = ""; }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 11:25:30 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 11:25:30 -0000 Subject: [Varnish] #1856: LostHeader setting req.url to an empty string (was: LostHeader with regsub) In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.3ed6e9a6d7be095ca8ffa49c3b1b76ef@varnish-cache.org> #1856: LostHeader setting req.url to an empty string ------------------------+----------------------- Reporter: gdelacroix | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Changes (by fgsch): * version: 4.1.1 => trunk * component: regress => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 12:35:40 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 12:35:40 -0000 Subject: [Varnish] #1856: LostHeader setting req.url to an empty string In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.eed2dc1eeb2e5a830df0d3c6eebaa5e4@varnish-cache.org> #1856: LostHeader setting req.url to an empty string ------------------------+----------------------- Reporter: gdelacroix | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Comment (by fgsch): This is not limited to req.url but any variable using vrt_do_string(). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 13:43:19 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 13:43:19 -0000 Subject: [Varnish] #1856: LostHeader setting req.url to an empty string In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.0d7c52d08c4f5436c4a1983ec62aa292@varnish-cache.org> #1856: LostHeader setting req.url to an empty string ------------------------+----------------------- Reporter: gdelacroix | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Comment (by gdelacroix): Yes, as I said: ''The issue occurs because the regsub actually removes the url when it's just "/".'' Seems the behavior when removing emptying req.url has changed, but I don't know which is expected. And anyway, the wiki page example should be updated because, even if it doesn't cause trouble before 4.1, it tries to remove the url when it's "/". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 16:14:35 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 16:14:35 -0000 Subject: [Varnish] #1857: Session herding is broken. In-Reply-To: <041.d54997163bc44fe4c8f05f71f8038661@varnish-cache.org> References: <041.d54997163bc44fe4c8f05f71f8038661@varnish-cache.org> Message-ID: <056.a65615f844c9e13a643b559543491412@varnish-cache.org> #1857: Session herding is broken. ----------------------+---------------------------------------- Reporter: phk | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [efddff421c030db3e21f949947626a259ce97c36]: {{{ #!CommitTicketReference repository="" revision="efddff421c030db3e21f949947626a259ce97c36" Fix timeout calculation to give session-herding a chance. Fixes: #1857 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 16:14:36 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 16:14:36 -0000 Subject: [Varnish] #1843: HTTP/1.0 POST without C-L should error out earlier In-Reply-To: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> References: <043.7c280f599be33ccabcb60ca1c01ec58c@varnish-cache.org> Message-ID: <058.52b25287ab7bcda88f88357bbcf16e33@varnish-cache.org> #1843: HTTP/1.0 POST without C-L should error out earlier ----------------------+--------------------------------------------- Reporter: fgsch | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [b9946b4b0bc65b935580fe7db999b1b6c5558e19]: {{{ #!CommitTicketReference repository="" revision="b9946b4b0bc65b935580fe7db999b1b6c5558e19" Fail HTTP/1.0 POST and PUT requests without C-L It is not allowed by the spec and we incorrectly assumed chunked and eventually timed out. OK'd by phk at . Fixes #1843. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 16:14:36 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 16:14:36 -0000 Subject: [Varnish] #1837: Error compiling VCL if probe is referenced before it is defined In-Reply-To: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> References: <043.9d42389dc6634f3dd209df6886d7f9ac@varnish-cache.org> Message-ID: <058.e38c1632317df7240df7c13c4174b9ad@varnish-cache.org> #1837: Error compiling VCL if probe is referenced before it is defined ----------------------+--------------------------------------------- Reporter: fgsch | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [3885d2c8fe3d5edca729b607cafc224349208c86]: {{{ #!CommitTicketReference repository="" revision="3885d2c8fe3d5edca729b607cafc224349208c86" Error earlier if we cannot find the probe We don't have forward declarations in VCL. OK'd by phk at . Fixes #1837. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 16:14:36 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 16:14:36 -0000 Subject: [Varnish] #1841: r01801.vtc panic on OSX: vwk_thread(), waiter/cache_waiter_kqueue.c line 109: In-Reply-To: <046.6046354ab122696fa0a1985521776750@varnish-cache.org> References: <046.6046354ab122696fa0a1985521776750@varnish-cache.org> Message-ID: <061.dd6d14f41a45a3947a7fa4391a05b2bc@varnish-cache.org> #1841: r01801.vtc panic on OSX: vwk_thread(), waiter/cache_waiter_kqueue.c line 109: ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [87f081e6e58d0e51f288f131e209aa31891db38f]: {{{ #!CommitTicketReference repository="" revision="87f081e6e58d0e51f288f131e209aa31891db38f" Replace alien FD's with /dev/null rather than just closing them When we fork the worker process, we close all filedescriptors we have not explictly marked for it to inherit, for security reasons. Operating system libraries may have open filedescriptors (see end*ent(3)) and there is no way to chase these down. At least on OSX something related to DNS lookups leaves such a FD around, and when that code later discovers the FD doesn't work, it closes it, even though it no longer owns it. In ticket 1841, that happens to be FD7 which is one of our kqueue FDs. Normally such library code should set 'close-on-exec' status with fcntl(2) but that doesn't seem to be the case here, and this bit of wisdom seems neglegted about 50/50, so it probably wouldn't help us to examine this. The fix here is to close the FDs, and replace them with a FD open to /dev/null, so that there is no risk of information leak, but we don't reuse the FD for something else until the library has properly closed it. Fixes #1841 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 16:14:35 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 16:14:35 -0000 Subject: [Varnish] #1851: Varnish 4.1.1 fails to build on i386 In-Reply-To: <042.3b3edf26ed9fdf5c93dfc7efdd85550f@varnish-cache.org> References: <042.3b3edf26ed9fdf5c93dfc7efdd85550f@varnish-cache.org> Message-ID: <057.3ef5c5c569ff929499386637919d503f@varnish-cache.org> #1851: Varnish 4.1.1 fails to build on i386 --------------------+--------------------------------------------- Reporter: feld | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.1.1 Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [c1ed9e1f7187f6a6c85f388a861247774f32e243]: {{{ #!CommitTicketReference repository="" revision="c1ed9e1f7187f6a6c85f388a861247774f32e243" Cast time_t to work with 32 bit time_t Fixes #1851. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 11 16:14:36 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Feb 2016 16:14:36 -0000 Subject: [Varnish] #1852: Use-after-free situtation on ESI include In-Reply-To: <043.79d149d9c9be29b19daaef9aa20dc43b@varnish-cache.org> References: <043.79d149d9c9be29b19daaef9aa20dc43b@varnish-cache.org> Message-ID: <058.b6675c2e1b9041bc23586bf7366a7f27@varnish-cache.org> #1852: Use-after-free situtation on ESI include ----------------------+---------------------------------------- Reporter: daghf | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [1a92e35518210636e09cfb485a692de7570a218b]: {{{ #!CommitTicketReference repository="" revision="1a92e35518210636e09cfb485a692de7570a218b" Add a missing VDP flush operation after ESI:includes. In incredibly seldom circumstances this bug would cause ESI:include data to be bad. Fixes: #1852 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 12 10:45:13 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Feb 2016 10:45:13 -0000 Subject: [Varnish] #1847: HTTP1_DissectRequest doesn't handle https In-Reply-To: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> References: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> Message-ID: <062.3021e4cc4f8697d7efa1e7ce0d33af1f@varnish-cache.org> #1847: HTTP1_DissectRequest doesn't handle https -----------------------+-------------------- Reporter: gquintard | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------+-------------------- Comment (by gquintard): New patch, using a parameter for conditional activation. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Feb 14 05:57:34 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 14 Feb 2016 05:57:34 -0000 Subject: [Varnish] #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: In-Reply-To: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> References: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> Message-ID: <058.a0c30df998be966c15a50860d54a8a2c@varnish-cache.org> #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by billnbell): Not getting panics on 4.0, but on 4.1.1 getting them. {{{ 200 Last panic at: Sun, 14 Feb 2016 05:47:59 GMT "Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: Condition((vfe) != 0) not true. errno = 11 (Resource temporarily unavailable) thread = (cache-worker) version = varnish-4.1.1 revision 66bb824 ident = Linux,3.16.0-4-amd64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433965: varnishd() [0x433965] 0x425e5f: varnishd(VFP_Push+0x13f) [0x425e5f] 0x45254f: varnishd(V1F_Setup_Fetch+0x9f) [0x45254f] 0x411bd9: varnishd() [0x411bd9] 0x423f2d: varnishd() [0x423f2d] 0x449682: varnishd() [0x449682] 0x449afb: varnishd() [0x449afb] 0x7f4e78b5e0a4: libpthread.so.0(+0x80a4) [0x7f4e78b5e0a4] 0x7f4e7889304d: libc.so.6(clone+0x6d) [0x7f4e7889304d] busyobj = 0x7f4e62221020 { ws = 0x7f4e622210e0 { OVERFLOW id = \"Bo\", {s,f,r,e} = {0x7f4e62224390,+186792,(nil),+186792}, }, refcnt = 2, retries = 0, failed = 0, state = 1, flags = {do_stream, do_pass, uncacheable, is_gunzip}, http_conn = 0x7f4e622243a8 { fd = 22, doclose = NULL, ws = 0x7f4e622210e0, {rxbuf_b, rxbuf_e} = {0x7f4e62224458, 0x7f4e62224c9b}, {pipeline_b, pipeline_e} = {0x7f4e62224c9b, 0x7f4e62251d37}, content_length = 487583, body_status = length, first_byte_timeout = 60.000000, between_bytes_timeout = 60.000000, }, director_req = 0x7f4e77de3eb0 { vcl_name = hg, type = round-robin { }, }, director_resp = 0x7f4e77d41d38 { vcl_name = hgweb3, type = backend { display_name = boot.hgweb3, ipv4 = 10.248.9.76, port = 80, hosthdr = 10.248.9.76, health=healthy, admin_health=probe, changed=1455428861.2, n_conn = 1, }, }, http[bereq] = 0x7f4e62221d50 { ws[Bo] = 0x7f4e622210e0, hdrs { \"GET\", \"/physician/dr-robert-dagostini-xxcsh\", \"HTTP/1.1\", \"host: www.healthgrades.com\", \"Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2\", \"CloudFront-Forwarded-Proto: http\", \"Cookie: hg.persistence=cHQ9NDAuNjgxODA2LC03NC42NTA4MiZzcGVjaWFsdHk9MzEmY2l0eT1CZWRtaW5zdGVyJnN0YXRlPU5KJnppcD0wNzkyMSZzcG9uc29yPSZmYWNpbGl0eT0mcHJvZHVjdD1CQVNJQw--; hg.search=displayLoc=Hartford%2c+CT&latLng=41.763321%2c-72.674072&cityState=Hartford%2c+CT&source=Default&isTablet=false&profType=Provider&state=CT&isStateOnly=false&zip=; hg.sessionInfo=c2Vzc2lvbklkPVMyOGI3YTNmOTc4MDY3MjRlJnJlcXVlc3RJZD1SODhkOWY4ZTQ0OGM2ZTI0ZSZleHBpcmVzPTIvMTMvMjAxNiAxMToxNzo1MSBQTQ--; hg.user=7VPPT8IwGJ0XPfhPmB48TeIAGSHxMNGICQJxw4PGQ9d9QuPWLW0ZEsJf5R_oX6ELGPHi2V76473vva99qXPgOM4nDjObcWgWH0cjmZc8ARkClWw6opJmoEGqyyXp54xqnosNFMG7Jh3So1K!5jJxT7oRcckDpMgpIYQUmIbkmitNBQOci5QusCDjSZICUjcylSjpLEmX68UA!XZkkWdOA5GEmmr4aWjQNfTEiytQ_p5qNt3X18SabFZBHEsoubUmOxzbQDcXAm!A2UwjhOJ4Zuxy1OQC!ZQR66OAniVY0PRqfqvRqHsuvpOY2NMzv15r_c1zv_4abn9ttqVuYbJyyaDqZhwGZv9bpwhVKY04e6uy6lGFF2!4XvvC95rt1elYGUgpLMT0ekCxIGAmnYjGKFVYEbyWof4n8ZckbtM8pqn9EosCvr!rI4c5JFVa2Ojzi0uGAiKewTAT2JuEmxKEttCdGsDcZkY6Ws7gezb7Pt3q_As-; hg.user.fsp=dVFNawIxEN1C6aV!ouS8lXUVF4QedEupoCJdvfQWk3ENxESyo61I!0!!ZTvZD1awzWWz89689yYT3ARB8EPHf!2585fv2xculFZ4yoA7sV1wx3eA4IqnM3tWxV7z09QKjsoaNmSv3OHGOhk_pEsWsjfQhBwhAw0CQVIDciOgbqSGnZJSA1EbaGJmSkPBht2oE4Ws0a7cl!CJ1y4V1qY4s5TyzinnBZd4vjoyMkOOcK3i0RJ6V!sxFDjjKLZ!jZTXJtVttF47OKrmAS44dYDUGkPDK3FAgkicat7OkqYy5Fd4sSkJ4EFSQ7!bSQa9Xtz1w5u8rj4mcWeQ9KMkDj13Wpq11BZmXyGbN2lW2cj!!5eUoAXPlcknZmPLkewHpYmjsg7zw24NjjZBT2wdjv2_fE_7i1QDNyDL_v0v; hg.user.geoip.loc=cityStateZipBestMatch=Ashburn%2c+VA+20147&lat=39.0329&lon=-77.4866; hg.viewed.appointments=13KX9H%2c1XYLRKTF; hg.viewed.profiles=12K8G3%2c12JB5D%2c12WF77%2c13KX9H%2c1X366B%2c173PJZ%2c1XH32J%2c1YCC2S%2c132CX8%2c1YMMPV%2c13YQMG%2c134N3J%2c1X4Y3R%2c1YHWRB%2c1XSLYV%2c1YR6W6%2c138K3X%2c13436K%2c12VKJQ%2c1YJSDM%2c132JVG%2c1GFMMB%2c12HXNK%2c1XYLRKTF%2c12YJ7Y%2c13JK7R%2c1YCLT6%2c12KQTP%2c12G7SG%2c1YTLNR%2c1XMGFW%2c12YG3X%2c1XLW32%2c123D6Y%2c1XG83M%2c12T6PP%2c13DQGP%2c1XXCSH; trackcookiestatus=cmVzZXQ9MA--\", \"User-Agent: Mozilla/5.0 (compatible; proximic; +http://www.proximic.com/info/spider.php)\", \"Via: 1.1 281d76a9bd6048ee3d031cfc163b6092.cloudfront.net (CloudFront)\", \"X-Amz-Cf-Id: dInjCxa8DRQlSojf5dLniARz4NmqEQ86p2F2zvRvWW1E_ohAbuSR2g==\", \"X-Forwarded-Port: 80\", \"X-Forwarded-Proto: http\", \"X-Forwarded-For: 54.85.57.249, 54.240.144.82, 10.248.8.177\", \"X-Mobile-Category: other\", \"X-Mobile-Type: other\", \"X-Backend-Type: hg\", \"X-Varnish: 917511\", }, }, http[beresp] = 0x7f4e62222870 { ws[Bo] = 0x7f4e622210e0, hdrs { \"HTTP/1.1\", \"200\", \"OK\", \"Cache-Control: public, max-age=0\", \"Content-Type: text/html; charset=utf-8\", \"Server: Microsoft-IIS/8.5\", \"Set-Cookie: hg.user=; expires=Sat, 13-Feb-2016 05:47:52 GMT; path=/\", \"Set-Cookie: hg.user=7VM9T8MwFAwLDPwJ5IEpVKQNTVWJIRREh9JWJGUAMTj2o7VInMh2A1XV38JPhec2UYsoCzNe!HH37p59snPgOM4nDjvbcWgXH0djlZeCg4qAKjYbU0UzMKD05ZIMckaNyOUGiuHdkC7pU2VecsXdk15MXHIPKXJKiCAFZoBfC22oZIBzkdIFFmSC8xSQupGpRUl3SXrCLIbotyOLPHsaSh4ZauCnoUXX0KMorkCbO2rYbF9f08pkswqTREEpKmuyw6ka6OVS4g0EmxuEUBzPrF2OmkKin7ZiAxQwc44FvtcI2q1W03PxneS0Oj0Lmo124J8HTddyB2uzLXULk5VLhnU3kyi0_986RahOaSzYa51Vn2q8eCvwOheB53dWpxNtIa2xENPrA8WCkNl0YpqgVFGJ4LUs9T_JvyRxm_YJTasvsSjg_7s_CHgDXqeFjT49u2QkIRYZjDKJvSm4KUGaCtrNYd8HWx1!AQ--; expires=Sun, 14-Feb-2016 06:17:52 GMT; path=/\", \"Set-Cookie: hg.sessionInfo=c2Vzc2lvbklkPVMyOGI3YTNmOTc4MDY3MjRlJnJlcXVlc3RJZD1SODhkOWY4ZTQ0OGM2ZTI0ZSZleHBpcmVzPTIvMTMvMjAxNiAxMToxNzo1MiBQTQ--; expires=Sun, 14-Feb-2016 06:17:52 GMT; path=/\", \"Set-Cookie: hg.persistence=cHQ9NDAuNjgxODA2LC03NC42NTA4MiZzcGVjaWFsdHk9MzEmY2l0eT1CZWRtaW5zdGVyJnN0YXRlPU5KJnppcD0wNzkyMSZzcG9uc29yPSZmYWNpbGl0eT0mcHJvZHVjdD1CQVNJQw--; expires=Sun, 14-Feb-2016 06:17:52 GMT; path=/\", \"Set-Cookie: hg.user.fsp=dVFNawIxEN1C6aV!ouS8lXUVF4QedEupoCJdvfQWk3ENxESyo61I!0!!ZTvZD1awzWWz89689yYT3ARB8EPHf!2585fv2xculFZ4yoA7sV1wx3eA4IqnM3tWxV7z09QKjsoaNmSv3OHGOhk_pEsWsjfQhBwhAw0CQVIDciOgbqSGnZJSA1EbaGJmSkPBht2oE4Ws0a7cl!CJ1y4V1qY4s5TyzinnBZd4vjoyMkOOcK3i0RJ6V!sxFDjjKLZ!jZTXJtVttF47OKrmAS44dYDUGkPDK3FAgkicat7OkqYy5Fd4sSkJ4EFSQ7!bSQa9Xtz1w5u8rj4mcWeQ9KMkDj13Wpq11BZmXyGbN2lW2cj!!5eUoAXPlcknZmPLkewHpYmjsg7zw24NjjZBT2wdjv2_fE_7i1QDNyDL_v0v; expires=Sun, 14-Feb-2016 06:17:52 GMT; path=/\", \"Set-Cookie: hg.search=displayLoc=Hartford%2c+CT&latLng=41.763321%2c-72.674072&cityState=Hartford%2c+CT&source=Default&isTablet=false&profType=Provider&state=CT&isStateOnly=false&zip=; domain=.healthgrades.com; path=/\", \"Set-Cookie: trackcookiestatus=cmVzZXQ9MA--; expires=Sun, 14-Feb-2016 06:17:52 GMT; path=/\", \"X-UA-Compatible: IE=edge,chrome=1\", \"Access-Control-Allow-Origin: *\", \"Access-Control-Allow-Methods: GET\", \"Date: Sun, 14 Feb 2016 05:47:52 GMT\", \"Content-Length: 487583\", }, }, objcore[fetch] = 0x7f4e5803d0c0 { refcnt = 2, flags = 0x10e, exp_flags = 0x0, exp = { 1455428878.514611, 120.000000, 10.000000, 0.000000 } objhead = 0x7f4e77cc60e0, stevedore = 0x7f4e77ca2480 (malloc Transient), }, vcl = { temp = warm srcname = { \"/etc/varnish/default.vcl\", \"Builtin\", \"/etc/varnish/hgweb_backends.vcl\", \"/etc/varnish/hgnew3_backends.vcl\", \"/etc/varnish/m_backends.vcl\", \"/etc/varnish/ucms_backends.vcl\", \"/etc/varnish/mobile_detect.vcl\", \"/etc/varnish/mobile_be_detect.vcl\", \"/etc/varnish/uisvc_backends.vcl\", \"/etc/varnish/vcl_init.vcl\", }, }, }, " }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Feb 14 05:59:23 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 14 Feb 2016 05:59:23 -0000 Subject: [Varnish] #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: In-Reply-To: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> References: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> Message-ID: <058.f9ceac6dd90a1cc586d9a0a9bc7c8149@varnish-cache.org> #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by billnbell): I increased it from 64k to 200k and still got problems. So I increased it to 400k. Watching it. {{{ # varnishadm param.show | grep -v default cli_timeout 25.000 [seconds] http_max_hdr 164 [header lines] http_req_hdr_len 16k [bytes] http_req_size 100k [bytes] http_resp_hdr_len 16k [bytes] http_resp_size 100k [bytes] listen_depth 2048 [connections] nuke_limit 10000 [allocations] thread_pool_add_delay 2.000 [seconds] thread_pool_max 4000 [threads] thread_pool_min 200 [threads] thread_pools 4 [pools] workspace_backend 400k [bytes] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Feb 14 11:50:37 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 14 Feb 2016 11:50:37 -0000 Subject: [Varnish] #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: In-Reply-To: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> References: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> Message-ID: <058.f9ed1bc63f11271f8386a763176dbd78@varnish-cache.org> #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by fgsch): The workspace being exhausted is the backend workspace. The hint is in the panic: {{{ OVERFLOW id = \"Bo\", }}} I'd say the long cookies are involved on this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Feb 14 11:55:09 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 14 Feb 2016 11:55:09 -0000 Subject: [Varnish] #1856: LostHeader setting req.url to an empty string In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.83c70b21ddf2fc45e7a33e197c1db917@varnish-cache.org> #1856: LostHeader setting req.url to an empty string ------------------------+----------------------- Reporter: gdelacroix | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Comment (by fgsch): In previous version the request will not fail but further **set req.** would be ignored. Starting with 4.1 we fail the request altogether. I think the issue here is whether we should allow to set variables to an empty value via vrt_do_string(). These variables are special and it doesn't make sense to set e.g. proto to "". In any case, the workspace exhaustion is incorrect here. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Feb 14 19:58:51 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 14 Feb 2016 19:58:51 -0000 Subject: [Varnish] #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: In-Reply-To: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> References: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> Message-ID: <058.2970e38a8e0f9c65b407f78a0a369c23@varnish-cache.org> #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by billnbell): Ok I guessed on increasing workspace_backend to 400k . Is this the right place to increase for OVERFLOW id = \"Bo\" ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 16 08:20:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Feb 2016 08:20:15 -0000 Subject: [Varnish] #1847: HTTP1_DissectRequest doesn't handle https In-Reply-To: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> References: <047.b20bca93e8aec463a17ca3599f5770dc@varnish-cache.org> Message-ID: <062.21fef03a822935ce9047da21a5bdc586@varnish-cache.org> #1847: HTTP1_DissectRequest doesn't handle https -----------------------+--------------------- Reporter: gquintard | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -----------------------+--------------------- Changes (by gquintard): * status: new => closed * resolution: => fixed Comment: Fixed by e96478c2aea2a5c6f2e3efaff94508c3f0d43d87 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 16 12:53:31 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Feb 2016 12:53:31 -0000 Subject: [Varnish] #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: In-Reply-To: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> References: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> Message-ID: <058.1a8cb50267bf4564eca62af90061326a@varnish-cache.org> #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: ----------------------+----------------------- Reporter: slink | Owner: slink Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by slink): yes, `workspace_backend` is the right parameter to tune for working around this issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 17 10:23:11 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Feb 2016 10:23:11 -0000 Subject: [Varnish] #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: In-Reply-To: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> References: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> Message-ID: <058.9f90eb1c5b26d1eb2da7707c308aaaa5@varnish-cache.org> #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: ----------------------+--------------------- Reporter: slink | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Nils Goroll ): * status: reopened => closed * resolution: => fixed Comment: In [356854cd86b1866b492bbe64417d1ace6e19a9b3]: {{{ #!CommitTicketReference repository="" revision="356854cd86b1866b492bbe64417d1ace6e19a9b3" Fix workspace overflow handling in VFP_Push() and test for it This fix avoids a WS_Alloc panic when pushing fetch processors and should thus avoid panics by overflowing the backend workspace in vcl. This overflow is logged as FetchError "Bo workspace overflowed". Other panic points due to workspace_backend being set too low still exist. Sizing estimate for workspace_backend: sizeof(struct busyobj) + 3 * HTTP_estimate(cache_param->http_max_hdr) + cache_param->vsl_buffer + cache_param->http_resp_size + fetch processor memory + space required in VCL Fixes #1739 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 17 10:57:11 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Feb 2016 10:57:11 -0000 Subject: [Varnish] #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code In-Reply-To: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> References: <043.5ec9de46fe8e4464171efc5b34a690f3@varnish-cache.org> Message-ID: <058.e2815840ed0450dbf033b26b2306dab9@varnish-cache.org> #1844: VMODs: ENUM followed by STRING_LIST in an object constructor causes illegal C code -------------------------------------+------------------------------------- Reporter: geoff | Owner: Federico G. Schwindt Type: defect | Priority: high | Status: closed Component: vmod | Milestone: Later Severity: major | Version: trunk Keywords: | Resolution: fixed vmod,object,enum,string_list | -------------------------------------+------------------------------------- Comment (by Lasse Karstensen ): In [6d7edfce44476a0f078476570b689d3d335b0aed]: {{{ #!CommitTicketReference repository="" revision="6d7edfce44476a0f078476570b689d3d335b0aed" Correct ENUM handling in object constructors Discussed with phk at . Fix confirmed by geoff at . Fixes #1844. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 17 13:30:55 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Feb 2016 13:30:55 -0000 Subject: [Varnish] #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: In-Reply-To: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> References: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> Message-ID: <058.50ae59736bd15cb9ef6689acfa8239c4@varnish-cache.org> #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: ----------------------+--------------------- Reporter: slink | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Lasse Karstensen ): In [b06e54c6d188f3b96cbe934e38e0a3918548e871]: {{{ #!CommitTicketReference repository="" revision="b06e54c6d188f3b96cbe934e38e0a3918548e871" Fix workspace overflow handling in VFP_Push() and test for it This fix avoids a WS_Alloc panic when pushing fetch processors and should thus avoid panics by overflowing the backend workspace in vcl. This overflow is logged as FetchError "Bo workspace overflowed". Other panic points due to workspace_backend being set too low still exist. Sizing estimate for workspace_backend: sizeof(struct busyobj) + 3 * HTTP_estimate(cache_param->http_max_hdr) + cache_param->vsl_buffer + cache_param->http_resp_size + fetch processor memory + space required in VCL Fixes #1739 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 18 16:59:16 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Feb 2016 16:59:16 -0000 Subject: [Varnish] #1858: Stale hit-for-pass objects generating 200 responses with missing content Message-ID: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> #1858: Stale hit-for-pass objects generating 200 responses with missing content -------------------+---------------------- Reporter: dmz | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.1.1 | Severity: major Keywords: | -------------------+---------------------- Varnish is sending an If-Modified-Since header to the backend on stale hit-for-pass, then serving backend 304 responses as 200 responses with missing content. It appears to be related to the changes introduced in https://www.varnish- cache.org/trac/changeset/51e0af5ad29b9f1c15958c05b67dccfcb2beb95b/ as backing out this changeset fixes the issue. There is a simple reproducer, but note that it is timing sensitive (have to wait for the object to fall out of hit-for-pass and become stale). How to reproduce: (Files enclosed, vcl simply sets a default backend, no other behaviour modified) Varnish listening on 127.0.0.1:80, connecting to an Apache webserver on 192.168.0.180:80. test.sh script run on the varnish server, requests content locally. Expected response: {{{ $ ./test.sh HTTP/1.1 200 OK Date: Thu, 18 Feb 2016 14:52:22 GMT Server: Apache Last-Modified: Thu, 18 Feb 2016 14:47:12 GMT Accept-Ranges: bytes Content-Length: 827 Cache-Control: max-age=0, no-cache, no-store, must-revalidate Pragma: no-cache Expires: Thu, 1 Jan 1970 00:00:00 GMT Content-Type: text/plain; charset=UTF-8 X-Varnish: 33178 Age: 0 Via: 1.1 varnish-v4 Accept-Ranges: bytes Connection: close Li Europan lingues es membres del sam familie. Lor separat existentie es un myth. Por scientie, musica, sport etc, litot Europa usa li sam vocabular. Li lingues differe solmen in li grammatica, li pronunciation e li plu commun vocabules. Omnicos directe al desirabilite de un nov lingua franca: On refusa continuar payar custosi traductores. At solmen va esser necessi far uniform grammatica, pronunciation e plu commun paroles. Ma quande lingues coalesce, li grammatica del resultant lingue es plu simplic e regulari quam ti del coalescent lingues. Li nov lingua franca va esser plu simplic e regulari quam li existent Europan lingues. It va esser tam simplic quam Occidental in fact, it va esser Occidental. A un Angleso it va semblar un simplificat Angles, quam un skeptic Cambridge amico dit me que Occidental es. }}} Response on error: {{{ $ ./test.sh HTTP/1.1 200 OK Date: Thu, 18 Feb 2016 14:52:33 GMT Server: Apache Expires: Thu, 1 Jan 1970 00:00:00 GMT Cache-Control: max-age=0, no-cache, no-store, must-revalidate Last-Modified: Thu, 18 Feb 2016 14:47:12 GMT Accept-Ranges: bytes Content-Length: 827 Pragma: no-cache Content-Type: text/plain; charset=UTF-8 X-Varnish: 434 Age: 0 Via: 1.1 varnish-v4 Accept-Ranges: bytes Connection: close }}} (Note that no content is returned to the client). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Feb 20 19:52:51 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 20 Feb 2016 19:52:51 -0000 Subject: [Varnish] #1858: Stale hit-for-pass objects generating 200 responses with missing content In-Reply-To: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> References: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> Message-ID: <056.52804d18f3582e6b1fb6934178a49d67@varnish-cache.org> #1858: Stale hit-for-pass objects generating 200 responses with missing content ----------------------+-------------------- Reporter: dmz | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.1 Severity: major | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): Varnish should not send an IMS request for hit-for-pass objects. Testcase in .vtc format attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 11:08:58 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 11:08:58 -0000 Subject: [Varnish] #1858: Stale hit-for-pass objects generating 200 responses with missing content In-Reply-To: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> References: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> Message-ID: <056.9fa04a1414d9873a6a411f6948c72ebe@varnish-cache.org> #1858: Stale hit-for-pass objects generating 200 responses with missing content ----------------------+-------------------- Reporter: dmz | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.1 Severity: major | Resolution: Keywords: | ----------------------+-------------------- Comment (by dmz): Confirm fail when enforcing the expect line in this test case. Without the enforce, test will pass with IMS sent to server (issues same response regardless of query). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 12:02:22 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 12:02:22 -0000 Subject: [Varnish] #1858: Stale hit-for-pass objects generating 200 responses with missing content In-Reply-To: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> References: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> Message-ID: <056.18d27c971bc3cc4fdf337890c5012d5a@varnish-cache.org> #1858: Stale hit-for-pass objects generating 200 responses with missing content ----------------------+--------------------- Reporter: dmz | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.1 Severity: major | Resolution: Keywords: | ----------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 12:20:01 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 12:20:01 -0000 Subject: [Varnish] #1856: LostHeader setting req.url to an empty string In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.8cdbab2fea11f68e3f52e43a961eede5@varnish-cache.org> #1856: LostHeader setting req.url to an empty string ------------------------+----------------------- Reporter: gdelacroix | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Comment (by lkarsten): Discussed at (live) bugwash today. There are two issues: if you mangle req, proto or method in VCL for a non- hit you end up in a bad place. The ws overflow handling is wrong, but generalised it is a "vcl author did something stupid" kind of situation. Add a vcl_500 sub where a one-off 500 error can be configured, instead of the static one we serve now. We discussed this on the Rotterdam VDD, and the controversy was that the canned response should be per-request configurable. One solution to this is to allow the 500 response to be a 302, where the admin can redirect to a more descriptive page. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 12:22:48 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 12:22:48 -0000 Subject: [Varnish] #1815: Child died on pipe request In-Reply-To: <045.fd9ff74855f45ed16026a18196ea076c@varnish-cache.org> References: <045.fd9ff74855f45ed16026a18196ea076c@varnish-cache.org> Message-ID: <060.2e239f97ed4d7c41470964c6ce6e4cd1@varnish-cache.org> #1815: Child died on pipe request -------------------------+-------------------- Reporter: jferjan | Owner: Dridi Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: major | Resolution: Keywords: pipe, panic | -------------------------+-------------------- Changes (by Dridi): * owner: => Dridi -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 12:28:28 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 12:28:28 -0000 Subject: [Varnish] #1830: VSL API: "duplicate link" errors in request grouping when vsl_buffer is increased In-Reply-To: <043.aa684f175db5954239cc4d4515a36183@varnish-cache.org> References: <043.aa684f175db5954239cc4d4515a36183@varnish-cache.org> Message-ID: <058.12bcc65ac813f911ab9519b41383c0c5@varnish-cache.org> #1830: VSL API: "duplicate link" errors in request grouping when vsl_buffer is increased -------------------------------------------+------------------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 Component: varnishd | release Severity: normal | Version: Keywords: VSL,duplicate link,vsl_buffer | Resolution: -------------------------------------------+------------------------------- Changes (by martin): * version: 4.0.3 => Comment: Removing the 4.0.3 as this issue probably also applies to master. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 12:28:47 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 12:28:47 -0000 Subject: [Varnish] #1830: VSL API: "duplicate link" errors in request grouping when vsl_buffer is increased In-Reply-To: <043.aa684f175db5954239cc4d4515a36183@varnish-cache.org> References: <043.aa684f175db5954239cc4d4515a36183@varnish-cache.org> Message-ID: <058.a4e43cf3cf78195fe94f52fd063c45f4@varnish-cache.org> #1830: VSL API: "duplicate link" errors in request grouping when vsl_buffer is increased -------------------------------------------+------------------------------- Reporter: geoff | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 Component: varnishd | release Severity: normal | Version: Keywords: VSL,duplicate link,vsl_buffer | Resolution: -------------------------------------------+------------------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 12:35:02 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 12:35:02 -0000 Subject: [Varnish] #1794: varnish*-tools do not die when terminal disconnects In-Reply-To: <041.5e0136e0890c547547da2629f527e416@varnish-cache.org> References: <041.5e0136e0890c547547da2629f527e416@varnish-cache.org> Message-ID: <056.128df0a9fc8eadc50f68380ea20cf49c@varnish-cache.org> #1794: varnish*-tools do not die when terminal disconnects --------------------+--------------------------------------------- Reporter: kwy | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------------------------------- Changes (by lkarsten): * status: reopened => closed * resolution: => fixed Comment: It would be nice to have the HUP handler for reopening the file in foreground mode to use the new systemd simplicity, but that is really a future feature and not a bug. The current handling works fine, as far as I can tell. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 12:37:49 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 12:37:49 -0000 Subject: [Varnish] #1750: Fail more gracefully on -l >= 4GB In-Reply-To: <043.043bbd8ec6de89449726e0316939ec56@varnish-cache.org> References: <043.043bbd8ec6de89449726e0316939ec56@varnish-cache.org> Message-ID: <058.5a93281813c656e9449ef95211185075@varnish-cache.org> #1750: Fail more gracefully on -l >= 4GB ----------------------+--------------------- Reporter: geoff | Owner: martin Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+--------------------- Changes (by phk): * version: 4.0.3 => trunk * milestone: Varnish 4.0 release => -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 12:43:44 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 12:43:44 -0000 Subject: [Varnish] #1754: n_objecthead increase just before oomkill In-Reply-To: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> References: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> Message-ID: <061.b36a9c3aa25136850a57ba125972bcbd@varnish-cache.org> #1754: n_objecthead increase just before oomkill ----------------------+------------------ Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+------------------ Changes (by lkarsten): * version: 4.0.3 => Comment: dmz: can you please supply a varnishstat -1 output of 1) stable state, and 2) just before you restart it? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 12:51:13 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 12:51:13 -0000 Subject: [Varnish] #1754: n_objecthead increase just before oomkill In-Reply-To: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> References: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> Message-ID: <061.45ea451f398f147debf8c06d89ff6206@varnish-cache.org> #1754: n_objecthead increase just before oomkill ----------------------+------------------ Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+------------------ Comment (by slink): Also it would be good to know if you could lower the malloc stevedore size to a safe value (like 1/3 of your available memory) and see if this issue still arises. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 13:26:25 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 13:26:25 -0000 Subject: [Varnish] #1754: n_objecthead increase just before oomkill In-Reply-To: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> References: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> Message-ID: <061.2c19a827ccb5794b8f746cfc54c40233@varnish-cache.org> #1754: n_objecthead increase just before oomkill ----------------------+------------------ Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+------------------ Comment (by dmz): I'm very sorry to have got your hopes up on tracking this one down, if it exists. We currently suspect our own increase in useage was as simple as large TTL objects slowly filling the cache, coupled with an overly optimistic malloc size. We've imposed a maximum TTL, but due to several recent unscheduled restarts won't know for around another week if it is now genuinely stable or not (enclosed a graph of memory use showing two weeks of "leaking" followed by reconfiguration with max TTL, initially with a much reduced malloc size). I won't update further unless we see further "leaking". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 13:38:45 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 13:38:45 -0000 Subject: [Varnish] #1754: n_objecthead increase just before oomkill In-Reply-To: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> References: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> Message-ID: <061.a60bef6c4c876c32fd0740b0ad832483@varnish-cache.org> #1754: n_objecthead increase just before oomkill ----------------------+------------------ Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+------------------ Comment (by slink): Just in case this helps, here's some background and a hypothesis: The malloc stevedore size you configure is a net value, limiting the total sum of all allocations which varnishd may issue to the malloc implementation, usually jemalloc. Because varnishd requests allocations of different sizes, memory freed by expiring objects or lru nuking them may not be usable, by the malloc implementation, to satisfy new allocation requests, so the gross amount of memory required may be significantly larger than the net value configure. My personal ballpark figure from real life experience is a factor of 2-3. My hypothesis on what you're seeing is that allocations are satisfied until your cache is forced to nuke objects, from which point on you'd see the gross/net ratio rise. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 14:05:53 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 14:05:53 -0000 Subject: [Varnish] #1754: n_objecthead increase just before oomkill In-Reply-To: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> References: <046.913b54b05f4537fbf8fe340cac2f9093@varnish-cache.org> Message-ID: <061.0a2b447e3100821a01d1efed0ee638bf@varnish-cache.org> #1754: n_objecthead increase just before oomkill ----------------------+----------------------- Reporter: lkarsten | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Changes (by slink): * status: new => needinfo -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 14:14:06 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 14:14:06 -0000 Subject: [Varnish] #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 In-Reply-To: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> References: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> Message-ID: <058.520d61358135de3904ba744424c71b9d@varnish-cache.org> #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 ----------------------+---------------------------------- Reporter: geoff | Owner: geoff Type: defect | Status: reopened Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by geoff): patch pushed, but evidently I don't have the bits to close the ticket -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 15:41:41 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 15:41:41 -0000 Subject: [Varnish] #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 In-Reply-To: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> References: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> Message-ID: <058.e07bdb498548a662366dcfd5a69d92d6@varnish-cache.org> #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 ----------------------+---------------------------------- Reporter: geoff | Owner: geoff Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------- Changes (by Dridi): * status: reopened => closed * resolution: => fixed Comment: Fixed in [f4539dd2166bfd422a722967fe31e2e3e2c93ad5] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 22 17:21:48 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Feb 2016 17:21:48 -0000 Subject: [Varnish] #1815: Child died on pipe request In-Reply-To: <045.fd9ff74855f45ed16026a18196ea076c@varnish-cache.org> References: <045.fd9ff74855f45ed16026a18196ea076c@varnish-cache.org> Message-ID: <060.e8dccedc8936d0dd4afa2a03c21e06a7@varnish-cache.org> #1815: Child died on pipe request -------------------------+----------------------- Reporter: jferjan | Owner: Dridi Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: major | Resolution: Keywords: pipe, panic | -------------------------+----------------------- Changes (by Dridi): * status: new => assigned Comment: This doesn't look like a duplicate because in #1730 the assertion triggers after a failed getfd, whereas in this case it's before. I have tried to reproduce it and AFAICT the only VCL way to end up with a NULL {{{(struct busyobj).director}}} is to either set the {{{req.backend_hint}}} or {{{bereq.backend}}} to NULL which is not allowed by the VCL compiler unless you use a VMOD? When setting a NULL {{{bereq.backend}}} Varnish seems to recover and pick the default backend. I narrowed it down to this: {{{ $ cat bin/varnishtest/tests/r01815.vtc varnishtest "backend unreachable on piped request" server s1 { rxreq txresp } -start varnish v1 -vcl+backend { import ${vmod_debug}; sub vcl_recv { set req.backend_hint = debug.no_backend(); } } -start client c1 { txreq -req PROPFIND rxresp expect resp.status == 200 } -run }}} It looks an awful lot like #1501 for piped requests :) jferjan, are you using a director? Can you share your VCL or confirm it may be a director failing to pick a backend? phk, it looks like something Varnish should handle properly with either a synthetic 500 response or picking the default backend. Thoughts? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 23 17:52:04 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Feb 2016 17:52:04 -0000 Subject: [Varnish] #1859: Average Hitrate Reported by Varnishstat Inaccurate Message-ID: <043.84daa5379ecc7197454a1af0d51ed7ec@varnish-cache.org> #1859: Average Hitrate Reported by Varnishstat Inaccurate ---------------------------------+------------------------- Reporter: batty | Type: defect Status: new | Priority: normal Milestone: | Component: varnishstat Version: 4.1.1 | Severity: normal Keywords: varnishtat hit rate | ---------------------------------+------------------------- We're in the process of upgrading from varnish 3.0.3 to varnish 4.1.1. During the upgrade it was noticed that the average hit rate reported by varnishstat in 4.1.1 does not match the hit rate calculated from the individual hit/miss metrics. We have two servers running, one still on version 3.0.3 and one updated to version 4.1.1. I restarted both servers at roughly the same time and immediately began running varnishstat each. The average hit rate according to varnish 4.1.1 is: 0.2465 0.3085 0.3127[[br]] The average hit rate according to varnish 3.0.3 is: 0.6592 0.6402 0.6182 Here is a varnishstat -1 dump from each server:[[br]] varnishstat -1 4.1.1: http://pastebin.com/tP5AE995 [[br]] varnishstat -1 3.0.3: http://pastebin.com/cg51CuUS Relevant metrics from 4.1.1: {{{ MAIN.cache_hit 47970 20.23 Cache hits MAIN.cache_miss 22402 9.45 Cache misses }}} Relevant metrics from 3.0.3: {{{ cache_hit 46306 19.81 Cache hits cache_miss 23223 9.94 Cache misse }}} From what I understand hit rate is calculated as cache_hit / (cache_hit + cache_miss) so... For varnish 4.1.1:[[br]] 47970 / (47970 + 22402) = .6816 For varnish 3.0.3:[[br]] 46306 / (46306 + 23223) = .6659 Both of these calculations correspond roughly to the average hit rate being reported by varnishstat in 3.0.3, however varnish 4.1.1 is reporting the much lower (0.2465 0.3085 0.3127). Is the hit rate being reported by varnishtat calculated differently in 4.1.1? I reported this the IRC channel and it was suggested I file a ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 23 18:33:17 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Feb 2016 18:33:17 -0000 Subject: [Varnish] #1859: Average Hitrate Reported by Varnishstat Inaccurate In-Reply-To: <043.84daa5379ecc7197454a1af0d51ed7ec@varnish-cache.org> References: <043.84daa5379ecc7197454a1af0d51ed7ec@varnish-cache.org> Message-ID: <058.438f5a7a29c8d051d26e5497491638f9@varnish-cache.org> #1859: Average Hitrate Reported by Varnishstat Inaccurate ---------------------------------+-------------------- Reporter: batty | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: 4.1.1 Severity: normal | Resolution: Keywords: varnishtat hit rate | ---------------------------------+-------------------- Comment (by batty): {{{ varnishd -V varnishd (varnish-4.1.1 revision 66bb824) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2015 Varnish Software AS }}} Installed 4.1.1 from: https://repo.varnish- cache.org/redhat/varnish-4.1/el6/x86_64/varnish/ These two packages are installed: {{{ varnish-4.1.1-2.el6.x86_64 varnish-libs-4.1.1-2.el6.x86_64 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 24 12:03:41 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Feb 2016 12:03:41 -0000 Subject: [Varnish] #1860: ESI-related memory leaks Message-ID: <043.d1642b45ea53a8b5b5d2ad09c0caf12c@varnish-cache.org> #1860: ESI-related memory leaks --------------------+------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.1.2 Severity: normal | Keywords: --------------------+------------------- Did a quick ASAN run w/ the leak checking enabled for 4.1.2. For most (all?) of the ESI fetch VTCs, it detects a couple of leaks that we probably want to look into. 1) {{{ *** v1 3.2 debug| Info: Child (26687) said Direct leak of 40 byte(s) in 1 object(s) allocated from:\n *** v1 3.2 debug| Info: Child (26687) said #0 0x4cea62 in malloc (/home/daghf/varnish-master/bin/varnishd/.libs/lt-varnishd+0x4cea62)\n *** v1 3.2 debug| Info: Child (26687) said #1 0x7f5313479762 in VSB_new /home/daghf/varnish-master/lib/libvarnish/vsb.c:226:6\n *** v1 3.2 debug| Info: Child (26687) said #2 0x577bd4 in VEP_Parse /home/daghf/varnish- master/bin/varnishd/cache/cache_esi_parse.c:889:20\n *** v1 3.2 debug| Info: Child (26687) said #3 0x56a18b in vfp_esi_pull /home/daghf/varnish- master/bin/varnishd/cache/cache_esi_fetch.c:254:3\n *** v1 3.2 debug| Info: Child (26687) said #4 0x5ba8c8 in VFP_Suck /home/daghf/varnish-master/bin/varnishd/cache/cache_fetch_proc.c:172:8\n *** v1 3.2 debug| Info: Child (26687) said #5 0x5b621e in vbf_fetch_body_helper /home/daghf/varnish- master/bin/varnishd/cache/cache_fetch.c:511:10\n *** v1 3.2 debug| Info: Child (26687) said #6 0x5aeb07 in vbf_stp_fetch /home/daghf/varnish- master/bin/varnishd/cache/cache_fetch.c:670:3\n *** v1 3.2 debug| Info: Child (26687) said #7 0x59d235 in vbf_fetch_thread /home/daghf/varnish- master/bin/varnishd/../../include/tbl/steps.h:63:1\n *** v1 3.2 debug| Info: Child (26687) said #8 0x7191f6 in Pool_Work_Thread /home/daghf/varnish- master/bin/varnishd/cache/cache_wrk.c:341:4\n *** v1 3.2 debug| Info: Child (26687) said #9 0x716a0d in WRK_Thread /home/daghf/varnish- master/bin/varnishd/cache/cache_wrk.c:121:2\n *** v1 3.2 debug| Info: Child (26687) said #10 0x715d27 in pool_thread /home/daghf/varnish- master/bin/varnishd/cache/cache_wrk.c:371:2\n *** v1 3.2 debug| Info: Child (26687) said #11 0x7f53120a2283 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7283)\n }}} 2) {{{ *** v1 2.5 debug| Info: Child (747) said Direct leak of 64 byte(s) in 1 object(s) allocated from:\n *** v1 2.5 debug| Info: Child (747) said #0 0x4cebdb in calloc (/home/daghf/varnish-master/bin/varnishd/.libs/lt-varnishd+0x4cebdb)\n *** v1 2.5 debug| Info: Child (747) said #1 0x568ebd in vfp_esi_init /home/daghf/varnish- master/bin/varnishd/cache/cache_esi_fetch.c:227:2\n *** v1 2.5 debug| Info: Child (747) said #2 0x5b96ab in VFP_Open /home/daghf/varnish-master/bin/varnishd/cache/cache_fetch_proc.c:137:17\n *** v1 2.5 debug| Info: Child (747) said #3 0x5ad2d3 in vbf_stp_fetch /home/daghf/varnish- master/bin/varnishd/cache/cache_fetch.c:624:6\n *** v1 2.5 debug| Info: Child (747) said #4 0x59d235 in vbf_fetch_thread /home/daghf/varnish- master/bin/varnishd/../.n./include/tbl/steps.h:63:1\n *** v1 2.5 debug| Info: Child (747) said #5 0x7191f6 in Pool_Work_Thread /home/daghf/varnish- master/bin/varnishd/cache/cache_wrk.c:341:4\n *** v1 2.5 debug| Info: Child (747) said #6 0x716a0d in WRK_Thread /home/daghf/varnish-master/bin/varnishd/cache/cache_wrk.c:121:2\n *** v1 2.5 debug| Info: Child (747) said #7 0x715d27 in pool_thread /home/daghf/varnish- master/bin/varnishd/cache/cache_wrk.c:371:2\n *** v1 2.5 debug| Info: Child (747) said #8 0x7fac5de0e283 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7283)\n }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 24 12:10:41 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Feb 2016 12:10:41 -0000 Subject: [Varnish] #1860: ESI-related memory leaks In-Reply-To: <043.d1642b45ea53a8b5b5d2ad09c0caf12c@varnish-cache.org> References: <043.d1642b45ea53a8b5b5d2ad09c0caf12c@varnish-cache.org> Message-ID: <058.5cae938a6b752c164b74a166a9a84c40@varnish-cache.org> #1860: ESI-related memory leaks --------------------+-------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.1.2 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by daghf): To reproduce, build with {{{ ./autogen.des CC=clang --without-jemalloc CFLAGS="-fno-omit-frame-pointer -fsanitize=address -fsanitize-recover" }}} The -fsanitize-recover option lets asan continue after spotting an error if you also do {{{ export ASAN_OPTIONS=halt_on_error=0 }}} to get symbols in the output you also need to set ASAN_SYMBOLIZER_PATH to point at your llvm-symbolizer application, e.g. {{{ export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.6 }}} Be warned that the signal to noise ratio in the resulting make check test- suite.log is rather staggering. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 24 12:34:15 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Feb 2016 12:34:15 -0000 Subject: [Varnish] #1858: Stale hit-for-pass objects generating 200 responses with missing content In-Reply-To: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> References: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> Message-ID: <056.a25f64829020ec00070140f33ced40ff@varnish-cache.org> #1858: Stale hit-for-pass objects generating 200 responses with missing content ----------------------+--------------------- Reporter: dmz | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.1 Severity: major | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: In [1f37998adbc5e68d0b20006436d9bef226ca9bdc]: {{{ #!CommitTicketReference repository="" revision="1f37998adbc5e68d0b20006436d9bef226ca9bdc" Hit-for-pass objects are not IMS candidates Original test case by fgsch Fixes: #1858 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 24 12:36:25 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Feb 2016 12:36:25 -0000 Subject: [Varnish] #1858: Stale hit-for-pass objects generating 200 responses with missing content In-Reply-To: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> References: <041.1979cc04915d19c7292158b7d907ba19@varnish-cache.org> Message-ID: <056.c3c8e37bdc0c4465b8dcdfd5100ae244@varnish-cache.org> #1858: Stale hit-for-pass objects generating 200 responses with missing content ----------------------+--------------------- Reporter: dmz | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.1 Severity: major | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Martin Blix Grydeland ): In [4f2af500ee64091e8a7c17a2a68026ae8920804c]: {{{ #!CommitTicketReference repository="" revision="4f2af500ee64091e8a7c17a2a68026ae8920804c" Hit-for-pass objects are not IMS candidates Original test case by fgsch Fixes: #1858 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 24 13:26:20 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 24 Feb 2016 13:26:20 -0000 Subject: [Varnish] #1861: varnishadm - help command Message-ID: <047.a5b2dea1035f5dee25ea4a1470af97eb@varnish-cache.org> #1861: varnishadm - help command -----------------------+------------------------- Reporter: phnakarin | Type: enhancement Status: new | Priority: lowest Milestone: | Component: varnishadm Version: 4.0.3 | Severity: trivial Keywords: | -----------------------+------------------------- This is a cosmetic issue. It would be nice if varnishadm sorts out outputs, for example; from 'help' command, alphabetically. {{{ varnish> help 200 help [] ping [] auth quit banner status start stop vcl.load vcl.inline vcl.use vcl.discard vcl.list param.show [-l] [] param.set panic.show panic.clear storage.list vcl.show [-v] backend.list [] backend.set_health ban [&& ]... ban.list }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 26 07:57:56 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Feb 2016 07:57:56 -0000 Subject: [Varnish] #1860: ESI-related memory leaks In-Reply-To: <043.d1642b45ea53a8b5b5d2ad09c0caf12c@varnish-cache.org> References: <043.d1642b45ea53a8b5b5d2ad09c0caf12c@varnish-cache.org> Message-ID: <058.e4e448996d0d1d02105c1ee74abc88a6@varnish-cache.org> #1860: ESI-related memory leaks --------------------+-------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.1.2 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by phk): It seems like the leak-sanitizer part of address-sanitizer is only available on Linux: http://clang.llvm.org/docs/LeakSanitizer.html#id2 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 26 08:00:25 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Feb 2016 08:00:25 -0000 Subject: [Varnish] #1855: varnishstat width is limited to 999GB (12 chars) for byte counters In-Reply-To: <043.645c04c96f766732bf122865b24e378a@varnish-cache.org> References: <043.645c04c96f766732bf122865b24e378a@varnish-cache.org> Message-ID: <058.1fe121b6e8ae4133f14fe45be2692b13@varnish-cache.org> #1855: varnishstat width is limited to 999GB (12 chars) for byte counters -------------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by fgsch): I spoke with Martin and we agreed to keep the existing width but add some visual hint to indicate the truncation (e.g. ellipsis) for when auto scaling is off (default is on). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 26 17:14:13 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 26 Feb 2016 17:14:13 -0000 Subject: [Varnish] #1860: ESI-related memory leaks In-Reply-To: <043.d1642b45ea53a8b5b5d2ad09c0caf12c@varnish-cache.org> References: <043.d1642b45ea53a8b5b5d2ad09c0caf12c@varnish-cache.org> Message-ID: <058.e1829e9ed4c0d0e61295c64b618e4286@varnish-cache.org> #1860: ESI-related memory leaks --------------------+---------------------------------------- Reporter: daghf | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.1.2 Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [29313f17d58cd36e8926103316ad4e866e195527]: {{{ #!CommitTicketReference repository="" revision="29313f17d58cd36e8926103316ad4e866e195527" Always close the VFP stack, also on BS_NONE. Fixes: #1860 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 09:15:44 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 09:15:44 -0000 Subject: [Varnish] #1862: Request URL with whitespace is allowed Message-ID: <045.7cd1851542a40f5e7a193132a1812872@varnish-cache.org> #1862: Request URL with whitespace is allowed ----------------------+--------------------- Reporter: espebra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Keywords: ----------------------+--------------------- Client requests to {{{/foo bar}}} are accepted by varnishd and are handled as/translated to {{{/foo}}} - which most likely will end up with the wrong content being served. Requests to {{{/foo bar}}} are not properly encoded, and thereby invalid according to the RFC. RFC 7230 section 3.1.1 (https://tools.ietf.org/html/rfc7230#section-3.1.1) says: Recipients of an invalid request-line SHOULD respond with either a 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded. A recipient SHOULD NOT attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately crafted to bypass security filters along the request chain. I have attached a simple test case which passes with the current "non-RFC compliant" behaviour. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 09:17:30 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 09:17:30 -0000 Subject: [Varnish] #1862: Request URL with whitespace is allowed In-Reply-To: <045.7cd1851542a40f5e7a193132a1812872@varnish-cache.org> References: <045.7cd1851542a40f5e7a193132a1812872@varnish-cache.org> Message-ID: <060.89dd559b13c7b1c4bc09a21fff57bc81@varnish-cache.org> #1862: Request URL with whitespace is allowed ----------------------+-------------------- Reporter: espebra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by espebra): * version: unknown => 4.0.3 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 09:48:34 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 09:48:34 -0000 Subject: [Varnish] #1862: Request URL with whitespace is allowed In-Reply-To: <045.7cd1851542a40f5e7a193132a1812872@varnish-cache.org> References: <045.7cd1851542a40f5e7a193132a1812872@varnish-cache.org> Message-ID: <060.63f59065ea1ac7973eb223a82ab435f1@varnish-cache.org> #1862: Request URL with whitespace is allowed ----------------------+-------------------- Reporter: espebra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Dridi): In Espen's test case, the client URL is {{{"/foo bar"}}} and {{{"bar"}}} leaks in {{{req.proto}}}, so we have a workaround: {{{ sub vcl_recv { if (req.proto !~ "^HTTP/1.[01]$") { return (synth(400, "Bad Request")); } } }}} I'm personally leaning toward a 400 error because it's simple and it doesn't acknowledge non-compliant clients (which I believe in most cases would be malicious). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 10:11:37 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 10:11:37 -0000 Subject: [Varnish] #1862: Request URL with whitespace is allowed In-Reply-To: <045.7cd1851542a40f5e7a193132a1812872@varnish-cache.org> References: <045.7cd1851542a40f5e7a193132a1812872@varnish-cache.org> Message-ID: <060.54331e8d322a7590e9268f63447cbe02@varnish-cache.org> #1862: Request URL with whitespace is allowed ----------------------+-------------------- Reporter: espebra | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by fgsch): FWIW, this doesn't affect >= 4.1.0 or master. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 10:14:31 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 10:14:31 -0000 Subject: [Varnish] #1856: LostHeader setting req.url to an empty string In-Reply-To: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> References: <048.e7a4838e42e5afbe2ab380f13d5972a7@varnish-cache.org> Message-ID: <063.de80961c59bd747b36dd03ddaec88390@varnish-cache.org> #1856: LostHeader setting req.url to an empty string ------------------------+----------------------- Reporter: gdelacroix | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Comment (by fgsch): Please note that for the ws exhaustion this is not limited to req, proto and method. Any variable using vrt_do_string() will suffer from this issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 12:32:26 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 12:32:26 -0000 Subject: [Varnish] #1815: Child died on pipe request In-Reply-To: <045.fd9ff74855f45ed16026a18196ea076c@varnish-cache.org> References: <045.fd9ff74855f45ed16026a18196ea076c@varnish-cache.org> Message-ID: <060.c767daf3c1bf0d3ba4c2757e9329c303@varnish-cache.org> #1815: Child died on pipe request -------------------------+----------------------- Reporter: jferjan | Owner: Dridi Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: major | Resolution: Keywords: pipe, panic | -------------------------+----------------------- Comment (by Dridi): Discussed during today's bugwash, Varnish should serve a 503 Service Unavailable if no backend is available. I will try to do that. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 17:26:46 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 17:26:46 -0000 Subject: [Varnish] #1862: Request URL with whitespace is allowed In-Reply-To: <045.7cd1851542a40f5e7a193132a1812872@varnish-cache.org> References: <045.7cd1851542a40f5e7a193132a1812872@varnish-cache.org> Message-ID: <060.a79e581644db776e82a8570b6f8c0854@varnish-cache.org> #1862: Request URL with whitespace is allowed ----------------------+-------------------- Reporter: espebra | Owner: Dridi Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by Dridi): * owner: => Dridi Comment: Assigning to myself. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 20:50:54 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 20:50:54 -0000 Subject: [Varnish] #1863: Assert error in child_sigsegv_handler() Message-ID: <043.25edbd1166f396845e72d7946fde9079@varnish-cache.org> #1863: Assert error in child_sigsegv_handler() -------------------+---------------------- Reporter: batty | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.1.1 | Severity: major Keywords: | -------------------+---------------------- Upgraded from Varnish 3.0.6 to 4.1.1 late last week on a tier of three servers. We use BANs quite a bit. On one of the servers in the tier, we've received this assert twice. {{{ Last panic at: Mon, 29 Feb 2016 15:12:04 GMT "Assert error in child_sigsegv_handler(), mgt/mgt_child.c line 282: Condition(Segmentation fault by instruction at 0x28) not true. thread = (ban-lurker) version = varnish-4.1.1 revision 66bb824 ident = Linux,2.6.32-358.23.2.el6.x86_64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4328b3: varnishd() [0x4328b3] 0x451f09: varnishd() [0x451f09] 0x7f7aa70277e0: libpthread.so.0(+0xf7e0) [0x7f7aa70277e0] 0x417dc5: varnishd(ban_lurker+0x6b5) [0x417dc5] 0x448527: varnishd() [0x448527] 0x7f7aa701faa1: libpthread.so.0(+0x7aa1) [0x7f7aa701faa1] 0x7f7aa6d6893d: libc.so.6(clone+0x6d) [0x7f7aa6d6893d] " }}} I'm working with our operations team to try to enable core dumps and get a back trace. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 20:51:05 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 20:51:05 -0000 Subject: [Varnish] #1864: Assert error in BAN_CheckObject() Message-ID: <043.16ef0498d962136d0f77108fdaee3dd2@varnish-cache.org> #1864: Assert error in BAN_CheckObject() -------------------+---------------------- Reporter: batty | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.1.1 | Severity: major Keywords: | -------------------+---------------------- Upgraded from Varnish 3.0.6 to 4.1.1 late last week on a tier of three servers. We use BANs quite a bit. On one of the servers in the tier, we've received this assert twice. {{{ Last panic at: Thu, 25 Feb 2016 04:06:41 GMT "Assert error in BAN_CheckObject(), cache/cache_ban.c line 539: Condition((b) != NULL) not true. thread = (cache-worker) version = varnish-4.1.1 revision 66bb824 ident = Linux,2.6.32-358.23.2.el6.x86_64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4328b3: varnishd() [0x4328b3] 0x4163d0: varnishd(BAN_CheckObject+0x320) [0x4163d0] 0x4287b8: varnishd(HSH_Lookup+0x2f8) [0x4287b8] 0x436291: varnishd() [0x436291] 0x436c31: varnishd(CNT_Request+0x3b1) [0x436c31] 0x44dc5b: varnishd(HTTP1_Session+0x11b) [0x44dc5b] 0x439dbd: varnishd(SES_Proto_Req+0x5d) [0x439dbd] 0x448a1d: varnishd() [0x448a1d] 0x448e4b: varnishd() [0x448e4b] 0x7fcb3ed97aa1: libpthread.so.0(+0x7aa1) [0x7fcb3ed97aa1] req = 0x7fcaee106020 { vxid = 5064422, step = R_STP_LOOKUP, req_body = R_BODY_NONE, restarts = 0, esi_level = 0, sp = 0x7fcae0e55020 { fd = 22, vxid = 5064354, client = xxxxx 48795, step = S_STP_H1PROC, }, worker = 0x7fcb272f6bc0 { stack = {0x7fcb272f7000 -> 0x7fcb272eb000}, ws = 0x7fcb272f6db8 { id = \"wrk\", {s,f,r,e} = {0x7fcb272f6380,0x7fcb272f6380,(nil),+2040}, }, VCL::method = HASH, VCL::return = lookup, VCL::methods = {RECV, PASS, HASH, MISS, HIT, DELIVER}, }, ws = 0x7fcaee106200 { id = \"req\", {s,f,r,e} = {0x7fcaee108000,+1984,+1040376,+1040376}, }, http_conn = 0x7fcaee106128 { fd = 22, doclose = NULL, ws = 0x7fcaee106200, {rxbuf_b, rxbuf_e} = {0x7fcaee108000, 0x7fcaee10876f}, {pipeline_b, pipeline_e} = {(nil), (nil)}, content_length = -1, body_status = none, first_byte_timeout = 0.000000, between_bytes_timeout = 0.000000, }, http[req] = 0x7fcaee106298 { ws[req] = 0x7fcaee106200, hdrs { \"GET\", \"/xxxxx/xxxxx", \"HTTP/1.1\", \"User-Agent: xxxx", \"Accept: */*\", \"X-Forwarded-For: xxxxx, xxxxx\", \"host: varnish.xxxxx.com\", }, }, vcl = { temp = warm srcname = { \"/etc/varnish/default.vcl\", \"Builtin\", }, }, flags = { }, }, }}} I'm working with our operations team to try to enable core dumps and get a back trace. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 20:54:28 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 20:54:28 -0000 Subject: [Varnish] #1863: Assert error in child_sigsegv_handler() In-Reply-To: <043.25edbd1166f396845e72d7946fde9079@varnish-cache.org> References: <043.25edbd1166f396845e72d7946fde9079@varnish-cache.org> Message-ID: <058.31965edeceaaf0d3666b331c99645f18@varnish-cache.org> #1863: Assert error in child_sigsegv_handler() ----------------------+-------------------- Reporter: batty | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.1 Severity: major | Resolution: Keywords: | ----------------------+-------------------- Comment (by batty): FYI, this server is in the same tier as the server in [ticket:1864 ticket 1864]. It just received a different ban assert. The errors may (or may not) be related. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 29 20:54:44 2016 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Feb 2016 20:54:44 -0000 Subject: [Varnish] #1864: Assert error in BAN_CheckObject() In-Reply-To: <043.16ef0498d962136d0f77108fdaee3dd2@varnish-cache.org> References: <043.16ef0498d962136d0f77108fdaee3dd2@varnish-cache.org> Message-ID: <058.cad953985dfd4045828d701737068675@varnish-cache.org> #1864: Assert error in BAN_CheckObject() ----------------------+-------------------- Reporter: batty | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.1 Severity: major | Resolution: Keywords: | ----------------------+-------------------- Comment (by batty): FYI, this server is in the same tier as the server in [ticket:1863 ticket 1863]. It just received a different ban assert. The errors may (or may not) be related. -- Ticket URL: Varnish The Varnish HTTP Accelerator