From phk at phk.freebsd.dk Tue Sep 28 10:46:33 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 28 Sep 2010 10:46:33 +0000 Subject: [Varnish] #785: vcl.load and vcl.discard In-Reply-To: Your message of "Tue, 28 Sep 2010 10:37:47 GMT." <057.c3f24c3d352be34b213a55ae12881f75@varnish-cache.org> Message-ID: <58823.1285670793@critter.freebsd.dk> In message <057.c3f24c3d352be34b213a55ae12881f75 at varnish-cache.org>, "Varnish" writes: > What does the other code on that line mean? > > i.e 63 - ? That is the number of bytes in the reply. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From varnish-bugs at varnish-cache.org Wed Sep 1 16:55:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 01 Sep 2010 16:55:25 -0000 Subject: [Varnish] #767: HTTP/1.1 and connection-close from back-end -> empty result from varnish Message-ID: <043.d98808dea0f2d7386597a9dbd9e2bf50@varnish-cache.org> #767: HTTP/1.1 and connection-close from back-end -> empty result from varnish ----------------------+----------------------------------------------------- Reporter: ysimon | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Keywords: connection-close, varnishd ----------------------+----------------------------------------------------- When i try to reverse proxy this url http://www- ha.rueducommerce.fr/jqscript/jqueryZjquery/jqueryZjquery.selectbox/jqueryZjquery.coukie/jqueryZbgframe/jqueryZslideshow/jscript.js the content sent back by varnish is empty the http headers are '''HTTP/1.1''' 200 OK Server: Microsoft-IIS/5.0 Date: Wed, 01 Sep 2010 16:48:52 GMT Edge-control: max-age=600 Cache-control: max-age=600 '''Connection: close''' even with 2.1.3 version of varnish, '''the result from varnish is an empty file''' with a "0" content-length it seems to be different from other previous tickets ... the script engine behind this URL is "coldfusion 5" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 2 08:07:45 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 02 Sep 2010 08:07:45 -0000 Subject: [Varnish] #766: Varnish Redirect Issue when User-Agent contains the string "connec" In-Reply-To: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> References: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> Message-ID: <056.41bd3405ac4ed427dc4209f4070261e4@varnish-cache.org> #766: Varnish Redirect Issue when User-Agent contains the string "connec" ---------------------------------+------------------------------------------ Reporter: stefansinn | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 2.0 | Severity: major Keywords: Redirect User-Agent | ---------------------------------+------------------------------------------ Comment(by nav): Your configuration appears to be always redirecting from http://wetter.info to http://www.wetter.info, no matter what is in user- agent. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 2 11:18:18 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 02 Sep 2010 11:18:18 -0000 Subject: [Varnish] #767: HTTP/1.1 and connection-close from back-end -> empty result from varnish In-Reply-To: <043.d98808dea0f2d7386597a9dbd9e2bf50@varnish-cache.org> References: <043.d98808dea0f2d7386597a9dbd9e2bf50@varnish-cache.org> Message-ID: <052.370766060064013a88f0afcb19997219@varnish-cache.org> #767: HTTP/1.1 and connection-close from back-end -> empty result from varnish ----------------------+----------------------------------------------------- Reporter: ysimon | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Keywords: connection-close, varnishd ----------------------+----------------------------------------------------- Comment(by ysimon): Changing cache_fetch.c like this else if (http_HdrIs(hp, H_Connection, "close")) { sp->wrk->stats.fetch_close++; /* * If we have connection closed, it is safe to read what * comes in any case. */ cls = fetch_eof(sp, sp->wrk->htc); mklen = 1; } by else if (http_HdrIs(hp, H_Connection, "close")) { sp->wrk->stats.fetch_close++; /* * If we have connection closed, it is safe to read what * comes in any case. */ cls = fetch_eof(sp, sp->wrk->htc); } seems to be a good solution because of that if (mklen > 0) http_PrintfHeader(sp->wrk, sp->fd, sp->obj->http, "Content-Length: %u", sp->obj->len); -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 2 11:57:46 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 02 Sep 2010 11:57:46 -0000 Subject: [Varnish] #766: Varnish Redirect Issue when User-Agent contains the string "connec" In-Reply-To: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> References: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> Message-ID: <056.54ab5b1ec9a32aa1c6b91592daa31ab9@varnish-cache.org> #766: Varnish Redirect Issue when User-Agent contains the string "connec" ---------------------------------+------------------------------------------ Reporter: stefansinn | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 2.0 | Severity: major Keywords: Redirect User-Agent | ---------------------------------+------------------------------------------ Comment(by stefansinn): I apologize for not having been specific. [[BR]] if the '''User-Agent''' contains the string "OfficeLive__'''Connec'''__tor.1.3;" for example, Varnish automatically redirects the Browser in '''error''' to http://mobil.wetter.info instead of to http://www.wetter.info [[BR]] I am trying to find out why Varnish gets hung up on the string "connec" in the User-Agent. Desktop Users with "Office Live" installed for example, get Redirected to a Site meant for Mobile Devices [[BR]] instead of being passed thru to the Site meant for PC's (Desktops). [[BR]] btw. thank you very much for the quick response, nav -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 2 12:38:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 02 Sep 2010 12:38:25 -0000 Subject: [Varnish] #766: Varnish Redirect Issue when User-Agent contains the string "connec" In-Reply-To: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> References: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> Message-ID: <056.d15e9255b05cd12faab7c0bb19cea464@varnish-cache.org> #766: Varnish Redirect Issue when User-Agent contains the string "connec" ---------------------------------+------------------------------------------ Reporter: stefansinn | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 2.0 | Severity: major Keywords: Redirect User-Agent | ---------------------------------+------------------------------------------ Comment(by nav): Still, not varnishd fault. You have configuration that does that, so you should check for this behaviour in there. And I think bugs is not place to discuss that, you probably should've posted on proper mailing list. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 2 13:35:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 02 Sep 2010 13:35:04 -0000 Subject: [Varnish] #766: Varnish Redirect Issue when User-Agent contains the string "connec" In-Reply-To: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> References: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> Message-ID: <056.7680945e56f132fae3a27787a0d00ac3@varnish-cache.org> #766: Varnish Redirect Issue when User-Agent contains the string "connec" ---------------------------------+------------------------------------------ Reporter: stefansinn | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 2.0 | Severity: major Keywords: Redirect User-Agent | ---------------------------------+------------------------------------------ Comment(by stefansinn): I see that there might be a slight misunderstanding. The domain which uses Varnish for redirection of mobile user agents is not http://wetter.info but rather http://www.wetter.info. So there is no relation to the HTTP/301 which is intentionally taking place from wetter.info to www.wetter.info. :-) Actually, the config we use at www.wetter.info looks like this: -- tchik -- ## 1st part in sub vcl_recv if (req.http.user-agent ~ "^SIE-") { if (req.http.host ~ "www.wetter.info") { error 750 "mobil.wetter.info"; } } ## 2nd part in sub vcl_error if (obj.status == 750) { set obj.http.Location = "http://mobil.wetter.info/"; set obj.status = 301; set obj.http.cache-control = "no-cache, must-revalidate"; deliver; } -- tchak -- There is no place in this configuration anywhere that mentions the string "connec" or anything similar which could trigger the redirect. That's the reason we thought it might have been a bug. :-\ It would be great if we were wrong, and if we are, of course will we move to the proper mailing list. Thanks for your reply & regards.. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 2 14:15:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 02 Sep 2010 14:15:04 -0000 Subject: [Varnish] #766: Varnish Redirect Issue when User-Agent contains the string "connec" In-Reply-To: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> References: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org> Message-ID: <056.38763cabdbba84745b961735493755bf@varnish-cache.org> #766: Varnish Redirect Issue when User-Agent contains the string "connec" ---------------------------------+------------------------------------------ Reporter: stefansinn | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 2.0 | Severity: major Keywords: Redirect User-Agent | ---------------------------------+------------------------------------------ Comment(by s.christiansen): The configuration really seems to be fine - the redirecting of mobile user agents works just great otherwise. It still is the only problem that a redirect is taking place from www.wetter.info to mobil.wetter.info once the user agent request header contains anything that smells of "connec". :-( We already checked all of our matching patterns for the user agents - the string "connec" cannot be found in the whole Varnish configuration whatsoever. We suspect that there might be a connection with the "Connection: close" response headers that are being used in this system; I have seen 'mixed up' HTTP headers here at some point already. So the assumption at this point is that there are User Agent request headers which, by error, actually contain the string "Connection: close" (or part of it). This then would end up somehow confusing the matching.. the picture is not very clear yet. We'll check on that. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 2 15:43:17 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 02 Sep 2010 15:43:17 -0000 Subject: [Varnish] #767: HTTP/1.1 and connection-close from back-end -> empty result from varnish In-Reply-To: <043.d98808dea0f2d7386597a9dbd9e2bf50@varnish-cache.org> References: <043.d98808dea0f2d7386597a9dbd9e2bf50@varnish-cache.org> Message-ID: <052.9680a4d5dfbd0f5d6f87d989cf50421b@varnish-cache.org> #767: HTTP/1.1 and connection-close from back-end -> empty result from varnish ----------------------+----------------------------------------------------- Reporter: ysimon | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Keywords: connection-close, varnishd ----------------------+----------------------------------------------------- Comment(by ysimon): sorry the good url to try is http://s1.static69.com/jqscript/jqueryZjquery/jqueryZjquery.selectbox/jqueryZjquery.coukie/jqueryZbgframe/jqueryZslideshow/jscript.js with static-org.ha.rueducommerce.fr as a back end server -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 2 17:13:55 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 02 Sep 2010 17:13:55 -0000 Subject: [Varnish] #767: HTTP/1.1 and connection-close from back-end -> empty result from varnish In-Reply-To: <043.d98808dea0f2d7386597a9dbd9e2bf50@varnish-cache.org> References: <043.d98808dea0f2d7386597a9dbd9e2bf50@varnish-cache.org> Message-ID: <052.68ba0e00d401ca202e1cfa699aa95cda@varnish-cache.org> #767: HTTP/1.1 and connection-close from back-end -> empty result from varnish ----------------------+----------------------------------------------------- Reporter: ysimon | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Keywords: connection-close, varnishd ----------------------+----------------------------------------------------- Comment(by ysimon): Finally, we found another solution with our load balancers ... may be, varnishd doesn't need this correction... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 3 03:43:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 03 Sep 2010 03:43:16 -0000 Subject: [Varnish] #768: varnishstat sms_balloc/sms_nbytes race condition Message-ID: <045.ff365b39a47f2027f48d9972a383214a@varnish-cache.org> #768: varnishstat sms_balloc/sms_nbytes race condition ----------------------+----------------------------------------------------- Reporter: askalski | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: trivial Keywords: | ----------------------+----------------------------------------------------- There's a race condition in sms_nbytes and sms_balloc in varnishstat: {{{ sms_nbytes 18446744073709515650 . SMS outstanding bytes sms_balloc 189713772 . SMS bytes allocated sms_bfree 189748637 . SMS bytes freed }}} bin/varnishd/storage_synth.c:SMS_Finish() is missing its mutex operations: {{{ --- a/storage_synth.c 2010-09-02 23:40:46.405915699 -0400 +++ b/storage_synth.c 2010-09-02 23:41:21.365964969 -0400 @@ -120,6 +120,8 @@ sto->len = vsb_len(vsb); sto->space = vsb_len(vsb); obj->len = sto->len; + Lck_Lock(&sms_mtx); VSC_main->sms_nbytes += sto->len; VSC_main->sms_balloc += sto->len; + Lck_Unlock(&sms_mtx); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Sep 4 08:55:47 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 04 Sep 2010 08:55:47 -0000 Subject: [Varnish] #769: Vcl_error not respecting set obj.status in vcl_error Message-ID: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> #769: Vcl_error not respecting set obj.status in vcl_error ------------------------+--------------------------------------------------- Reporter: stewsnooze | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Keywords: | ------------------------+--------------------------------------------------- I've noticed that in a setup that does something along the lines of: ?sub vcl_recv { ??... ??if (something) { ????error 798; ??} ?} ?sub vcl_error { ???if (obj.status == 798) { ?????set obj.status = 404; ?????synthetic {"Oh no, a "} obj.status {" occurred!"}; ???} ?} The actual HTTP response code will be correct (404), but the text returned in the response will say the status was 798. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Sep 4 08:55:50 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 04 Sep 2010 08:55:50 -0000 Subject: [Varnish] #770: Vcl_error not respecting set obj.status in vcl_error Message-ID: <047.2b07f757ca2e4426bf900e0b16d03b08@varnish-cache.org> #770: Vcl_error not respecting set obj.status in vcl_error ------------------------+--------------------------------------------------- Reporter: stewsnooze | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Keywords: | ------------------------+--------------------------------------------------- I've noticed that in a setup that does something along the lines of: ?sub vcl_recv { ??... ??if (something) { ????error 798; ??} ?} ?sub vcl_error { ???if (obj.status == 798) { ?????set obj.status = 404; ?????synthetic {"Oh no, a "} obj.status {" occurred!"}; ???} ?} The actual HTTP response code will be correct (404), but the text returned in the response will say the status was 798. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Sep 4 09:15:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 04 Sep 2010 09:15:27 -0000 Subject: [Varnish] #769: Vcl_error not respecting set obj.status in vcl_error In-Reply-To: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> References: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> Message-ID: <056.f37a7666c6e771080688508da101c7c1@varnish-cache.org> #769: Vcl_error not respecting set obj.status in vcl_error ------------------------+--------------------------------------------------- Reporter: stewsnooze | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Keywords: | ------------------------+--------------------------------------------------- Comment(by stewsnooze): This is a duplicate. Close. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Sep 4 15:47:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 04 Sep 2010 15:47:16 -0000 Subject: [Varnish] #771: caching large objects Message-ID: <044.72d043cecc110889e5fa91f9bd2e6400@varnish-cache.org> #771: caching large objects ----------------------+----------------------------------------------------- Reporter: bcakipp | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Hi, Working with Varnish 2.1.3 on CentOS5. I've noticed child threads dying with an assertion error when trying to fetch large objets. From what I can tell, objects with a Content-Length larger then 4GB will cause the child thread to die. For example (file is ~ 6GB). {{{ $ curl http://glint1/aries/75123740001/75123740001_601962598001_ALO- IPA-083010.mov -o /dev/null -v -s * About to connect() to glint1 port 80 * Trying 192.168.104.211... connected * Connected to glint1 (192.168.104.211) port 80 > GET /aries/75123740001/75123740001_601962598001_ALO-IPA-083010.mov HTTP/1.1 > User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: glint1 > Accept: */* > * Empty reply from server * Connection #0 to host glint1 left intact * Closing connection #0 }}} Syslog shows: {{{ Sep 2 20:31:09 glint1 varnishd[21426]: Child (22486) died signal=6 Sep 2 20:31:09 glint1 varnishd[21426]: Child (22486) Panic message: Assert error in fetch_straight(), cache_fetch.c line 64: Condition((uintmax_t)cl == cll) not true. thread = (cache-worker) ident = Linux,2.6.18-164.15.1.el5xen,x86_64,-sfile,-hcritbit,epoll Backtrace: 0x422726: /usr/sbin/varnishd [0x422726] 0x41a8f8: /usr/sbin/varnishd(FetchBody+0x4a8) [0x41a8f8] 0x412960: /usr/sbin/varnishd [0x412960] 0x413ed5: /usr/sbin/varnishd(CNT_Session+0x345) [0x413ed5] 0x424b78: /usr/sbin/varnishd [0x424b78] 0x423e5d: /usr/sbin/varnishd [0x423e5d] 0x3c9de06617: /lib64/libpthread.so.0 [0x3c9de06617] 0x3c9d6d3c2d: /lib64/libc.so.6(clone+0x6d) [0x3c9d6d3c2d] sp = 0x2abe71908008 { fd = 11, id = 11, xid = 674181670, client = 192.168.103.71:48903, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2abe71908078 { id = "sess", {s,f,r,e} = {0x2abe71908cd0,+240,(nil),+65536}, }, http[req] = { ws = 0x2abe71908078[sess] " }}} Looking at that line in cache_fetch.c: {{{ uintmax_t cll; unsigned cl, sl; struct storage *st; cll = strtoumax(b, NULL, 0); if (cll == 0) return (0); cl = (unsigned)cll; assert((uintmax_t)cl == cll); /* Protect against bogusly large values */ }}} My reading of that says that anything larger then an unsigned int (~4GB) will cause the client thread to die. I understand that it would be possible to just pipe these large files, but what I would really like to do is cache them in varnish. Is this possible? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 7 07:12:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 07 Sep 2010 07:12:27 -0000 Subject: [Varnish] #772: cli_buffer parameter doesn't work. Message-ID: <044.12c898455bb056ae4f68271e3a5999e5@varnish-cache.org> #772: cli_buffer parameter doesn't work. ----------------------+----------------------------------------------------- Reporter: Estartu | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: cli_buffer ----------------------+----------------------------------------------------- I'm setting my configs via vcl.inline. Works find as long as the config and the command shorter than 8192 bytes. so i tried to increase cli_buffer with param.set cli_buffer 81920 still the input stops at 8192 characters. The help to cli_buffer states that cli_buffer has to be set via -p. No change there to. I even changed the default value in mgt_param.c The changed value is shown via param.show but the input still stops after 8192 characters. I'm running varnish-2.1.3 SVN 5049:5055 installed via the FreeBSD Port. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 7 12:04:07 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 07 Sep 2010 12:04:07 -0000 Subject: [Varnish] #773: Setting TOS byte via VCL directive Message-ID: <045.d5aa10ae71877115178687487fff71c3@varnish-cache.org> #773: Setting TOS byte via VCL directive -------------------------+-------------------------------------------------- Reporter: tmagnien | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: 2.1.3 Severity: minor | Keywords: -------------------------+-------------------------------------------------- Hi, I've written a patch to allow for TOS byte manipulation through VCL directive. Typical use is : sub vcl_recv { if ( req.url ~ "^/test.html$" ) { set_tos 32; } } This sets the TOS byte on the socket between varnishd and the client. Any comments welcome. Note that the patch has been tested against 2.1.3 release (the version I use). Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 7 12:46:23 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 07 Sep 2010 12:46:23 -0000 Subject: [Varnish] #731: Can't remove illegal header without terminal colon In-Reply-To: <042.2bedc9032a3afd45a69e919dde5311df@varnish-cache.org> References: <042.2bedc9032a3afd45a69e919dde5311df@varnish-cache.org> Message-ID: <051.de9f4d99caa0dcd5b23a2f6173d9f053@varnish-cache.org> #731: Can't remove illegal header without terminal colon -----------------------+---------------------------------------------------- Reporter: slink | Type: defect Status: reopened | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by slink): * status: closed => reopened * resolution: worksforme => Comment: Phk, I fully understand your reasons. But I don't understand why you fear Varnish would be butchered if one assertion in VRT_SetHdr was removed. I was not asking at all to parse broken request lines in varnish, RFC2616 is very clear about this: {{{ Request-Line = Method SP Request-URI SP HTTP-Version CRLF }}} I am not at all questioning this, nor the current Varnish Request Line parsing. All I am asking for is the necessary tool to work around this broken client in a VCL by removing one assertion. Thanks, Nils -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 7 13:12:14 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 07 Sep 2010 13:12:14 -0000 Subject: [Varnish] #760: varnishlog unbuffered output In-Reply-To: <045.bbcca487396d337b069b2c55e4ee6665@varnish-cache.org> References: <045.bbcca487396d337b069b2c55e4ee6665@varnish-cache.org> Message-ID: <054.40400d37421bce9afaaa06f0383de784@varnish-cache.org> #760: varnishlog unbuffered output -------------------------------+-------------------------------------------- Reporter: blade106 | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: varnishlog output | -------------------------------+-------------------------------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: (In [5176]) Apply optional unbuffered output on stdout before call to do_order. Fixes: #760 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 7 14:25:15 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 07 Sep 2010 14:25:15 -0000 Subject: [Varnish] #774: Panic message: Assert error in STV_alloc() Message-ID: <046.ecc2f4bc4f7ae0ce88547b074a00b027@varnish-cache.org> #774: Panic message: Assert error in STV_alloc() -----------------------+---------------------------------------------------- Reporter: wittwerch | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.0 | Severity: normal Keywords: | -----------------------+---------------------------------------------------- We encountered a crash on our varnish server. Sep 7 14:01:50 myserver varnishd[26296]: Child (26297) Panic message: Assert error in STV_alloc(), stevedore.c line 71: Condition((st) != NULL) not true. thread = (cache-worker) Backtrace: 0x41ba68: /usr/sbin/varnishd [0x41ba68] 0x43121d: /usr/sbin/varnishd(STV_alloc+0x9d) [0x43121d] 0x4154e2: /usr/sbin/varnishd(Fetch+0x6b2) [0x4154e2] 0x410154: /usr/sbin/varnishd [0x410154] 0x411379: /usr/sbin/varnishd(CNT_Session+0x389) [0x411379] 0x41d9e2: /usr/sbin/varnishd [0x41d9e2] 0x41cf4f: /usr/sbin/varnishd [0x41cf4f] 0x372f806617: /lib64/libpthread.so.0 [0x372f806617] 0x372f0d3c2d: /lib64/libc.so.6(clone+0x6d) [0x372f0d3c2d] sp = 0x2aaaedfa2008 { fd = 37, id = 37, xid = 1793847417, client = 84.253.6.190:44291, step = STP_FETCH, handling = discard, restarts = 0, esis = 0 ws = 0x2aaaedfa2080 { id = "sess", {s,f,r,e} = {0x2aaaedfa2820,+391,(nil),+16384}, }, http[req] = { ws = 0x2aaaedfa2080[sess] "GET", "/mammut-extern/TokoPST/DSC.zip", "HTTP/1.1", There was no port open on tcp/80 anymore, so the automatically restart did not work. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 9 05:00:18 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 09 Sep 2010 05:00:18 -0000 Subject: [Varnish] #775: wrong documentation Message-ID: <044.ccbdfeb9e6745156653465eabc2cc801@varnish-cache.org> #775: wrong documentation -------------------------------+-------------------------------------------- Reporter: behrang | Type: documentation Status: new | Priority: low Milestone: After Varnish 2.1 | Component: documentation Version: trunk | Severity: minor Keywords: | -------------------------------+-------------------------------------------- in http://www.varnish- cache.org/docs/trunk/tutorial/increasing_your_hitrate.html in cookie section, if ( !( req.url ~ ^/admin/) ) { unset http.Cookie; } should be changed to if ( !( req.url ~ ^/admin/) ) { unset req.ttp.Cookie; } -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 10 12:28:13 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 10 Sep 2010 12:28:13 -0000 Subject: [Varnish] #775: wrong documentation In-Reply-To: <044.ccbdfeb9e6745156653465eabc2cc801@varnish-cache.org> References: <044.ccbdfeb9e6745156653465eabc2cc801@varnish-cache.org> Message-ID: <053.ce4d224d92557edf8d4e6ddf41c277ec@varnish-cache.org> #775: wrong documentation --------------------------------+------------------------------------------- Reporter: behrang | Type: documentation Status: closed | Priority: low Milestone: After Varnish 2.1 | Component: documentation Version: trunk | Severity: minor Resolution: fixed | Keywords: --------------------------------+------------------------------------------- Changes (by perbu): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 10 12:28:38 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 10 Sep 2010 12:28:38 -0000 Subject: [Varnish] #775: wrong documentation In-Reply-To: <044.ccbdfeb9e6745156653465eabc2cc801@varnish-cache.org> References: <044.ccbdfeb9e6745156653465eabc2cc801@varnish-cache.org> Message-ID: <053.220eb4cc2f6dc33e9bd951ca94d64140@varnish-cache.org> #775: wrong documentation --------------------------------+------------------------------------------- Reporter: behrang | Type: documentation Status: closed | Priority: low Milestone: After Varnish 2.1 | Component: documentation Version: trunk | Severity: minor Resolution: fixed | Keywords: --------------------------------+------------------------------------------- Comment(by perbu): (In [5190]) close #775 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 10 12:45:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 10 Sep 2010 12:45:26 -0000 Subject: [Varnish] #708: XML display is not documented In-Reply-To: <043.ef00f4612fb85c87d480634e4de05a49@varnish-cache.org> References: <043.ef00f4612fb85c87d480634e4de05a49@varnish-cache.org> Message-ID: <052.4f51b8101a29f4b68354eecf922c2b90@varnish-cache.org> #708: XML display is not documented ---------------------------+------------------------------------------------ Reporter: jerome | Owner: perbu Type: documentation | Status: closed Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: minor | Resolution: fixed Keywords: varnishstat | ---------------------------+------------------------------------------------ Changes (by perbu): * status: new => closed * resolution: => fixed Comment: (In [5191]) closes #708 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 10 13:20:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 10 Sep 2010 13:20:25 -0000 Subject: [Varnish] #759: Varnish child crashes, restarts often In-Reply-To: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org> References: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org> Message-ID: <056.36379a450c8c712a807f3478fb4aefc5@varnish-cache.org> #759: Varnish child crashes, restarts often -------------------------------------+-------------------------------------- Reporter: allan.jude | Owner: martin Type: defect | Status: closed Priority: high | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: crash segfault signal11 | -------------------------------------+-------------------------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: Hi, Your error seems to come from Varnish being unable to allocate any memory for the object, as all memory being available to Varnish is busy at the time (tied up to served objects). This can happen when Varnish is running with a very small amount of available storage. I notice that you are running with two storage backends, where one of them is only 32M large, and the other a more reasonable 1G size. 32M is a too restricted memory pool for Varnish to run. Your problem likely happens during busy times when trying to store to the small storage. It is perhaps there by error? I suggest to remove the small storage backend and run only with the large one, or increase the small storage significantly. -Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 13 07:30:03 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Sep 2010 07:30:03 -0000 Subject: [Varnish] #770: Vcl_error not respecting set obj.status in vcl_error In-Reply-To: <047.2b07f757ca2e4426bf900e0b16d03b08@varnish-cache.org> References: <047.2b07f757ca2e4426bf900e0b16d03b08@varnish-cache.org> Message-ID: <056.b4308451abed53d9cef94e6bf69624b4@varnish-cache.org> #770: Vcl_error not respecting set obj.status in vcl_error -------------------------+-------------------------------------------------- Reporter: stewsnooze | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Resolution: duplicate | Keywords: -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => duplicate Comment: Dupe of 769, closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 13 08:14:21 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Sep 2010 08:14:21 -0000 Subject: [Varnish] #769: Vcl_error not respecting set obj.status in vcl_error In-Reply-To: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> References: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> Message-ID: <056.e44721a5cd7c64428cd3e72ca6c0cc10@varnish-cache.org> #769: Vcl_error not respecting set obj.status in vcl_error ------------------------+--------------------------------------------------- Reporter: stewsnooze | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Keywords: | ------------------------+--------------------------------------------------- Comment(by stewsnooze): Replying to [comment:1 stewsnooze]: > This is a duplicate. Close. So somebody has closed the duplicate instead of this one. So this is no longer a dupe. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 13 11:13:43 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Sep 2010 11:13:43 -0000 Subject: [Varnish] #774: Panic message: Assert error in STV_alloc() In-Reply-To: <046.ecc2f4bc4f7ae0ce88547b074a00b027@varnish-cache.org> References: <046.ecc2f4bc4f7ae0ce88547b074a00b027@varnish-cache.org> Message-ID: <055.a58f8fce7dd106bb508ea056c1a36ca1@varnish-cache.org> #774: Panic message: Assert error in STV_alloc() -----------------------+---------------------------------------------------- Reporter: wittwerch | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Keywords: -----------------------+---------------------------------------------------- Changes (by kristian): * owner: => kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 13 11:13:44 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Sep 2010 11:13:44 -0000 Subject: [Varnish] #769: Vcl_error not respecting set obj.status in vcl_error In-Reply-To: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> References: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> Message-ID: <056.8b5724c550c5dc1de0544d8cf2d7f38a@varnish-cache.org> #769: Vcl_error not respecting set obj.status in vcl_error ------------------------+--------------------------------------------------- Reporter: stewsnooze | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 2.1.3 Severity: normal | Keywords: ------------------------+--------------------------------------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 13 11:22:59 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Sep 2010 11:22:59 -0000 Subject: [Varnish] #731: Can't remove illegal header without terminal colon In-Reply-To: <042.2bedc9032a3afd45a69e919dde5311df@varnish-cache.org> References: <042.2bedc9032a3afd45a69e919dde5311df@varnish-cache.org> Message-ID: <051.6b079b2e70f19735ef7e5eae173ebccc@varnish-cache.org> #731: Can't remove illegal header without terminal colon -----------------------+---------------------------------------------------- Reporter: slink | Type: defect Status: reopened | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: | Keywords: -----------------------+---------------------------------------------------- Comment(by slink): closed after discussion on IRC -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 13 11:24:24 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Sep 2010 11:24:24 -0000 Subject: [Varnish] #731: Can't remove illegal header without terminal colon In-Reply-To: <042.2bedc9032a3afd45a69e919dde5311df@varnish-cache.org> References: <042.2bedc9032a3afd45a69e919dde5311df@varnish-cache.org> Message-ID: <051.8913e8b5d51d9669b7924590245eefff@varnish-cache.org> #731: Can't remove illegal header without terminal colon ----------------------+----------------------------------------------------- Reporter: slink | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: wontfix | Keywords: ----------------------+----------------------------------------------------- Changes (by slink): * status: reopened => closed * resolution: => wontfix -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 13 11:53:43 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Sep 2010 11:53:43 -0000 Subject: [Varnish] #767: HTTP/1.1 and connection-close from back-end -> empty result from varnish In-Reply-To: <043.d98808dea0f2d7386597a9dbd9e2bf50@varnish-cache.org> References: <043.d98808dea0f2d7386597a9dbd9e2bf50@varnish-cache.org> Message-ID: <052.a5b7ca4985a73cdf6124ee6348423e91@varnish-cache.org> #767: HTTP/1.1 and connection-close from back-end -> empty result from varnish ----------------------------------------+----------------------------------- Reporter: ysimon | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: normal | Resolution: duplicate Keywords: connection-close, varnishd | ----------------------------------------+----------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate Comment: Already worked around this backend bug, please see #733 and r5075. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 13 13:11:08 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 13 Sep 2010 13:11:08 -0000 Subject: [Varnish] #774: Panic message: Assert error in STV_alloc() In-Reply-To: <046.ecc2f4bc4f7ae0ce88547b074a00b027@varnish-cache.org> References: <046.ecc2f4bc4f7ae0ce88547b074a00b027@varnish-cache.org> Message-ID: <055.b65de58c1a4deae08f0e1a33834710c5@varnish-cache.org> #774: Panic message: Assert error in STV_alloc() -----------------------+---------------------------------------------------- Reporter: wittwerch | Owner: kristian Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: -----------------------+---------------------------------------------------- Changes (by kristian): * priority: normal => low * component: build => varnishd Comment: This is a bit of an old version - can you test with Varnish 2.1.3? By the looks of it, you're running out of space in a bad way. I would guess that the .zip is potentially "large"? Varnish does about 50 attempts of lru before it fails hard (like you just noticed), and that may or may not have been what you experienced. So I suggest you try with Varnish 2.1.3 and add any startup parameters and output of varnishstat -1 if we're to look into this further. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 14 07:02:20 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 14 Sep 2010 07:02:20 -0000 Subject: [Varnish] #771: caching large objects In-Reply-To: <044.72d043cecc110889e5fa91f9bd2e6400@varnish-cache.org> References: <044.72d043cecc110889e5fa91f9bd2e6400@varnish-cache.org> Message-ID: <053.b15452951de6de13e7ca26be85e65807@varnish-cache.org> #771: caching large objects ----------------------+----------------------------------------------------- Reporter: bcakipp | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by phk): You'd think we got wiser with time wouldn't you ? Nooo, we're always so smart and say things like "Nobody is ever going to cache DVD images in Varnish, 4GB will be enough for everybody" and such. It will take some time to kill this particular retrooptimization, but I will keep my eye on it and try to eradicate it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 14 09:12:24 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 14 Sep 2010 09:12:24 -0000 Subject: [Varnish] #773: Setting TOS byte via VCL directive In-Reply-To: <045.d5aa10ae71877115178687487fff71c3@varnish-cache.org> References: <045.d5aa10ae71877115178687487fff71c3@varnish-cache.org> Message-ID: <054.686e69ed2b3e9203903301ea00c8394b@varnish-cache.org> #773: Setting TOS byte via VCL directive -------------------------+-------------------------------------------------- Reporter: tmagnien | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Later Component: varnishd | Version: 2.1.3 Severity: minor | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5206]) Add a procedure to std vmod to manipulate the IP TOS byte of the client connection: VOID set_ip_tos(INT) Fixes: #773 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 14 11:32:06 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 14 Sep 2010 11:32:06 -0000 Subject: [Varnish] #762: varnishstat segfault In-Reply-To: <044.faeba9b0cd4de3f6b34ab7116b045a3d@varnish-cache.org> References: <044.faeba9b0cd4de3f6b34ab7116b045a3d@varnish-cache.org> Message-ID: <053.3fb7deb879a1a7e2de9022a145d1d6f1@varnish-cache.org> #762: varnishstat segfault ---------------------+------------------------------------------------------ Reporter: victori | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------+------------------------------------------------------ Changes (by martin): * status: new => closed * resolution: => fixed Comment: (In [5208]) Initialize default varnish instance name in library if no n-argument has been given. Fixes: #762 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 15 07:22:19 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Sep 2010 07:22:19 -0000 Subject: [Varnish] #768: varnishstat sms_balloc/sms_nbytes race condition In-Reply-To: <045.ff365b39a47f2027f48d9972a383214a@varnish-cache.org> References: <045.ff365b39a47f2027f48d9972a383214a@varnish-cache.org> Message-ID: <054.f6d7716b22108550f2c43c52ac864f05@varnish-cache.org> #768: varnishstat sms_balloc/sms_nbytes race condition -----------------------+---------------------------------------------------- Reporter: askalski | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: trivial Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5210]) Lock the sms counters properly Fixes: #768 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 15 07:54:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Sep 2010 07:54:52 -0000 Subject: [Varnish] #769: Vcl_error not respecting set obj.status in vcl_error In-Reply-To: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> References: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> Message-ID: <056.34a026e107cadfa070475a34049a59de@varnish-cache.org> #769: Vcl_error not respecting set obj.status in vcl_error ------------------------+--------------------------------------------------- Reporter: stewsnooze | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: (In [5211]) Set the int status when setting the txt header status in VRT_l_[obj|resp|beresp]_status. Fixes: #769 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 15 17:40:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Sep 2010 17:40:52 -0000 Subject: [Varnish] #776: SMA_trim() failed??? Message-ID: <042.47b1e58cc7d70cd224146acc5d8054de@varnish-cache.org> #776: SMA_trim() failed??? ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- I get this all the time on one of my instanceses. What does it mean and what to do against it? {{{ Sep 15 17:29:12 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8085) died signal=6 Sep 15 17:29:12 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8085) Panic message: Assert error in sma_trim(), storage_malloc.c line 140: Condition(size < sma->sz) not true. thread = (cache-worker) ident = Linux,2.6.18-194.8.1.el5,x86_64,-smalloc,-hclassic,epoll Backtrace: 0x4234e8: pan_ic+b4 0x4399a6: sma_trim+15a 0x41c013: FetchBody+a9c 0x4128d9: cnt_fetch+692 0x413d8f: CNT_Session+329 0x425791: wrk_do_cnt_sess+b8 0x424ad1: wrk_thread_real+335 0x391580673d: _end+39151a3785 0x39150d3d1d: _end+3914a70d65 sp = 0x2aaaaf705008 { fd = 13, id = 13, xid = 2068267231, client = 192.168.2.12 5915, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaaf705080 { id = "sess", {s,f,r,e} = {0x2aaaaf705cd8,+768,(nil),+8192}, }, http[req] = { ws = 0x2aaaaf705080[sess] "GET", "/ext/scriptaculous/prototype.js+effects.js+versionfix.js+controls.js;/fo/default.js+search.js+track.js+babepage.js;/fms/qu Sep 15 17:29:12 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: child (8197) Started Sep 15 17:29:12 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8197) said Sep 15 17:29:12 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8197) said Child starts Sep 15 17:29:17 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8197) died signal=6 Sep 15 17:29:17 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8197) Panic message: Assert error in sma_trim(), storage_malloc.c line 140: Condition(size < sma->sz) not true. thread = (cache-worker) ident = Linux,2.6.18-194.8.1.el5,x86_64,-smalloc,-hclassic,epoll Backtrace: 0x4234e8: pan_ic+b4 0x4399a6: sma_trim+15a 0x41c013: FetchBody+a9c 0x4128d9: cnt_fetch+692 0x413d8f: CNT_Session+329 0x425791: wrk_do_cnt_sess+b8 0x424ad1: wrk_thread_real+335 0x391580673d: _end+39151a3785 0x39150d3d1d: _end+3914a70d65 sp = 0x2aaaaf103008 { fd = 10, id = 10, xid = 1696336878, client = 192.168.2.13 42404, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaaf103080 { id = "sess", {s,f,r,e} = {0x2aaaaf103cd8,+552,(nil),+8192}, }, http[req] = { ws = 0x2aaaaf103080[sess] "GET", "/ext/scriptaculous/prototype.js+effects.js+controls.js;/board/search.js", "HTTP/1.1", "User-Agent: Mozilla/5. Sep 15 17:29:17 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: child (8305) Started Sep 15 17:29:17 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8305) said Sep 15 17:29:17 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8305) said Child starts Sep 15 17:29:21 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8305) died signal=6 Sep 15 17:29:21 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8305) Panic message: Assert error in sma_trim(), storage_malloc.c line 140: Condition(size < sma->sz) not true. thread = (cache-worker) ident = Linux,2.6.18-194.8.1.el5,x86_64,-smalloc,-hclassic,epoll Backtrace: 0x4234e8: pan_ic+b4 0x4399a6: sma_trim+15a 0x41c013: FetchBody+a9c 0x4128d9: cnt_fetch+692 0x413d8f: CNT_Session+329 0x425791: wrk_do_cnt_sess+b8 0x424ad1: wrk_thread_real+335 0x391580673d: _end+39151a3785 0x39150d3d1d: _end+3914a70d65 sp = 0x2aaaabf2a008 { fd = 10, id = 10, xid = 199396413, client = 192.168.2.13 45133, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaabf2a080 { id = "sess", {s,f,r,e} = {0x2aaaabf2acd8,+680,(nil),+8192}, }, http[req] = { ws = 0x2aaaabf2a080[sess] "GET", "/banners/defr_index2.js+defr_index_left.js+defr_index_right.js;/ext/scriptaculous/prototype.js;/fo/default.js+randomprize. Sep 15 17:29:21 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: child (8415) Started Sep 15 17:29:22 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8415) said Sep 15 17:29:22 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8415) said Child starts Sep 15 17:29:34 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8415) died signal=6 Sep 15 17:29:34 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8415) Panic message: Assert error in sma_trim(), storage_malloc.c line 140: Condition(size < sma->sz) not true. thread = (cache-worker) ident = Linux,2.6.18-194.8.1.el5,x86_64,-smalloc,-hclassic,epoll Backtrace: 0x4234e8: pan_ic+b4 0x4399a6: sma_trim+15a 0x41c013: FetchBody+a9c 0x4128d9: cnt_fetch+692 0x413d8f: CNT_Session+329 0x425791: wrk_do_cnt_sess+b8 0x424ad1: wrk_thread_real+335 0x391580673d: _end+39151a3785 0x39150d3d1d: _end+3914a70d65 sp = 0x2aaaaf505008 { fd = 13, id = 13, xid = 1976549252, client = 192.168.2.12 18014, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaaf505080 { id = "sess", {s,f,r,e} = {0x2aaaaf505cd8,+704,(nil),+8192}, }, http[req] = { ws = 0x2aaaaf505080[sess] "GET", "/ext/scriptaculous/prototype.js+effects.js+versionfix.js+controls.js;/fo/default.js+search.js+track.js+babepage.js;/fms/q Sep 15 17:29:34 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: child (8524) Started Sep 15 17:29:34 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8524) said Sep 15 17:29:34 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8524) said Child starts Sep 15 17:29:36 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8524) died signal=6 Sep 15 17:29:36 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8524) Panic message: Assert error in sma_trim(), storage_malloc.c line 140: Condition(size < sma->sz) not true. thread = (cache-worker) ident = Linux,2.6.18-194.8.1.el5,x86_64,-smalloc,-hclassic,epoll Backtrace: 0x4234e8: pan_ic+b4 0x4399a6: sma_trim+15a 0x41c013: FetchBody+a9c 0x4128d9: cnt_fetch+692 0x413d8f: CNT_Session+329 0x425791: wrk_do_cnt_sess+b8 0x424ad1: wrk_thread_real+335 0x391580673d: _end+39151a3785 0x39150d3d1d: _end+3914a70d65 sp = 0x2aaaaf264008 { fd = 12, id = 12, xid = 1430554042, client = 192.168.2.12 18746, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaaf264080 { id = "sess", {s,f,r,e} = {0x2aaaaf264cd8,+1472,(nil),+8192}, }, http[req] = { ws = 0x2aaaaf264080[sess] "GET", "/ext/scriptaculous/prototype.js+effects.js+versionfix.js+controls.js;/fo/default.js+search.js+track.js+babepage.js;/fms/ Sep 15 17:29:36 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: child (8611) Started Sep 15 17:29:36 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8611) said Sep 15 17:29:36 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8611) said Child starts Sep 15 17:29:36 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8611) died signal=6 Sep 15 17:29:36 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8611) Panic message: Assert error in sma_trim(), storage_malloc.c line 140: Condition(size < sma->sz) not true. thread = (cache-worker) ident = Linux,2.6.18-194.8.1.el5,x86_64,-smalloc,-hclassic,epoll Backtrace: 0x4234e8: pan_ic+b4 0x4399a6: sma_trim+15a 0x41c013: FetchBody+a9c 0x4128d9: cnt_fetch+692 0x413d8f: CNT_Session+329 0x425791: wrk_do_cnt_sess+b8 0x424ad1: wrk_thread_real+335 0x391580673d: _end+39151a3785 0x39150d3d1d: _end+3914a70d65 sp = 0x2aaaaf10c008 { fd = 16, id = 16, xid = 679210775, client = 192.168.2.12 19094, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaaf10c080 { id = "sess", {s,f,r,e} = {0x2aaaaf10ccd8,+784,(nil),+8192}, }, http[req] = { ws = 0x2aaaaf10c080[sess] "GET", "/ext/scriptaculous/prototype.js+effects.js+versionfix.js+controls.js;/fo/default.js+search.js+track.js+babepage.js;/fms/qu Sep 15 17:29:36 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: child (8649) Started Sep 15 17:29:36 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8649) said Sep 15 17:29:36 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8649) said Child starts Sep 15 17:29:38 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8649) died signal=6 Sep 15 17:29:38 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8649) Panic message: Assert error in sma_trim(), storage_malloc.c line 140: Condition(size < sma->sz) not true. thread = (cache-worker) ident = Linux,2.6.18-194.8.1.el5,x86_64,-smalloc,-hclassic,epoll Backtrace: 0x4234e8: pan_ic+b4 0x4399a6: sma_trim+15a 0x41c013: FetchBody+a9c 0x4128d9: cnt_fetch+692 0x413d8f: CNT_Session+329 0x425791: wrk_do_cnt_sess+b8 0x424ad1: wrk_thread_real+335 0x391580673d: _end+39151a3785 0x39150d3d1d: _end+3914a70d65 sp = 0x2aaaabc44008 { fd = 17, id = 17, xid = 1815255751, client = 192.168.2.13 53869, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aaaabc44080 { id = "sess", {s,f,r,e} = {0x2aaaabc44cd8,+784,(nil),+8192}, }, http[req] = { ws = 0x2aaaabc44080[sess] "GET", "/ext/scriptaculous/prototype.js+effects.js+versionfix.js+controls.js;/fo/default.js+search.js+track.js+babepage.js;/fms/q Sep 15 17:29:38 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: child (8743) Started Sep 15 17:29:38 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8743) said Sep 15 17:29:38 nlvrn1 /usr/local/varnish/var/varnish/jscss[8084]: Child (8743) said Child starts}}} varnishd parameters: {{{ /usr/local/varnish/sbin/varnishd -P /var/run/varnish_jscss.pid -a 0.0.0.0:603 -f /usr/local/varnish/etc/varnish/jscss.xxx.xxx.vcl -T 0.0.0.0:703 -s malloc,2048M -i jscss -n /usr/local/varnish/var/varnish/jscss -p listen_depth=16384 -p lru_interval=30 -p sess_timeout=5 -p shm_workspace=65536 -p ping_interval=1 -p thread_pools=4 -p thread_pool_min=25 -p thread_pool_max=4000 -p esi_syntax=1 -p overflow_max=10000 -p sess_workspace=8192 -h classic,500009}}} Tried with and without the sess_workspace. Tried to lower and higher it (up to 128k) but none helped. Thanks for the respons! Keep up the good work. BTW: running revision 5129 of trunk. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 15 19:01:43 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Sep 2010 19:01:43 -0000 Subject: [Varnish] #776: SMA_trim() failed??? In-Reply-To: <042.47b1e58cc7d70cd224146acc5d8054de@varnish-cache.org> References: <042.47b1e58cc7d70cd224146acc5d8054de@varnish-cache.org> Message-ID: <051.eedc8e4ba27b1ea7b15a27b6868a6be9@varnish-cache.org> #776: SMA_trim() failed??? ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5217]) Fix a cornercase of chunked encoding and malloc stevedore: Don't try to trim a storage segment we filled completely. Fixes: #776 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 15 20:08:18 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 15 Sep 2010 20:08:18 -0000 Subject: [Varnish] #777: Documentation on regex with new if parser Message-ID: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> #777: Documentation on regex with new if parser -------------------+-------------------------------------------------------- Reporter: hp197 | Type: documentation Status: new | Priority: lowest Milestone: | Component: documentation Version: trunk | Severity: minor Keywords: | -------------------+-------------------------------------------------------- I noticed the if parsing changed. But now my regex check doesn't work anymore {{{ if ( !req.http.X-Forwarded-For ~ "^(192\.168\.2\.[0-9]{1,3})$" ) { remove req.http.Cache-Control; } }}} This gives me a vcl compilation error on the current revision. Is this not implemented in the new parser yet or is the syntax changed? Thanks (for the second time today) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 16 11:32:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 16 Sep 2010 11:32:04 -0000 Subject: [Varnish] #778: Signal 11 crash in Varnish trunk/4516 Message-ID: <043.3f5ec2f2a0af2eba58bdfebcac692c9d@varnish-cache.org> #778: Signal 11 crash in Varnish trunk/4516 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- I am running Varnish trunk/4516 in FreeBSD/amd64 7.2-RELEASE, using saint mode. Occasionally I get a signal11 crash: Sep 16 09:38:07 cache3 kernel: pid 93634 (varnishd), uid 0: exited on signal 11 (core dumped) Backtrace here: {{{ (gdb) bt #0 0x00000008009d535f in getframeaddr (level=Variable "level" is not available. ) at execinfo.c:285 #1 0x00000008009d5394 in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:70 #2 0x0000000000422538 in pan_backtrace () at cache_panic.c:273 #3 0x0000000000422915 in pan_ic (func=Variable "func" is not available. ) at cache_panic.c:332 #4 0x000000000041df3d in http_copyheader (w=0x7fffce071d10, fd=3905, to=0x8f06958e0, fm=0x7fffce06b350, n=15) at cache_http.c:650 #5 0x000000000041ebf8 in http_FilterFields (w=0x7fffce071d10, fd=3905, to=0x8f06958e0, fm=0x7fffce06b350, how=Variable "how" is not available. ) at cache_http.c:714 #6 0x00000000004133cf in cnt_fetch (sp=0xaa7462008) at cache_center.c:584 #7 0x00000000004148fa in CNT_Session (sp=0xaa7462008) at steps.h:41 #8 0x0000000000424891 in wrk_do_cnt_sess (w=0x7fffce071d10, priv=Variable "priv" is not available. ) at cache_pool.c:294 #9 0x0000000000423b7d in wrk_thread_real (qp=0x80110f6f0, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:183 #10 0x0000000800bf74d1 in pthread_getprio () from /lib/libthr.so.3 #11 0x00007fffcde72000 in ?? () Cannot access memory at address 0x7fffce072000 (gdb) frame 5 #5 0x000000000041ebf8 in http_FilterFields (w=0x7fffce071d10, fd=3905, to=0x8f06958e0, fm=0x7fffce06b350, how=Variable "how" is not available. ) at cache_http.c:714 714 http_copyheader(w, fd, to, fm, u); (gdb) print *w $1 = {magic = 1670491599, nobjhead = 0x8a0159820, nobjcore = 0x86f76d510, stats = {client_req = 2, cache_hit = 0, cache_hitpass = 2, cache_miss = 0, fetch_head = 0, fetch_length = 1, fetch_chunked = 0, fetch_eof = 0, fetch_bad = 0, fetch_close = 0, fetch_oldhttp = 0, fetch_zero = 0, fetch_failed = 0, n_object = 1, n_vampireobject = 0, n_objectcore = 0, n_objecthead = 0, n_objoverflow = 0, s_sess = 1, s_req = 1, s_pipe = 0, s_pass = 1, s_fetch = 1, s_hdrbytes = 324, s_bodybytes = 0, sess_closed = 0, sess_pipeline = 0, sess_readahead = 0, sess_linger = 1, sess_herd = 0}, lastused = 1284621501.1297348, cond = 0x8a05c1580, list = { vtqe_next = 0x7fffcee78d10, vtqe_prev = 0x80110f700}, wrq = 0xaa74621a0, wfd = 0x0, werr = 0, iov = 0x7fffce06a6a0, siov = 128, niov = 0, liov = 0, vcl = 0x0, wlb = 0x7fffce06fca0 "\024", wlp = 0x7fffce06fe6e "", wle = 0x7fffce071ca0 "", wlr = 16, sha256ctx = 0x7fffce071f10, htc = {{ magic = 1041886673, fd = 4389, ws = 0x7fffce071e50, rxbuf = { b = 0x7fffce06bca5 "HTTP/1.1", e = 0x7fffce06bdc0 "????"}, pipeline = { b = 0x7fffce06bdc0 "????", e = 0x7fffce06c24d "X-Varnish-IP: 80.91.37.199"}}}, ws = {{ magic = 905626964, id = 0x444a76 "wrk", s = 0x7fffce06bc90 "X-Varnish: 806894301", f = 0x7fffce06c286 "Date: Thu, 16 Sep 2010 07:18:21 GMT", r = 0x0, e = 0x7fffce06fc90 "", overflow = 0}}, http = {0x7fffce06b7f0, 0x7fffce06b350, 0x7fffce06aeb0}, bereq = 0x7fffce06b7f0, beresp1 = 0x7fffce06aeb0, beresp = 0x7fffce06b350, resp = 0x0, cacheable = 0, age = 0, entered = 1284621501.1304965, ttl = 1284623301.1297348, grace = 21600, do_esi = 0, connect_timeout = 0, first_byte_timeout = 0, between_bytes_timeout = 0} (gdb) print *to $2 = {magic = 1680389577, ws = 0x8f0695820, conds = 0 '\0', logtag = HTTP_Obj, status = 206, protover = 0, shd = 15, hd = 0x8f0695928, hdf = 0x8f0695a18 "", nhd = 11} (gdb) print *fm $3 = {magic = 1680389577, ws = 0x7fffce071e50, conds = 0 '\0', logtag = HTTP_Rx, status = 206, protover = 1.1000000000000001, shd = 64, hd = 0x7fffce06b398, hdf = 0x7fffce06b798 "", nhd = 16} (gdb) frame 4 #4 0x000000000041df3d in http_copyheader (w=0x7fffce071d10, fd=3905, to=0x8f06958e0, fm=0x7fffce06b350, n=15) at cache_http.c:650 650 assert(n < to->shd); }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 17 08:35:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 17 Sep 2010 08:35:39 -0000 Subject: [Varnish] #772: cli_buffer parameter doesn't work. In-Reply-To: <044.12c898455bb056ae4f68271e3a5999e5@varnish-cache.org> References: <044.12c898455bb056ae4f68271e3a5999e5@varnish-cache.org> Message-ID: <053.2bcc0e2756ce5cda2c653cc03e3e3ff4@varnish-cache.org> #772: cli_buffer parameter doesn't work. ----------------------+----------------------------------------------------- Reporter: Estartu | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: cli_buffer ----------------------+----------------------------------------------------- Changes (by martin): * owner: phk => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 17 22:28:34 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 17 Sep 2010 22:28:34 -0000 Subject: [Varnish] #779: Varnish craches Message-ID: <049.2b3f5e8449570b01a6702aaa04e2c52f@varnish-cache.org> #779: Varnish craches --------------------------+------------------------------------------------- Reporter: piripirigoso | Owner: phk Type: defect | Status: new Priority: highest | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.1.3 Severity: blocker | Keywords: varnishd STV_alloc() --------------------------+------------------------------------------------- Dear All, My varnish is crashing. I don't understand the log. Follow the error: '''Sep 16 18:50:46 my-host kernel:varnishd[4436]: segfault at 000000003ffa91a8 rip 0000000000423bf3 rsp 000000003ffa91b0 error 6 Sep 16 21:50:46 my-host varnishd[3214]: Child (4271) died signal=11 Sep 16 21:50:46 my-host varnishd[3214]: child (4437) Started Sep 16 21:50:46 my-host varnishd[3214]: Child (4437) said Sep 16 21:50:46 my-host varnishd[3214]: Child (4437) said Child starts Sep 16 21:50:46 my-host varnishd[3214]: Child (4437) said managed to mmap 29851648 bytes of 29851648 Sep 16 21:50:49 my-host varnishd[3214]: Child (4437) died signal=6 Sep 16 21:50:49 my-host varnishd[3214]: Child (4437) Panic message: Assert error in STV_alloc(), stevedore.c line 192: Condition((st) != NULL) not true. thread = (cache-worker) ident = Linux,2.6.18-164.el5,x86_64,-sfile,-hclassic,epoll Backtrace: 0x422726: /usr/sbin/varnishd [0x422726] 0x437e75: /usr/sbin/varnishd(STV_alloc+0x185) [0x437e75] 0x41a918: /usr/sbin/varnishd(FetchBody+0x4c8) [0x41a918] 0x412960: /usr/sbin/varnishd [0x412960] 0x413ed5: /usr/sbin/varnishd(CNT_Session+0x345) [0x413ed5] 0x424b78: /usr/sbin/varnishd [0x424b78] 0x423e5d: /usr/sbin/varnishd [0x423e5d] 0x3ae0c064a7: /lib64/libpthread.so.0 [0x3ae0c064a7] 0x3ae04d3c2d: /lib64/libc.so.6(clone+0x6d) [0x3ae04d3c2d] sp = 0x2aad6cb00008 { fd = 1117, id = 1117, xid = 1453303514, client = 201.88.100.232:1232, step = STP_FETCH, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esis = 0 ws = 0x2aad6cb00078 { id = "sess", {s,f,r,e} = {0x2aad6cb08c50,+22440,(nil),+10242880}, }, http[req] = { ws = 0x2aad6cb00078[sess] "GET", "/dl/169b4479c740c9f01834ce7431e4e51b/src.swf", "HTTP/1.1", "User-Agent: Opera/9.27 (Windows NT 5.1; U; pt-br)", "Host: img.clickjogos.uol.com.br", "Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1", "Accept-Language: pt- br,pt;q=0.9,en;q=0.8", "Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1", "Referer: http://clickjogos.uol.com.br/Jogos- online/Tiro/Dogfight-2-The-Great-War/", "Cookie2: $Version=1", "Connection: Keep-Alive, TE", "TE: deflate, gzip, chunked, identity, trailers", "Accept-Encoding: gzip", }, worker = 0x2aadbdfffe50 { ws = 0x2aadbdffffc0 { id = "wrk", {s,f,r,e} = {0x2aadbd5b1ee0,+5816,(nil),+10242880}, }, http[bereq] = { ws = 0x2aadbdffffc0[wrk] "GET", "/dl/169b4479c740c9f01834ce7431e4e51b/src.swf", "HTTP/1.1", "User-Agent: Opera/9.27 (Windows NT 5.1; U; pt-br)", "Host: img.clickjogos.uol.com.br", "Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1", "Accept-Language: pt- br,pt;q=0.9,en;q=0.8", "Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1", "Referer: http://clickjogos.uol.com.br/Jogos- online/Tiro/Dogfight-2-The-Great-War/", "Cookie2: $Version=1", "Accept-Encoding: gzip", "X-Varnish: 1453303514", }, http[beresp] = { ws = 0x2aadbdffffc0[wrk] "HTTP/1.1", "200", "OK", "Content-Type: application/x-shockwave- flash", "ETag: "-527502804"", "Accept-Ranges: bytes", "Last-Modified: Fri, 14 Nov 2008 02:42:34 GMT", "Expires: Fri, 17 Sep 2010 21:50:49 GMT", "Cache-Control: max-age=86400", "Content-Length: 3226910", "Date: Thu, 16 Sep 2010 21:50:49 GMT", "Server: lighttpd/1.5.0", }, }, vcl = { srcname = { "input", "Default", "/opt/varnish/etc/varnish/uolproxy_backend.vcl", "/etc/varnish/backend/virgula.vcl", "/etc/varnish/backend/videolog.vcl", "/etc/varnish/backend/hardgamer.vcl", "/etc/varnish/backend/trofeuinternet.vcl", "/etc/varnish/backend/cosmopax.vcl", "/etc/varnish/backend/clickjogos.vcl", "/opt/varnish/etc/varnish/backend/mtv.vcl", }, }, obj = 0x2aaab11bb000 { xid = 1453303514, ws = 0x2aaab11bb020 { id = "obj", {s,f,r,e} = {0x2aaab11bb228,+288,(nil),+3544}, }, http[obj] = { ws = 0x2aaab11bb020[obj] "HTTP/1.1", "200", "OK", "Content-Type: application/x-shockwave- flash", "ETag: "-527502804"", "Last-Modified: Fri, 14 Nov 2008 02:42:34 GMT", "Expires: Fri, 17 Sep 2010 21:50:49 GMT", "Cache-Control: max-age=86400", "Date: Thu, 16 Sep 2010 21:50:49 GMT", "Server: lighttpd/1.5.0", }, len = 0, store = { }, }, }, Sep 16 21:50:49 my-host varnishd[3214]: child (4572) Started Sep 16 18:50:49 my-host kernel:varnishd[4578]: segfault at 000000004023d1a8 rip 0000000000423bf3 rsp 000000004023d1b0 error 6 Sep 16 21:50:49 my-host varnishd[3214]: Pushing vcls failed: CLI communication error (hdr) Sep 16 21:50:49 my-host varnishd[3214]: Child (4572) died signal=11 Sep 16 21:50:49 my-host varnishd[3214]: Child (-1) said Sep 16 21:50:49 my-host varnishd[3214]: Child (-1) said Child starts Sep 16 21:53:00 my-host varnishd[3214]: Manager got SIGINT''' Follow too, my start daemon line: ''' /usr/sbin/varnishd -P /var/run/varnish.pid -T localhost:81 -i uolproxy -f /etc/varnish/uolproxy.vcl -u varnish -h classic,500009 -a :80 -p thread_pools 8 -p thread_pool_min 100 -p thread_pool_max 16288 -p between_bytes_timeout 50s -p connect_timeout 50s -p first_byte_timeout 25s -p lru_interval 60 -p listen_depth 8192 -p sess_workspace 524288 -p shm_workspace 262144 -p ping_interval 3 -p sess_timeout 10 -p send_timeout 6000s -p http_headers 1024 -s malloc,28G''' I have found some users with same issue, but I can't get the solution. Can we help me? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 17 23:58:47 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 17 Sep 2010 23:58:47 -0000 Subject: [Varnish] #779: Varnish craches In-Reply-To: <049.2b3f5e8449570b01a6702aaa04e2c52f@varnish-cache.org> References: <049.2b3f5e8449570b01a6702aaa04e2c52f@varnish-cache.org> Message-ID: <058.d5705f0e3e67ccc3af41cf3d6c658259@varnish-cache.org> #779: Varnish craches ----------------------------------+----------------------------------------- Reporter: piripirigoso | Owner: phk Type: defect | Status: closed Priority: highest | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.1.3 Severity: blocker | Resolution: worksforme Keywords: varnishd STV_alloc() | ----------------------------------+----------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: You have told Varnish to use 28GB malloc storage, but appearantly your system ran out of memory before that limit was hit. Check the ulimits, they may be lower than 28GB, and if you do not have at least 28GB RAM, also check that your swapspace is correctly configured. You may also consider using -sfile instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Sep 19 00:44:30 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 19 Sep 2010 00:44:30 -0000 Subject: [Varnish] #780: fetch_chunked fails to read trailing CRLF, prevents backend connection reuse Message-ID: <045.1942ed9c4aec6a2224b939823eab7ab0@varnish-cache.org> #780: fetch_chunked fails to read trailing CRLF, prevents backend connection reuse ----------------------+----------------------------------------------------- Reporter: askalski | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- bin/varnishd/cache_fetch.c The fetch_chunked() function is not reading in the final CRLF of the chunked response. This prevents the backend connection from being reused. The relevant text from RFC 2616: {{{ Chunked-Body = *chunk last-chunk trailer CRLF <-- This is the CRLF I'm talking about. }}} And some strace output showing what's happening: {{{ # Reading in the last-chunk... read(33, "0", 1) = 1 read(33, "\r", 1) = 1 read(33, "\n", 1) = 1 # ...but not the final CRLF clock_gettime(CLOCK_REALTIME, {1284855439, 471704000}) = 0 . . . # When it comes time to test re-usability of the backend, it fails # because that CRLF is still in the receive queue, waiting to be read. poll([{fd=33, events=POLLIN}], 1, 0) = 1 ([{fd=33, revents=POLLIN}]) close(33) = 0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 20 08:05:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Sep 2010 08:05:16 -0000 Subject: [Varnish] #778: Signal 11 crash in Varnish trunk/4516 In-Reply-To: <043.3f5ec2f2a0af2eba58bdfebcac692c9d@varnish-cache.org> References: <043.3f5ec2f2a0af2eba58bdfebcac692c9d@varnish-cache.org> Message-ID: <052.6bf46bdbe411526ddd87b6290ef9d166@varnish-cache.org> #778: Signal 11 crash in Varnish trunk/4516 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Sorry for not recognizing this one: It's fixed in r4603 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 20 11:01:17 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Sep 2010 11:01:17 -0000 Subject: [Varnish] #780: fetch_chunked fails to read trailing CRLF, prevents backend connection reuse In-Reply-To: <045.1942ed9c4aec6a2224b939823eab7ab0@varnish-cache.org> References: <045.1942ed9c4aec6a2224b939823eab7ab0@varnish-cache.org> Message-ID: <054.a5ee443cbe96fb4b0a575423f3b62249@varnish-cache.org> #780: fetch_chunked fails to read trailing CRLF, prevents backend connection reuse ----------------------+----------------------------------------------------- Reporter: askalski | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 20 11:09:41 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Sep 2010 11:09:41 -0000 Subject: [Varnish] #777: Documentation on regex with new if parser In-Reply-To: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> References: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> Message-ID: <051.ad7d081eac0f80cf75d4d61626864de2@varnish-cache.org> #777: Documentation on regex with new if parser ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: kristian Type: defect | Status: new Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * owner: => kristian * type: documentation => defect * component: documentation => varnishd Comment: Can you paste the compile error you are seeing? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 20 11:34:08 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Sep 2010 11:34:08 -0000 Subject: [Varnish] #666: pmatch: regular expression subexpression references In-Reply-To: <042.76d05c82246fe5e55bdabfd5337d3d51@varnish-cache.org> References: <042.76d05c82246fe5e55bdabfd5337d3d51@varnish-cache.org> Message-ID: <051.4c992fd6deb7c7abf6924759c3c5f7fb@varnish-cache.org> #666: pmatch: regular expression subexpression references -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: pmatch, match, subexpression, back reference -------------------------+-------------------------------------------------- Comment(by slink): Notes from IRC conversation with phk: * Implementation should be cleaned up when we get scoped variables in VCL * We're looking for better syntax -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 20 11:40:45 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Sep 2010 11:40:45 -0000 Subject: [Varnish] #599: WRK_Queue should prefer thread pools with idle threads / improve thread pool loadbalancing In-Reply-To: <042.aacb155ba8936daf642e54f0b92905ea@varnish-cache.org> References: <042.aacb155ba8936daf642e54f0b92905ea@varnish-cache.org> Message-ID: <051.09eafc198346548f953450a7b4b5af25@varnish-cache.org> #599: WRK_Queue should prefer thread pools with idle threads / improve thread pool loadbalancing -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Comment(by slink): I will check if this still applies to trunk. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 20 11:48:05 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Sep 2010 11:48:05 -0000 Subject: [Varnish] #599: WRK_Queue should prefer thread pools with idle threads / improve thread pool loadbalancing In-Reply-To: <042.aacb155ba8936daf642e54f0b92905ea@varnish-cache.org> References: <042.aacb155ba8936daf642e54f0b92905ea@varnish-cache.org> Message-ID: <051.c45f317ec3f781bc6a1216c8a1e4f097@varnish-cache.org> #599: WRK_Queue should prefer thread pools with idle threads / improve thread pool loadbalancing -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- Comment(by slink): From irc conversation: We will revisit this when phk is back out of "3.0 feature mode". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 20 12:25:36 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Sep 2010 12:25:36 -0000 Subject: [Varnish] #777: Documentation on regex with new if parser In-Reply-To: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> References: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> Message-ID: <051.fd8fc0a0a5556aa7b39d82e2c6467624@varnish-cache.org> #777: Documentation on regex with new if parser ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: kristian Type: defect | Status: new Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: ----------------------+----------------------------------------------------- Comment(by hp197): {{{ Starting varnish HTTP accelerator: storage.malloc.storage_0: max size 256 MB. Message from VCC-compiler: Expected ')' got '~' (program line 76), at ('input' Line 62 Pos 40) if ( !req.http.X-Forwarded-For ~ "^(192\.168\.1\.[0-9]{1,3}|92\.70\.242\.66|94\.210\.246\.167|87\.212\.194\.237)$" ) { ---------------------------------------#-------------------------------------------------------------------------------------- Running VCC-compiler failed, exit 1 VCL compilation failed }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 20 19:35:42 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Sep 2010 19:35:42 -0000 Subject: [Varnish] #781: Assigning empty string to bereq.url breaks Message-ID: <040.097be1e54086eea2cb35ccbcb50acebb@varnish-cache.org> #781: Assigning empty string to bereq.url breaks ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: ----------------------+----------------------------------------------------- vcl_miss { set bereq.url = req.http.foo; # where foo doesn't exist leads to Panic message: Assert error in VRT_l_bereq_url(), cache_vrt.c line 284: Condition((p) != 0) not true. } -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 20 20:02:01 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 20 Sep 2010 20:02:01 -0000 Subject: [Varnish] #781: Assigning empty string to bereq.url breaks In-Reply-To: <040.097be1e54086eea2cb35ccbcb50acebb@varnish-cache.org> References: <040.097be1e54086eea2cb35ccbcb50acebb@varnish-cache.org> Message-ID: <049.e3860b375ab31fc3bc4995c91af28e56@varnish-cache.org> #781: Assigning empty string to bereq.url breaks ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5224]) Treat NULL elements of string assignment as empty string line1 proto fields. Refuse assignment of empty strings to line1 proto fields, issue VSL record LostHdr. line1 proto fields are request, url, proto and response. status is numeric and not affected. Fixes: #781 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 09:04:22 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 09:04:22 -0000 Subject: [Varnish] #753: Varnish craches In-Reply-To: <049.e4871ddd65d5d7434dab456a42301aa3@varnish-cache.org> References: <049.e4871ddd65d5d7434dab456a42301aa3@varnish-cache.org> Message-ID: <058.3922ed9a350b96469f4b59c042fb61e3@varnish-cache.org> #753: Varnish craches ---------------------------+------------------------------------------------ Reporter: piripirigoso | Owner: phk Type: defect | Status: closed Priority: highest | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.1.2 Severity: major | Resolution: worksforme Keywords: Panic message | ---------------------------+------------------------------------------------ Comment(by hannosch): I ran into the same problem while running Varnish 2.1.3 on a 32bit system with default sess_workspace, but a total cache size of 1536M. The cookie payload wasn't really that massive in this case: {{{ "Cookie: I18N_LANGUAGE="fi"; serverid=p0102; __utma=141643181.1302391896.1285057807.1285057807.1285057807.1; __utmb=141643181.14.10.1285057807; __utmc=141643181; __utmz=141643181.1285057807.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)" }}} Maybe the default sess_workspace could be larger. But I understand that the 32bit / >1G cache size config is not recommended. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 11:04:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 11:04:00 -0000 Subject: [Varnish] #671: Solaris least privilege support breaks core dumps (SNOCD set) In-Reply-To: <042.aaecd3a48beadf46e953bbd8f5745f77@varnish-cache.org> References: <042.aaecd3a48beadf46e953bbd8f5745f77@varnish-cache.org> Message-ID: <051.fe4bc11708b9871a8e7f9a052a9f9fec@varnish-cache.org> #671: Solaris least privilege support breaks core dumps (SNOCD set) --------------------+------------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Changes (by slink): * owner: => slink * status: new => assigned Comment: will integrate this patch into patch in #670 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 11:19:28 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 11:19:28 -0000 Subject: [Varnish] #663: Varnish should auto-configure pthread support and VCC_CC In-Reply-To: <042.cc3f0c6660efd1422fb857bae27be731@varnish-cache.org> References: <042.cc3f0c6660efd1422fb857bae27be731@varnish-cache.org> Message-ID: <051.bbc47b375c44853d1fa1db9238389346@varnish-cache.org> #663: Varnish should auto-configure pthread support and VCC_CC -------------------------+-------------------------------------------------- Reporter: slink | Owner: phk Type: enhancement | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Keywords: errno, mt-safety, pthread, reentrant -------------------------+-------------------------------------------------- Changes (by slink): * owner: => phk Comment: ready for integration -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 11:24:37 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 11:24:37 -0000 Subject: [Varnish] #598: SIGSEGV due to null pointer dereference in SES_Delete - VSL In-Reply-To: <042.98952b60539de813054840be8e7f2305@varnish-cache.org> References: <042.98952b60539de813054840be8e7f2305@varnish-cache.org> Message-ID: <051.fd3dfa58260539cfcfb58228828fd78f@varnish-cache.org> #598: SIGSEGV due to null pointer dereference in SES_Delete - VSL --------------------+------------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Changes (by slink): * owner: => phk Comment: ready for integration -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 11:51:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 11:51:27 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> References: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> Message-ID: <051.93653caa6ae8b34095fd9b428ab91986@varnish-cache.org> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by slink): Attached patch is for trunk and does not need TIM_t2ts() from #630, which was not accepted. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 13:05:46 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 13:05:46 -0000 Subject: [Varnish] #777: Documentation on regex with new if parser In-Reply-To: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> References: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> Message-ID: <051.18629ab67cff92399627e3a7f791352b@varnish-cache.org> #777: Documentation on regex with new if parser ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: kristian Type: defect | Status: new Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: ----------------------+----------------------------------------------------- Comment(by kristian): I'm still not able to reproduce this. Can you post the entire vcl? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 13:14:20 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 13:14:20 -0000 Subject: [Varnish] #777: Documentation on regex with new if parser In-Reply-To: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> References: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> Message-ID: <051.e103c14f5524422abacc5e9bfa9ed489@varnish-cache.org> #777: Documentation on regex with new if parser ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: kristian Type: defect | Status: new Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: ----------------------+----------------------------------------------------- Comment(by hp197): {{{ director loadbalancer round-robin { { .backend = { .host = "192.168.x.x"; .port = "x"; .connect_timeout = 20s; .first_byte_timeout = 50s; .between_bytes_timeout = 20s; } } { .backend = { .host = "192.168.x.x"; .port = "x"; .connect_timeout = 20s; .first_byte_timeout = 50s; .between_bytes_timeout = 20s; } } } sub vcl_recv { set req.backend = loadbalancer; if (req.url ~ "/alive_test.html") { error 200 "1"; } if (req.restarts == 5) { error 418 "I'm a teapot"; } if (req.restarts > 2) { return (pass); } if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") { return (pipe); } remove req.http.Accept-Encoding; remove req.http.Accept-Charset; remove req.http.Accept-Language; remove req.http.Accept; remove req.http.Referer; remove req.http.Cookie; set req.http.host = "xxx.xxx.xxx"; if ( !req.http.X-Forwarded-For ~ "^(192\.168\.1\.[0-9]{1,3}|92\.70\.242\.66|94\.210\.246\.167|87\.212\.194\.237)$" ) { remove req.http.Cache-Control; } set req.grace = 2m; return (lookup); } sub vcl_pipe { set req.http.connection = "close"; return (pipe); } sub vcl_pass { return (pass); } sub vcl_hash { hash_data(req.url); return (hash); } sub vcl_hit { if (!obj.cacheable) { return (pass); } if (req.http.Cache-Control ~ "no-cache") { set obj.ttl = 0s; return (restart); } return (deliver); } sub vcl_miss { if (req.http.Cache-Control ~ "no-cache") { set bereq.http.Cache-Control = "no-cache"; } return (fetch); } sub vcl_fetch { if (beresp.status == 302 || beresp.status == 301 || beresp.status == 418) { return (pass); } remove beresp.http.Set-Cookie; remove beresp.http.X-Cache; remove beresp.http.Server; remove beresp.http.Age; set beresp.grace = 2m; if (!beresp.cacheable) { return (pass); } return (deliver); } sub vcl_deliver { remove resp.http.Via; remove resp.http.X-Varnish; remove resp.http.Set-Cookie; if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } set resp.http.Server = "us_cache_1"; return (deliver); } sub vcl_error { if (obj.status == 503 && req.restarts <= 4) { return (restart); } set obj.http.Content-Type = "text/html; charset=utf-8"; synthetic {" "} obj.status " " obj.response {"

Error "} obj.status " " obj.response {"

"} obj.response {"

Guru Meditation:

XID: "} req.xid {"

xxx
"}; return (deliver); } }}} Version is trunk revision: 5217 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 13:26:19 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 13:26:19 -0000 Subject: [Varnish] #777: Documentation on regex with new if parser In-Reply-To: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> References: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> Message-ID: <051.4eecfbd2377f43440374e554c2fa1967@varnish-cache.org> #777: Documentation on regex with new if parser ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: kristian Type: defect | Status: new Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: ----------------------+----------------------------------------------------- Comment(by kristian): Ok, I've got it reproduced now, thanks. Looking into it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 15:19:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 15:19:25 -0000 Subject: [Varnish] #777: Documentation on regex with new if parser In-Reply-To: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> References: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> Message-ID: <051.b32801d72d757f03bf6ad2e9fa214848@varnish-cache.org> #777: Documentation on regex with new if parser ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: kristian Type: defect | Status: new Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: ----------------------+----------------------------------------------------- Comment(by kristian): Hmm, right. This requires some thought, we're discussing it at the moment. The problem is: {{{ if (!foo ~ "bar") }}} used to mean the same thing as: {{{ if (!(foo ~ "bar")) }}} However, that is counter to what many would expect from typical operator precedence, and it might be "more correct" to have it mean: {{{ if ((!foo) ~ "bar") }}} Which, in turn, doesn't really make sense to write at all. I'll drop a mail to the -dev list and see what happens. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 16:58:31 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 16:58:31 -0000 Subject: [Varnish] #598: SIGSEGV due to null pointer dereference in SES_Delete - VSL In-Reply-To: <042.98952b60539de813054840be8e7f2305@varnish-cache.org> References: <042.98952b60539de813054840be8e7f2305@varnish-cache.org> Message-ID: <051.b6035cc865132d91c6b430fa7ee12755@varnish-cache.org> #598: SIGSEGV due to null pointer dereference in SES_Delete - VSL --------------------+------------------------------------------------------- Reporter: slink | Owner: phk 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: (In [5225]) If we fail to enqueue a session because all threadpools are filled we drop the session before we have rendered the clients address. Report IP and port as "-" rather than passing NULL pointers, which is not nice under any, and core dump solaris under some circumstances. Fixes: #598 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 17:04:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 17:04:25 -0000 Subject: [Varnish] #670: need to support new solaris privilege net_access In-Reply-To: <042.e202679d59474c68f18db079c22fcb9f@varnish-cache.org> References: <042.e202679d59474c68f18db079c22fcb9f@varnish-cache.org> Message-ID: <051.753b32c50dd6e7a87ee37d8b006574e1@varnish-cache.org> #670: need to support new solaris privilege net_access ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: highest | Milestone: Component: varnishd | Version: trunk Severity: blocker | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5226]) Fix/Update for Solaris priv_set(). Fixes #670 Fixes #671 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 17:04:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 17:04:26 -0000 Subject: [Varnish] #671: Solaris least privilege support breaks core dumps (SNOCD set) In-Reply-To: <042.aaecd3a48beadf46e953bbd8f5745f77@varnish-cache.org> References: <042.aaecd3a48beadf46e953bbd8f5745f77@varnish-cache.org> Message-ID: <051.5f36b88069fb6144e05333695e1343a9@varnish-cache.org> #671: Solaris least privilege support breaks core dumps (SNOCD set) --------------------+------------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: assigned => closed * resolution: => fixed Comment: (In [5226]) Fix/Update for Solaris priv_set(). Fixes #670 Fixes #671 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 17:09:14 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 17:09:14 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> References: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> Message-ID: <051.21e3f58bb370613a86b08821d39add77@varnish-cache.org> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5227]) Update the Solaris "port" based waiter. Fixes #629 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 18:18:42 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 18:18:42 -0000 Subject: [Varnish] #777: Documentation on regex with new if parser In-Reply-To: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> References: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> Message-ID: <051.9914d0532f8248c8e2ea4d08675e6bc0@varnish-cache.org> #777: Documentation on regex with new if parser ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: kristian Type: defect | Status: closed Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5228]) Fix operator precedence for '!' operator Fixes #777 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 21 18:25:51 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 21 Sep 2010 18:25:51 -0000 Subject: [Varnish] #777: Documentation on regex with new if parser In-Reply-To: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> References: <042.1a428a5512e5a0d1723013d2fb13e42e@varnish-cache.org> Message-ID: <051.1afc3751c59417b9f3050832b55c60c8@varnish-cache.org> #777: Documentation on regex with new if parser ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: kristian Type: defect | Status: closed Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by hp197): Thankx. Thought it was undocumented yet (because a few revisions back the complete if statement changed). But it was some sort of 'by design' bug... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 22 08:55:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 22 Sep 2010 08:55:52 -0000 Subject: [Varnish] #663: Varnish should auto-configure pthread support and VCC_CC In-Reply-To: <042.cc3f0c6660efd1422fb857bae27be731@varnish-cache.org> References: <042.cc3f0c6660efd1422fb857bae27be731@varnish-cache.org> Message-ID: <051.24d443ee9fdc5512f58bba09d6ca52b7@varnish-cache.org> #663: Varnish should auto-configure pthread support and VCC_CC -------------------------+-------------------------------------------------- Reporter: slink | Owner: tfheen Type: enhancement | Status: new Priority: high | Milestone: Component: build | Version: trunk Severity: normal | Keywords: errno, mt-safety, pthread, reentrant -------------------------+-------------------------------------------------- Changes (by tfheen): * owner: phk => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 23 09:02:31 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 23 Sep 2010 09:02:31 -0000 Subject: [Varnish] #774: Panic message: Assert error in STV_alloc() In-Reply-To: <046.ecc2f4bc4f7ae0ce88547b074a00b027@varnish-cache.org> References: <046.ecc2f4bc4f7ae0ce88547b074a00b027@varnish-cache.org> Message-ID: <055.9a360dfc0f5d39731c34b5e100af844a@varnish-cache.org> #774: Panic message: Assert error in STV_alloc() -----------------------+---------------------------------------------------- Reporter: wittwerch | Owner: kristian Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: -----------------------+---------------------------------------------------- Comment(by David Busby): I'm having a similar issue, in this case the configuration uses a 4GB Malloc, and typically sits at around 960MB in memory, a normal GET to a html page resulted in this error. varnish-2.0.6-2.el5 varnish-libs-2.0.6-2.el5 rpm's are in use. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 23 10:02:41 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 23 Sep 2010 10:02:41 -0000 Subject: [Varnish] #774: Panic message: Assert error in STV_alloc() In-Reply-To: <046.ecc2f4bc4f7ae0ce88547b074a00b027@varnish-cache.org> References: <046.ecc2f4bc4f7ae0ce88547b074a00b027@varnish-cache.org> Message-ID: <055.2ee3f9cdbf1456a5944602e01b10b579@varnish-cache.org> #774: Panic message: Assert error in STV_alloc() -----------------------+---------------------------------------------------- Reporter: wittwerch | Owner: kristian Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: -----------------------+---------------------------------------------------- Comment(by David Busby): I have upgraded to 2.1.3 in the hop this addresses the issue, please note your information here: http://www.varnish-cache.org/installation/redhat is out of date. rpm --nosignature -i http://repo.varnish-cache.org/redhat/el5/el5/noarch /varnish-release-2.1-1.noarch.rpm yum --nogpgcheck install varnish These are the steps I had to take in order to install from your rpms. Cheers Buzz -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 23 15:02:14 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 23 Sep 2010 15:02:14 -0000 Subject: [Varnish] #782: expose sp->esis to vcl (patch attached) Message-ID: <045.38ab3dedb5c8bc37860e60bac6c20b23@varnish-cache.org> #782: expose sp->esis to vcl (patch attached) ----------------------+----------------------------------------------------- Reporter: askalski | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: esi | ----------------------+----------------------------------------------------- (See ticket #705.) I need to determine in VCL, whether or not a request is an ESI subrequest. The proposed workaround from ticket #705 (req.restarts) doesn't actually work (it's always 0, even for ESI subrequests. The concrete problem I'm trying to solve: Strip cookies only for ESI subrequests, for two reasons: (a) to make them cacheable; (b) to address the security issue of cookies leaking between domains. (Example: ; the Cookie header from the orginal request gets sent to "some.other.domain.com".) {{{ sub vcl_recv { if (req.esis > 0) { remove req.http.Cookie; remove req.http.Authorization; } } sub vcl_fetch { if (req.esis > 0) { remove beresp.http.Set-Cookie; } } }}} I attached a diff against 2.1.3 that adds a read-only "req.esis" keyword that returns the value of sp->esis. (req.esis is probably not the best name choice, because it will be confused easily with req.esi; feel free to change it.) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Sep 26 14:16:25 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 26 Sep 2010 14:16:25 -0000 Subject: [Varnish] #783: Critbit crash in Varnish 2.1.3 Message-ID: <043.1cb99d4518a46b0c4d8e4001edfba412@varnish-cache.org> #783: Critbit crash in Varnish 2.1.3 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: major | Keywords: ----------------------+----------------------------------------------------- I am running Varnish 2.1.3 in FreeBSD/amd64 7.2-RELEASE, with the recommended binary heap patch from r5195. After some days with gdb attached and ping_interval set to 0, I get a crash: {{{ (gdb) bt #0 0x00000008009d94ab in backtrace (buffer=Variable "buffer" is not available. ) at execinfo.c:138 #1 0x0000000000423d36 in pan_ic (func=Variable "func" is not available. ) at cache_panic.c:273 #2 0x0000000000431408 in hcb_lookup (sp=0x80d45d008, noh=0x851219940) at hash_critbit.c:475 #3 0x000000000041db62 in HSH_Lookup (sp=0x80d45d008, poh=0x7ffff6da45e0) at cache_hash.c:349 #4 0x0000000000411f84 in cnt_lookup (sp=0x80d45d008) at cache_center.c:788 #5 0x0000000000414612 in CNT_Session (sp=0x80d45d008) at steps.h:38 #6 0x0000000000426381 in wrk_do_cnt_sess (w=0x7ffff6db7d10, priv=Variable "priv" is not available. ) at cache_pool.c:294 #7 0x0000000000425607 in wrk_thread_real (qp=0x80110e600, shm_workspace=Variable "shm_workspace" is not available. ) at cache_pool.c:183 #8 0x0000000800bfb4d1 in pthread_getprio () from /lib/libthr.so.3 #9 0x00007ffff6bb8000 in ?? () Error accessing memory address 0x7ffff6db8000: Bad address. (gdb) frame 2 #2 0x0000000000431408 in hcb_lookup (sp=0x80d45d008, noh=0x851219940) at hash_critbit.c:475 475 assert(!with_lock); (gdb) print *hp No symbol "hp" in current context. (gdb) print *sp $1 = {magic = 741317722, fd = 251, id = 251, xid = 379794173, restarts = 0, esis = 0, disable_esi = 0, wrk = 0x7ffff6db7d10, sockaddrlen = 16, mysockaddrlen = 128, sockaddr = 0x80d45d2b0, mysockaddr = 0x80d45d330, mylsock = 0x80111b2b0, addr = 0x80d45dcc0 "80.91.37.198", port = 0x80d45dcd0 "49690", doclose = 0x445f29 "Connection: close", http = 0x80d45d3b0, http0 = 0x80d45d838, ws = {{magic = 905626964, id = 0x44a4b8 "sess", s = 0x80d45dcc0 "80.91.37.198", f = 0x80d45dd68 "/", r = 0x0, e = 0x80d46dcc0 "", overflow = 0}}, ws_ses = 0x80d45dcd8 "PURGE", ws_req = 0x80d45dd48 "Accept-Encoding: deflate", digest = "?????\236j$\033??#:?\b\023\2264d??*7vO?\226\v\216?g?", htc = {{ magic = 1041886673, fd = 251, ws = 0x80d45d078, rxbuf = { b = 0x80d45dcd8 "PURGE", e = 0x80d45dd44 ""}, pipeline = {b = 0x0, e = 0x0}}}, t_open = 1285509011.4016879, t_req = 1285509011.401763, t_resp = nan(0x8000000000000), t_end = 1285509011.4016879, grace = 21600, step = STP_LOOKUP, cur_method = 0, handling = 3, sendbody = 0 '\0', wantbody = 1 '\001', err_code = 0, err_reason = 0x0, list = { vtqe_next = 0x0, vtqe_prev = 0x0}, director = 0x80110e8d8, vbe = 0x0, obj = 0x0, objcore = 0x0, objhead = 0x0, vcl = 0x8011d20e8, mem = 0x80d45d000, workreq = {list = {vtqe_next = 0x0, vtqe_prev = 0x0}, func = 0x4262c0 , priv = 0x80d45d008}, acct_tmp = { first = 0, sess = 1, req = 1, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_req = {first = 0, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, acct_ses = { first = 1285509011.4016879, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}} (gdb) frame 3 #3 0x000000000041db62 in HSH_Lookup (sp=0x80d45d008, poh=0x7ffff6da45e0) at cache_hash.c:349 349 oh = hash->lookup(sp, w->nobjhead); }}} I am using -s malloc,50G. I did not set hash algorithm with -h. Man page says I should have classic, but I still get a crash that refers to hash_critbit.c? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 10:18:22 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 10:18:22 -0000 Subject: [Varnish] #784: Varnish crash at HSH_Lookup() Message-ID: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> #784: Varnish crash at HSH_Lookup() ----------------------+----------------------------------------------------- Reporter: censored | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: critical | Keywords: varnishd HSH_Lookup died ----------------------+----------------------------------------------------- On debian 5.0, Linux 2.6.33.7. varnishd crashes in HSH_Lookup(). -a :55555 -T localhost:4092 -f /etc/varnish/default.vcl -s malloc,880G -p thread_pools=4 -p thread_pool_min=200 -p thread_pool_max=2400 -p thread_pool_add_delay=2 -p lru_interval=20" --default.vcl-- backend default { .host = "6.6.6.6"; .port = "80"; } sub vcl_recv { unset req.http.cookie; if (req.request == "HEAD") { return(pass); } } --EOF-- syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) not responding to ping, killing it. syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) died signal=6 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) Panic message: Assert error in HSH_Lookup(), cache_hash.c line 374:#012 Condition((o)->magic == 0x32851d42) not true.#012thread = (cache- worker)#012ident = Linux,2.6.33.7,x86_64,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x424608: /usr/sbin/varnishd [0x424608]#012 0x41e2df: /usr/sbin/varnishd(HSH_Lookup+0x2ff) [0x41e2df]#012 0x412c9b: /usr/sbin/varnishd [0x412c9b]#012 0x4151ad: /usr/sbin/varnishd(CNT_Session+0x38d) [0x4151ad]#012 0x426a48: /usr/sbin/varnishd [0x426a48]#012 0x425d23: /usr/sbin/varnishd [0x425d23]#012 0x7fe04e3aafc7: /lib/libpthread.so.0 [0x7fe04e3aafc7]#012 0x7fe04dc8564d: /lib/libc.so.6(clone+0x6d) [0x7fe04dc8564d]#012sp = 0x7fdede746008 {#012 fd = 198, id = 198, xid = 159666020,#012 client = 1.1.1.1:25723,#012 step = STP_LOOKUP,#012 handling = hash,#012 restarts = 0, esis = 0#012 ws = 0x7fdede746078 { #012 id = "sess",#012 {s,f,r,e} = {0x7fdede746cd0,+288,(nil),+65536},#012 },#012 http[req] = {#012 ws = 0x7fdede746078[sess]#012 "GET",#012 "/static/file.png",#012 "HTTP/1.1",#012 "Accept-Encoding: gzip",#012 "User-Agent: Jakarta Commons-HttpClient/3.1",#012 "Host: foo.bar.com",#012 "X-Forwarded-For: 4.4.4.4, 1.1.1.1",#012 },#012 worker = 0x7fccc53a3e70 {#012 ws = 0x7fccc53a3fe0 { #012 id = "wrk",#012 {s,f,r,e} = {0x7fccc5391e10,0x7fccc5391e10,(nil),+65536},#012 },#012 },#012 vcl = {#012 srcname = {#012 "input",#012 "Default",#012 },#012 },#012},#012 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child cleanup complete syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: child (2662) Started -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 11:00:35 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 11:00:35 -0000 Subject: [Varnish] #784: Varnish crash at HSH_Lookup() In-Reply-To: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> References: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> Message-ID: <054.44cfa9b6f3c02ee8c6cb1151eba0846a@varnish-cache.org> #784: Varnish crash at HSH_Lookup() ----------------------+----------------------------------------------------- Reporter: censored | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: critical | Keywords: varnishd HSH_Lookup died ----------------------+----------------------------------------------------- Description changed by kristian: Old description: > On debian 5.0, Linux 2.6.33.7. varnishd crashes in HSH_Lookup(). > > -a :55555 > -T localhost:4092 > -f /etc/varnish/default.vcl > -s malloc,880G > -p thread_pools=4 > -p thread_pool_min=200 > -p thread_pool_max=2400 > -p thread_pool_add_delay=2 > -p lru_interval=20" > > --default.vcl-- > backend default { > .host = "6.6.6.6"; > .port = "80"; > } > > sub vcl_recv { > unset req.http.cookie; > > if (req.request == "HEAD") { > return(pass); > } > } > --EOF-- > > syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) not > responding to ping, killing it. > syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) died > signal=6 > syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) Panic > message: Assert error in HSH_Lookup(), cache_hash.c line 374:#012 > Condition((o)->magic == 0x32851d42) not true.#012thread = (cache- > worker)#012ident = > Linux,2.6.33.7,x86_64,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x424608: /usr/sbin/varnishd [0x424608]#012 0x41e2df: > /usr/sbin/varnishd(HSH_Lookup+0x2ff) [0x41e2df]#012 0x412c9b: > /usr/sbin/varnishd [0x412c9b]#012 0x4151ad: > /usr/sbin/varnishd(CNT_Session+0x38d) [0x4151ad]#012 0x426a48: > /usr/sbin/varnishd [0x426a48]#012 0x425d23: /usr/sbin/varnishd > [0x425d23]#012 0x7fe04e3aafc7: /lib/libpthread.so.0 [0x7fe04e3aafc7]#012 > 0x7fe04dc8564d: /lib/libc.so.6(clone+0x6d) [0x7fe04dc8564d]#012sp = > 0x7fdede746008 {#012 fd = 198, id = 198, xid = 159666020,#012 client = > 1.1.1.1:25723,#012 step = STP_LOOKUP,#012 handling = hash,#012 > restarts = 0, esis = 0#012 ws = 0x7fdede746078 { #012 id = > "sess",#012 {s,f,r,e} = {0x7fdede746cd0,+288,(nil),+65536},#012 > },#012 http[req] = {#012 ws = 0x7fdede746078[sess]#012 > "GET",#012 "/static/file.png",#012 "HTTP/1.1",#012 > "Accept-Encoding: gzip",#012 "User-Agent: Jakarta Commons- > HttpClient/3.1",#012 "Host: foo.bar.com",#012 "X-Forwarded-For: > 4.4.4.4, 1.1.1.1",#012 },#012 worker = 0x7fccc53a3e70 {#012 ws = > 0x7fccc53a3fe0 { #012 id = "wrk",#012 {s,f,r,e} = > {0x7fccc5391e10,0x7fccc5391e10,(nil),+65536},#012 },#012 },#012 > vcl = {#012 srcname = {#012 "input",#012 > "Default",#012 },#012 },#012},#012 > syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child cleanup complete > syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: child (2662) Started New description: On debian 5.0, Linux 2.6.33.7. varnishd crashes in HSH_Lookup(). {{{ -a :55555 -T localhost:4092 -f /etc/varnish/default.vcl -s malloc,880G -p thread_pools=4 -p thread_pool_min=200 -p thread_pool_max=2400 -p thread_pool_add_delay=2 -p lru_interval=20" --default.vcl-- backend default { .host = "6.6.6.6"; .port = "80"; } sub vcl_recv { unset req.http.cookie; if (req.request == "HEAD") { return(pass); } } --EOF-- syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) not responding to ping, killing it. syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) died signal=6 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) Panic message: Assert error in HSH_Lookup(), cache_hash.c line 374:#012 Condition((o)->magic == 0x32851d42) not true.#012thread = (cache- worker)#012ident = Linux,2.6.33.7,x86_64,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x424608: /usr/sbin/varnishd [0x424608]#012 0x41e2df: /usr/sbin/varnishd(HSH_Lookup+0x2ff) [0x41e2df]#012 0x412c9b: /usr/sbin/varnishd [0x412c9b]#012 0x4151ad: /usr/sbin/varnishd(CNT_Session+0x38d) [0x4151ad]#012 0x426a48: /usr/sbin/varnishd [0x426a48]#012 0x425d23: /usr/sbin/varnishd [0x425d23]#012 0x7fe04e3aafc7: /lib/libpthread.so.0 [0x7fe04e3aafc7]#012 0x7fe04dc8564d: /lib/libc.so.6(clone+0x6d) [0x7fe04dc8564d]#012sp = 0x7fdede746008 {#012 fd = 198, id = 198, xid = 159666020,#012 client = 1.1.1.1:25723,#012 step = STP_LOOKUP,#012 handling = hash,#012 restarts = 0, esis = 0#012 ws = 0x7fdede746078 { #012 id = "sess",#012 {s,f,r,e} = {0x7fdede746cd0,+288,(nil),+65536},#012 },#012 http[req] = {#012 ws = 0x7fdede746078[sess]#012 "GET",#012 "/static/file.png",#012 "HTTP/1.1",#012 "Accept-Encoding: gzip",#012 "User-Agent: Jakarta Commons-HttpClient/3.1",#012 "Host: foo.bar.com",#012 "X-Forwarded-For: 4.4.4.4, 1.1.1.1",#012 },#012 worker = 0x7fccc53a3e70 {#012 ws = 0x7fccc53a3fe0 { #012 id = "wrk",#012 {s,f,r,e} = {0x7fccc5391e10,0x7fccc5391e10,(nil),+65536},#012 },#012 },#012 vcl = {#012 srcname = {#012 "input",#012 "Default",#012 },#012 },#012},#012 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child cleanup complete syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: child (2662) Started }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 11:11:56 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 11:11:56 -0000 Subject: [Varnish] #784: Varnish crash at HSH_Lookup() In-Reply-To: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> References: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> Message-ID: <054.0c78c99998954e2b92dcbca69602f8f1@varnish-cache.org> #784: Varnish crash at HSH_Lookup() ----------------------+----------------------------------------------------- Reporter: censored | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: critical | Keywords: varnishd HSH_Lookup died ----------------------+----------------------------------------------------- Description changed by phk: Old description: > On debian 5.0, Linux 2.6.33.7. varnishd crashes in HSH_Lookup(). > > {{{ > -a :55555 > -T localhost:4092 > -f /etc/varnish/default.vcl > -s malloc,880G > -p thread_pools=4 > -p thread_pool_min=200 > -p thread_pool_max=2400 > -p thread_pool_add_delay=2 > -p lru_interval=20" > > --default.vcl-- > backend default { > .host = "6.6.6.6"; > .port = "80"; > } > > sub vcl_recv { > unset req.http.cookie; > > if (req.request == "HEAD") { > return(pass); > } > } > --EOF-- > > syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) not > responding to ping, killing it. > syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) died > signal=6 > syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) Panic > message: Assert error in HSH_Lookup(), cache_hash.c line 374:#012 > Condition((o)->magic == 0x32851d42) not true.#012thread = (cache- > worker)#012ident = > Linux,2.6.33.7,x86_64,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x424608: /usr/sbin/varnishd [0x424608]#012 0x41e2df: > /usr/sbin/varnishd(HSH_Lookup+0x2ff) [0x41e2df]#012 0x412c9b: > /usr/sbin/varnishd [0x412c9b]#012 0x4151ad: > /usr/sbin/varnishd(CNT_Session+0x38d) [0x4151ad]#012 0x426a48: > /usr/sbin/varnishd [0x426a48]#012 0x425d23: /usr/sbin/varnishd > [0x425d23]#012 0x7fe04e3aafc7: /lib/libpthread.so.0 [0x7fe04e3aafc7]#012 > 0x7fe04dc8564d: /lib/libc.so.6(clone+0x6d) [0x7fe04dc8564d]#012sp = > 0x7fdede746008 {#012 fd = 198, id = 198, xid = 159666020,#012 client = > 1.1.1.1:25723,#012 step = STP_LOOKUP,#012 handling = hash,#012 > restarts = 0, esis = 0#012 ws = 0x7fdede746078 { #012 id = > "sess",#012 {s,f,r,e} = {0x7fdede746cd0,+288,(nil),+65536},#012 > },#012 http[req] = {#012 ws = 0x7fdede746078[sess]#012 > "GET",#012 "/static/file.png",#012 "HTTP/1.1",#012 > "Accept-Encoding: gzip",#012 "User-Agent: Jakarta Commons- > HttpClient/3.1",#012 "Host: foo.bar.com",#012 "X-Forwarded-For: > 4.4.4.4, 1.1.1.1",#012 },#012 worker = 0x7fccc53a3e70 {#012 ws = > 0x7fccc53a3fe0 { #012 id = "wrk",#012 {s,f,r,e} = > {0x7fccc5391e10,0x7fccc5391e10,(nil),+65536},#012 },#012 },#012 > vcl = {#012 srcname = {#012 "input",#012 > "Default",#012 },#012 },#012},#012 > syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child cleanup complete > syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: child (2662) Started > }}} New description: On debian 5.0, Linux 2.6.33.7. varnishd crashes in HSH_Lookup(). {{{ -a :55555 -T localhost:4092 -f /etc/varnish/default.vcl -s malloc,880G -p thread_pools=4 -p thread_pool_min=200 -p thread_pool_max=2400 -p thread_pool_add_delay=2 -p lru_interval=20" --default.vcl-- backend default { .host = "6.6.6.6"; .port = "80"; } sub vcl_recv { unset req.http.cookie; if (req.request == "HEAD") { return(pass); } } --EOF-- syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) not responding to ping, killing it. syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) died signal=6 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child (25316) Panic message: Assert error in HSH_Lookup(), cache_hash.c line 374:#012 Condition((o)->magic == 0x32851d42) not true.#012 thread = (cache-worker)#012 ident = Linux,2.6.33.7,x86_64,-smalloc,-hcritbit,epoll#012 Backtrace:#012 0x424608: /usr/sbin/varnishd [0x424608]#012 0x41e2df: /usr/sbin/varnishd(HSH_Lookup+0x2ff) [0x41e2df]#012 0x412c9b: /usr/sbin/varnishd [0x412c9b]#012 0x4151ad: /usr/sbin/varnishd(CNT_Session+0x38d) [0x4151ad]#012 0x426a48: /usr/sbin/varnishd [0x426a48]#012 0x425d23: /usr/sbin/varnishd [0x425d23]#012 0x7fe04e3aafc7: /lib/libpthread.so.0 [0x7fe04e3aafc7]#012 0x7fe04dc8564d: /lib/libc.so.6(clone+0x6d) [0x7fe04dc8564d]#012 sp = 0x7fdede746008 {#012 fd = 198, id = 198, xid = 159666020,#012 client = 1.1.1.1:25723,#012 step = STP_LOOKUP,#012 handling = hash,#012 restarts = 0, esis = 0#012 ws = 0x7fdede746078 { #012 id = "sess",#012 {s,f,r,e} = {0x7fdede746cd0,+288,(nil),+65536},#012 },#012 http[req] = {#012 ws = 0x7fdede746078[sess]#012 "GET",#012 "/static/file.png",#012 "HTTP/1.1",#012 "Accept-Encoding: gzip",#012 "User-Agent: Jakarta Commons-HttpClient/3.1",#012 "Host: foo.bar.com",#012 "X-Forwarded-For: 4.4.4.4, 1.1.1.1",#012 },#012 worker = 0x7fccc53a3e70 {#012 ws = 0x7fccc53a3fe0 { #012 id = "wrk",#012 {s,f,r,e} = {0x7fccc5391e10,0x7fccc5391e10,(nil),+65536},#012 },#012 },#012 vcl = {#012 srcname = {#012 "input",#012 "Default",#012 },#012 },#012 },#012 syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: Child cleanup complete syslog.1:Sep 27 03:40:28 varnish1 varnishd[7667]: child (2662) Started }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 11:15:40 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 11:15:40 -0000 Subject: [Varnish] #784: Varnish crash at HSH_Lookup() In-Reply-To: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> References: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> Message-ID: <054.6ca0dea9ecf22368a1475a2eba07e804@varnish-cache.org> #784: Varnish crash at HSH_Lookup() ----------------------+----------------------------------------------------- Reporter: censored | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: varnishd HSH_Lookup died ----------------------+----------------------------------------------------- Changes (by kristian): * severity: critical => normal Comment: How often does this occur? I notice 880G malloc. How much of that is physical memory and how much is swap? Does 'dmesg' reveal anything? What is the actual storage used, as I assume it's not 880G of RAM. Also, how much was the back trace modified from the original? (Ie: what parts). The specific assert indicates memory corruption of some sort. Any additional information you might have with regards to this specific system and/or problem would be helpful. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 11:25:13 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 11:25:13 -0000 Subject: [Varnish] #782: expose sp->esis to vcl (patch attached) In-Reply-To: <045.38ab3dedb5c8bc37860e60bac6c20b23@varnish-cache.org> References: <045.38ab3dedb5c8bc37860e60bac6c20b23@varnish-cache.org> Message-ID: <054.c4c652397ea2c37b8081b8fe9cd57d8c@varnish-cache.org> #782: expose sp->esis to vcl (patch attached) -------------------------+-------------------------------------------------- Reporter: askalski | Owner: kristian Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: esi -------------------------+-------------------------------------------------- Changes (by kristian): * owner: => kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 11:30:44 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 11:30:44 -0000 Subject: [Varnish] #783: Critbit crash in Varnish 2.1.3 In-Reply-To: <043.1cb99d4518a46b0c4d8e4001edfba412@varnish-cache.org> References: <043.1cb99d4518a46b0c4d8e4001edfba412@varnish-cache.org> Message-ID: <052.8887252b97c7c146795737627a9ec3c7@varnish-cache.org> #783: Critbit crash in Varnish 2.1.3 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: major | Resolution: duplicate Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => duplicate Comment: This looks like a duplicate of #761 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 11:31:08 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 11:31:08 -0000 Subject: [Varnish] #761: critbit segfault In-Reply-To: <040.60f07b58d2dfaf8df27b4a4d77300498@varnish-cache.org> References: <040.60f07b58d2dfaf8df27b4a4d77300498@varnish-cache.org> Message-ID: <049.6b0c7a7e1d1cc23f2f4030f93c48086d@varnish-cache.org> #761: critbit segfault ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by phk): See also #783 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 11:33:11 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 11:33:11 -0000 Subject: [Varnish] #710: check_varnish.c fails to compile against varnish 2.1.x In-Reply-To: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org> References: <043.efa321db0895611f7542c5d2167a3b16@varnish-cache.org> Message-ID: <052.460314e4c0b292e0a8252b67d3c99321@varnish-cache.org> #710: check_varnish.c fails to compile against varnish 2.1.x --------------------+------------------------------------------------------- Reporter: netmax | Owner: tfheen Type: defect | Status: new Priority: normal | Milestone: Component: nagios | Version: 2.1.2 Severity: normal | Keywords: --------------------+------------------------------------------------------- Changes (by tfheen): * owner: => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 12:21:42 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 12:21:42 -0000 Subject: [Varnish] #723: Incorrect SVN checkout URL in documentation In-Reply-To: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org> References: <045.5d04847b09c0aae8c8b9e6b34677b697@varnish-cache.org> Message-ID: <054.ea83ae9a7a2667cc0f3b236bc30fabce@varnish-cache.org> #723: Incorrect SVN checkout URL in documentation ---------------------------+------------------------------------------------ Reporter: walraven | Owner: perbu Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Comment(by tfheen): (In [5282]) Merge r4988: Fix SVN urls. Fixes: #723 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 13:50:29 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 13:50:29 -0000 Subject: [Varnish] #712: Custom varnishncsa log format In-Reply-To: <042.68735fbe2f2d3636ae319db40a720359@varnish-cache.org> References: <042.68735fbe2f2d3636ae319db40a720359@varnish-cache.org> Message-ID: <051.00727e35747e24d94d2613b5f070324f@varnish-cache.org> #712: Custom varnishncsa log format -------------------+-------------------------------------------------------- Reporter: quipo | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishncsa Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by wido): Is there any eta for this patch to reach a new version of Varnish? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 27 14:16:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 27 Sep 2010 14:16:04 -0000 Subject: [Varnish] #784: Varnish crash at HSH_Lookup() In-Reply-To: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> References: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> Message-ID: <054.9e691d91632213fa9771e01bdf4c8e9d@varnish-cache.org> #784: Varnish crash at HSH_Lookup() ----------------------+----------------------------------------------------- Reporter: censored | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: varnishd HSH_Lookup died ----------------------+----------------------------------------------------- Comment(by censored): - This is the first occurrence. - 24G RAM, 856G Swap. - 6x Intel X-25M SSD 160GB are used for swap. - Only IP-addresses, filenames and hostnames were modified from original backtrace. dmesg is clear, but I found another crash a day earlier: Sep 26 11:07:04 titan varnishd[7667]: Child (7668) said : (malloc) Error in munmap(): Sep 26 11:07:05 titan varnishd[7667]: Child (7668) said : (malloc) Error in munmap(): Sep 26 11:07:05 titan varnishd[7667]: Child (7668) said : (malloc) Error in munmap(): Sep 26 11:07:06 titan varnishd[7667]: Child (7668) said : (malloc) Error in munmap(): Sep 26 11:07:06 titan varnishd[7667]: Child (7668) said // Notice the empty message here ... Sep 26 12:34:56 titan varnishd[7667]: Child (7668) said : (malloc) Error in munmap(): ?#001 // Notice garbage at the end, most lines don't, some do. ( REPEAT x 17k ) Sep 26 15:40:02 titan varnishd[7667]: Child (7668) not responding to ping, killing it. Sep 26 15:40:02 titan varnishd[7667]: Child (7668) died signal=3 Sep 26 15:40:02 titan varnishd[7667]: Child cleanup complete Sep 26 15:40:02 titan varnishd[7667]: child (25316) Started Sep 26 15:40:02 titan varnishd[7667]: Child (25316) said Sep 26 15:40:02 titan varnishd[7667]: Child (25316) said Child starts An identical server is running without any problems. Do you think one of the drives is messing up data? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 08:35:58 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 08:35:58 -0000 Subject: [Varnish] #730: varnishd/cache_fetch.c:FetchBody dropping Content-Length on HEAD In-Reply-To: <045.5df7efb5659ea0e86c7a2e1129826a07@varnish-cache.org> References: <045.5df7efb5659ea0e86c7a2e1129826a07@varnish-cache.org> Message-ID: <054.9fa9b968a1a3a4b9cfd09e1dbc77be35@varnish-cache.org> #730: varnishd/cache_fetch.c:FetchBody dropping Content-Length on HEAD -----------------------+---------------------------------------------------- Reporter: dormando | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Comment(by tfheen): (In [5299]) Merge r5074: Don't suppress Content-Length, Age and Proxy-Auth headers Do not suppress the Content-Length:, Age:, Range: and Proxy-Auth headers from the backend on a pass operation. Fixes: #730 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 09:15:22 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 09:15:22 -0000 Subject: [Varnish] #733: Content-Length set to 0 when no Content-Length headers is set In-Reply-To: <040.c336ba7b81c8072d1f094b1bacdacd8a@varnish-cache.org> References: <040.c336ba7b81c8072d1f094b1bacdacd8a@varnish-cache.org> Message-ID: <049.eafb6bb6de4dbd049f17d80eda64340b@varnish-cache.org> #733: Content-Length set to 0 when no Content-Length headers is set ----------------------+----------------------------------------------------- Reporter: zab | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.1.2 Severity: blocker | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5301]) Merge r5075: Assume EOF encoding if we don't get indication of length If we get a HTTP/1.1 response with no indicatation of length, assume EOF encoding, rather than zero length. This has implications for a number of testcases which were written using the previous assumption. Fixes: #733 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 09:31:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 09:31:39 -0000 Subject: [Varnish] #785: vcl.load and vcl.discard Message-ID: <048.40b3ec207e0d8421adbad9a6742711ef@varnish-cache.org> #785: vcl.load and vcl.discard ------------------------------------------+--------------------------------- Reporter: freshteapot | Type: defect Status: new | Priority: normal Milestone: After Varnish 2.1 | Component: build Version: 2.1.3 | Severity: normal Keywords: vcl.load vcl.use vcl.discard | ------------------------------------------+--------------------------------- Hi, Running: varnishd -V varnishd (varnish-2.1.3 SVN ) Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS Loading a config file using. {{{ vcl.load d2 /var/configs/varnish.vcl vcl.use d2 vcl.discard boot }}} This works as I would expect, removing boot for the list. If I now load a new file. {{{ vcl.load d3 /var/configs/varnish.vcl vcl.use d3 vcl.discard d2 vcl.list 200 63 discarded 1 d2 active 8 d3 }}} I was expecting d2 to have gone, just how boot has been removed. If I now add the file again {{{ vcl.load d3 /var/configs/varnish.vcl vcl.list 200 63 discarded 1 d2 active 8 d3 available 0 d2 }}} Here we have to d2. It should be noted, I still can use the latest "d2" via vcl.use. But the "discarded" note still exists. I noted this is similiar to an older ticket which has been closed. http://www.varnish-cache.org/trac/ticket/145 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 09:34:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 09:34:52 -0000 Subject: [Varnish] #761: critbit segfault In-Reply-To: <040.60f07b58d2dfaf8df27b4a4d77300498@varnish-cache.org> References: <040.60f07b58d2dfaf8df27b4a4d77300498@varnish-cache.org> Message-ID: <049.95e63daba3e46b8215f4aeec5a9621c0@varnish-cache.org> #761: critbit segfault ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5304]) After considerable thinking, I have come to the conclusion that this assert is bogus. There is a window from our lookup until we lock the refcount where a different thread conceiveably could loose the last reference to the objhdr, before we get the lock to increase it. The situation the assert was meant to protect, where we insert a new objhdr, is handled in the "oh == noh" clause earlier, were the weaker "> 0" check is used (rather than "== 1") to cater for the exact same race. Fixes: #761 Fixes: #783 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 09:34:53 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 09:34:53 -0000 Subject: [Varnish] #783: Critbit crash in Varnish 2.1.3 In-Reply-To: <043.1cb99d4518a46b0c4d8e4001edfba412@varnish-cache.org> References: <043.1cb99d4518a46b0c4d8e4001edfba412@varnish-cache.org> Message-ID: <052.658af03ab6d8b2335d9367510bccf621@varnish-cache.org> #783: Critbit crash in Varnish 2.1.3 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * resolution: duplicate => fixed Comment: (In [5304]) After considerable thinking, I have come to the conclusion that this assert is bogus. There is a window from our lookup until we lock the refcount where a different thread conceiveably could loose the last reference to the objhdr, before we get the lock to increase it. The situation the assert was meant to protect, where we insert a new objhdr, is handled in the "oh == noh" clause earlier, were the weaker "> 0" check is used (rather than "== 1") to cater for the exact same race. Fixes: #761 Fixes: #783 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 09:36:29 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 09:36:29 -0000 Subject: [Varnish] #785: vcl.load and vcl.discard In-Reply-To: <048.40b3ec207e0d8421adbad9a6742711ef@varnish-cache.org> References: <048.40b3ec207e0d8421adbad9a6742711ef@varnish-cache.org> Message-ID: <057.9772149cf1f18a7b0e594e40452e2fd0@varnish-cache.org> #785: vcl.load and vcl.discard --------------------------------+------------------------------------------- Reporter: freshteapot | Type: defect Status: closed | Priority: normal Milestone: After Varnish 2.1 | Component: build Version: 2.1.3 | Severity: normal Resolution: worksforme | Keywords: vcl.load vcl.use vcl.discard --------------------------------+------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: This is expected behaviour. Notice the "1" before the discarded d2's name: That is the reference count. Some idle thread still has a reference to this VCL, which prevents us from completing the discard until that thread releases the reference. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 09:43:26 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 09:43:26 -0000 Subject: [Varnish] #746: Varnish keep crashing since i use pipe In-Reply-To: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org> References: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org> Message-ID: <053.1213d9ba658bf8ef1e271917119ec85f@varnish-cache.org> #746: Varnish keep crashing since i use pipe -------------------------+-------------------------------------------------- Reporter: ccastro | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: pipe, 2.1.3 | -------------------------+-------------------------------------------------- Comment(by tfheen): (In [5306]) Merge r5082: Fix a pipe mode corner case Fix a corner-case of pipe mode close-down processing, by simplifying the logic and letting vca_close_session() and VBE_CloseFd() carry out the last rites. Closes: #746 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 10:37:47 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 10:37:47 -0000 Subject: [Varnish] #785: vcl.load and vcl.discard In-Reply-To: <048.40b3ec207e0d8421adbad9a6742711ef@varnish-cache.org> References: <048.40b3ec207e0d8421adbad9a6742711ef@varnish-cache.org> Message-ID: <057.c3f24c3d352be34b213a55ae12881f75@varnish-cache.org> #785: vcl.load and vcl.discard --------------------------------+------------------------------------------- Reporter: freshteapot | Type: defect Status: closed | Priority: normal Milestone: After Varnish 2.1 | Component: build Version: 2.1.3 | Severity: normal Resolution: worksforme | Keywords: vcl.load vcl.use vcl.discard --------------------------------+------------------------------------------- Comment(by freshteapot): Thank you for the quick response, that makes sense. I had wondered what they meant. {{{ vcl.list [status] [thread count] [name] }}} {{{ vcl.list 200 63 }}} I see in "include/cli.h" that you have the response codes defined. 200 - CLIS_OK What does the other code on that line mean? i.e 63 - ? Equally I did do an initial search for this sort of information, if you have fielded this question before, I am sorry. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 12:46:52 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 12:46:52 -0000 Subject: [Varnish] #749: 503 if web server closes connection too soon. In-Reply-To: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org> References: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org> Message-ID: <049.3f7b7c04ee6b3792a38035cc489f3042@varnish-cache.org> #749: 503 if web server closes connection too soon. -------------------------+-------------------------------------------------- Reporter: Dan | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Comment(by tfheen): (In [5313]) Merge r5102: Retry backend fetches Retry backend fetches one time if we got a recycled connection and the transfer failed before we received anything. Fixes: #749 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 12:52:08 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 12:52:08 -0000 Subject: [Varnish] #752: [Bug] [varnish-2.1.2] No Null pointer check [strdup] :: no assertion In-Reply-To: <046.aecab54628e14837d4b17fc39db52bf1@varnish-cache.org> References: <046.aecab54628e14837d4b17fc39db52bf1@varnish-cache.org> Message-ID: <055.7fdb154ce1e285094b061dd92172f519@varnish-cache.org> #752: [Bug] [varnish-2.1.2] No Null pointer check [strdup] :: no assertion --------------------------+------------------------------------------------- Reporter: pprocacci | Owner: phk Type: defect | Status: closed Priority: low | Milestone: Varnish 2.1 release Component: varnishd | Version: 2.1.2 Severity: minor | Resolution: fixed Keywords: Null Pointer | --------------------------+------------------------------------------------- Comment(by tfheen): (In [5314]) Merge r5103: Add a missing assert. Spotted by: pprocacci (Thanks!) Fixes: #752 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 28 17:39:35 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 28 Sep 2010 17:39:35 -0000 Subject: [Varnish] #784: Varnish crash at HSH_Lookup() In-Reply-To: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> References: <045.78a0c9b5aafa8025a5bddb048c9c85eb@varnish-cache.org> Message-ID: <054.99e1a1e04c6f9275cca0a502d3e932bb@varnish-cache.org> #784: Varnish crash at HSH_Lookup() ----------------------+----------------------------------------------------- Reporter: censored | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: varnishd HSH_Lookup died ----------------------+----------------------------------------------------- Comment(by censored): Sorry about the formatting. Just wanted to add that I had the same crash on an identical server. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 07:33:49 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 07:33:49 -0000 Subject: [Varnish] #758: x-forwarded-for header concatenates for every restart In-Reply-To: <045.a2a1f4302fdcbcc87241fe7afe2db0ef@varnish-cache.org> References: <045.a2a1f4302fdcbcc87241fe7afe2db0ef@varnish-cache.org> Message-ID: <054.53a9f9eb4f0ae041f78bd2542da3133a@varnish-cache.org> #758: x-forwarded-for header concatenates for every restart -----------------------+---------------------------------------------------- Reporter: bert-jan | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: 2.1.3 | Severity: normal Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Comment(by tfheen): (In [5324]) Merge r5113: Don't mess with X-forwarded-for on restarts. Fixes: #758 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 07:50:13 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 07:50:13 -0000 Subject: [Varnish] #744: CLI repeats previous commands instead of executing the current one In-Reply-To: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org> References: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org> Message-ID: <049.cd4ce6bcb1decea20b1fe712dbe6dd0d@varnish-cache.org> #744: CLI repeats previous commands instead of executing the current one ----------------------+----------------------------------------------------- Reporter: tgr | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.2 Severity: major | Resolution: fixed Keywords: cli | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5327]) Merge r5116: Kill child process if CLI gets out of sync Whenever the CLI comms with the child process runs of the rails, we have to kill the child: We cannot get the CLI pipes back in sync, even if the child process was just preoccupied with something for much longer than cli_timeout. Fixes: #744 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 08:30:00 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 08:30:00 -0000 Subject: [Varnish] #764: Varnish thinks the backend response is 0 bytes, but only when passing through for MSIE In-Reply-To: <044.8fba0c9e911396c7e592226632e5c512@varnish-cache.org> References: <044.8fba0c9e911396c7e592226632e5c512@varnish-cache.org> Message-ID: <053.04a8fba9ff90b9891a6f29ea29f20021@varnish-cache.org> #764: Varnish thinks the backend response is 0 bytes, but only when passing through for MSIE ----------------------+----------------------------------------------------- Reporter: drwilco | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 08:40:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 08:40:39 -0000 Subject: [Varnish] #763: problem with invalid Headers In-Reply-To: <050.7fd2b5e740c9a9cd98d2c557a6da5890@varnish-cache.org> References: <050.7fd2b5e740c9a9cd98d2c557a6da5890@varnish-cache.org> Message-ID: <059.ffc830abce60b3f2e50018c025c3977a@varnish-cache.org> #763: problem with invalid Headers ---------------------------+------------------------------------------------ Reporter: danielpicolli | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5334]) Add a limited workaround for vary headers having double colons. In general the "be liberal in what you accept" is a good thing, but I am not going to be liberal about anything that could cause us to return wrong content. The truly consistent thing to do would be to error the fetch, but that is a bit on the harsh-side for this specific cornercase, so I have added a test to ignore the first character of the vary header, if it is a colon. Fixes: #763 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 09:28:04 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 09:28:04 -0000 Subject: [Varnish] #739: varnishlog sometimes reports backend logs as client logs In-Reply-To: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org> References: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org> Message-ID: <052.e51477ec4bea89e9af5ef8b496f1c9ea@varnish-cache.org> #739: varnishlog sometimes reports backend logs as client logs ------------------------+--------------------------------------------------- Reporter: thoran | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 2.1.2 Severity: major | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Comment(by tfheen): (In [5341]) Merge r5160: Flush log on backend close Add explicit log flushing when backend connections close to keep log chronology. This is to avoid log lines for the same (reused) FD coming before the closing connection when load is high. Fixes #739 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 10:47:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 10:47:27 -0000 Subject: [Varnish] #624: backend_http11 fails to set HTTP version 1.1 properly In-Reply-To: <042.9066be408f34d865b8fe4f6bcf4d609b@varnish-cache.org> References: <042.9066be408f34d865b8fe4f6bcf4d609b@varnish-cache.org> Message-ID: <051.ba6bad7dc691813ac0a06dea7366267d@varnish-cache.org> #624: backend_http11 fails to set HTTP version 1.1 properly ----------------------+----------------------------------------------------- Reporter: janne | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by phk): Going over old tickets, I've looked at this again. I still think it is correct behaviour to forward the clients HTTP/1.0 on pass and pipe, we should be as unintrusive in that case as possible. The main problem, the HTTP/1.1 reply to HTTP/1.0 requests, without "Connection: close", has been fixed in the meantime as part of another ticket (can't recall the number). So I belive this works correct now, and that the fixes have been merged into the 2.1 branch in preparation for the 2.1.4 release. Can I get you to check out the branches/2.1 and test that ? Thanks in advance, and sorry for the slow reply. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 10:54:05 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 10:54:05 -0000 Subject: [Varnish] #662: "Connection refused" crashes In-Reply-To: <044.643fd4d21429d19f7ac5cc49a1092cf1@varnish-cache.org> References: <044.643fd4d21429d19f7ac5cc49a1092cf1@varnish-cache.org> Message-ID: <053.f8faac201cd3ad14f2493f951792b219@varnish-cache.org> #662: "Connection refused" crashes ----------------------+----------------------------------------------------- Reporter: wrighty | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: critical | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Going over old tickets I looked at this one. I belive this has been fixed in the meantime. If not, feel free to reopen. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 10:55:44 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 10:55:44 -0000 Subject: [Varnish] #624: backend_http11 fails to set HTTP version 1.1 properly In-Reply-To: <042.9066be408f34d865b8fe4f6bcf4d609b@varnish-cache.org> References: <042.9066be408f34d865b8fe4f6bcf4d609b@varnish-cache.org> Message-ID: <051.7224e64feb84c2f2aaa2074f0714d04d@varnish-cache.org> #624: backend_http11 fails to set HTTP version 1.1 properly ----------------------+----------------------------------------------------- Reporter: janne | Owner: kristian Type: defect | Status: assigned Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by janne): I'm no longer working with the project where we had a problem with this. So, I think it's best to close this ticket and hope everything works. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 10:58:35 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 10:58:35 -0000 Subject: [Varnish] #624: backend_http11 fails to set HTTP version 1.1 properly In-Reply-To: <042.9066be408f34d865b8fe4f6bcf4d609b@varnish-cache.org> References: <042.9066be408f34d865b8fe4f6bcf4d609b@varnish-cache.org> Message-ID: <051.bbf052c7d093af7ce847452cd947583d@varnish-cache.org> #624: backend_http11 fails to set HTTP version 1.1 properly ----------------------+----------------------------------------------------- Reporter: janne | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.1 release Component: varnishd | Version: Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: assigned => closed * resolution: => worksforme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 11:35:49 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 11:35:49 -0000 Subject: [Varnish] #760: varnishlog unbuffered output In-Reply-To: <045.bbcca487396d337b069b2c55e4ee6665@varnish-cache.org> References: <045.bbcca487396d337b069b2c55e4ee6665@varnish-cache.org> Message-ID: <054.3e0f03be626af5ebd2edb2513f3af58a@varnish-cache.org> #760: varnishlog unbuffered output -------------------------------+-------------------------------------------- Reporter: blade106 | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: varnishlog output | -------------------------------+-------------------------------------------- Comment(by tfheen): (In [5345]) Merge r5176: Apply optional unbuffered output on stdout before call to do_order. Fixes: #760 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 12:09:40 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 12:09:40 -0000 Subject: [Varnish] #775: wrong documentation In-Reply-To: <044.ccbdfeb9e6745156653465eabc2cc801@varnish-cache.org> References: <044.ccbdfeb9e6745156653465eabc2cc801@varnish-cache.org> Message-ID: <053.3130cafa9ce169e1bc8682bb25b47000@varnish-cache.org> #775: wrong documentation --------------------------------+------------------------------------------- Reporter: behrang | Type: documentation Status: closed | Priority: low Milestone: After Varnish 2.1 | Component: documentation Version: trunk | Severity: minor Resolution: fixed | Keywords: --------------------------------+------------------------------------------- Comment(by tfheen): (In [5348]) Merge r5190: Fix typo close #775 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 12:14:31 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 12:14:31 -0000 Subject: [Varnish] #708: XML display is not documented In-Reply-To: <043.ef00f4612fb85c87d480634e4de05a49@varnish-cache.org> References: <043.ef00f4612fb85c87d480634e4de05a49@varnish-cache.org> Message-ID: <052.1595b22b77aea213ea34765b15ebdb28@varnish-cache.org> #708: XML display is not documented ---------------------------+------------------------------------------------ Reporter: jerome | Owner: perbu Type: documentation | Status: closed Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: minor | Resolution: fixed Keywords: varnishstat | ---------------------------+------------------------------------------------ Comment(by tfheen): (In [5349]) Merge r5191: Document -x to varnishstat closes #708 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 29 22:08:39 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 29 Sep 2010 22:08:39 -0000 Subject: [Varnish] #786: ESI includes don't follow 301 and 302 redirects Message-ID: <051.c431285741f2134d6828acd4e6fc55a2@varnish-cache.org> #786: ESI includes don't follow 301 and 302 redirects ----------------------------+----------------------------------------------- Reporter: jorgen@? | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: varnishd, esi, redirect, 301, 302 ----------------------------+----------------------------------------------- When using and http://localhost/test responds with an HTTP 301 or 302 redirect, the content of the 301 or 302 response is included, not the content of the resource given in the Location header. This can give results like this:

ESI test

301 Moved Permanently

Moved Permanently

The document has moved here.

The source in this case was

ESI test

In my opinion, the redirects should be followed. If that causes performance loss, it should be possible to configure varnish to turn on or off redirect following in ESI includes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 06:15:23 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 06:15:23 -0000 Subject: [Varnish] #768: varnishstat sms_balloc/sms_nbytes race condition In-Reply-To: <045.ff365b39a47f2027f48d9972a383214a@varnish-cache.org> References: <045.ff365b39a47f2027f48d9972a383214a@varnish-cache.org> Message-ID: <054.6a0a3c6c7501e72a83e9fb8d2f9505cb@varnish-cache.org> #768: varnishstat sms_balloc/sms_nbytes race condition -----------------------+---------------------------------------------------- Reporter: askalski | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: trivial Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Comment(by tfheen): (In [5360]) Merge r5210: Lock the sms counters properly Fixes: #768 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 06:24:07 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 06:24:07 -0000 Subject: [Varnish] #769: Vcl_error not respecting set obj.status in vcl_error In-Reply-To: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> References: <047.d7ac7a70a26836199ba762f469b9d888@varnish-cache.org> Message-ID: <056.e78b034197b5b3b5ac907a3ee1956c81@varnish-cache.org> #769: Vcl_error not respecting set obj.status in vcl_error ------------------------+--------------------------------------------------- Reporter: stewsnooze | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Comment(by tfheen): (In [5361]) Merge r5211: Set the int status when setting the txt header status in VRT_l_[obj|resp|beresp]_status. Fixes: #769 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 06:57:48 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 06:57:48 -0000 Subject: [Varnish] #776: SMA_trim() failed??? In-Reply-To: <042.47b1e58cc7d70cd224146acc5d8054de@varnish-cache.org> References: <042.47b1e58cc7d70cd224146acc5d8054de@varnish-cache.org> Message-ID: <051.3a93aed22323f34307e2755ea2b80470@varnish-cache.org> #776: SMA_trim() failed??? ----------------------+----------------------------------------------------- Reporter: hp197 | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5363]) Merge r5217: Fix a cornercase of chunked encoding and malloc stevedore Don't try to trim a storage segment we filled completely. Fixes: #776 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 08:56:27 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 08:56:27 -0000 Subject: [Varnish] #598: SIGSEGV due to null pointer dereference in SES_Delete - VSL In-Reply-To: <042.98952b60539de813054840be8e7f2305@varnish-cache.org> References: <042.98952b60539de813054840be8e7f2305@varnish-cache.org> Message-ID: <051.09301ab424f8a6b6cf0d8598aa4cf296@varnish-cache.org> #598: SIGSEGV due to null pointer dereference in SES_Delete - VSL --------------------+------------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment(by tfheen): (In [5365]) Merge r5225: Report IP and port as "-" rather than passing NULL pointers If we fail to enqueue a session because all threadpools are filled we drop the session before we have rendered the clients address. Report IP and port as "-" rather than passing NULL pointers, which is not nice under any, and core dump solaris under some circumstances. Fixes: #598 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 09:04:41 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 09:04:41 -0000 Subject: [Varnish] #670: need to support new solaris privilege net_access In-Reply-To: <042.e202679d59474c68f18db079c22fcb9f@varnish-cache.org> References: <042.e202679d59474c68f18db079c22fcb9f@varnish-cache.org> Message-ID: <051.9348306e8e140ef99959900c8e7379a6@varnish-cache.org> #670: need to support new solaris privilege net_access ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: highest | Milestone: Component: varnishd | Version: trunk Severity: blocker | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5366]) Merge r5226: Fix/Update for Solaris priv_set(). Fixes #670 Fixes #671 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 09:04:47 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 09:04:47 -0000 Subject: [Varnish] #671: Solaris least privilege support breaks core dumps (SNOCD set) In-Reply-To: <042.aaecd3a48beadf46e953bbd8f5745f77@varnish-cache.org> References: <042.aaecd3a48beadf46e953bbd8f5745f77@varnish-cache.org> Message-ID: <051.66c33c2186fb36645b4447f0ce525af8@varnish-cache.org> #671: Solaris least privilege support breaks core dumps (SNOCD set) --------------------+------------------------------------------------------- Reporter: slink | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment(by tfheen): (In [5366]) Merge r5226: Fix/Update for Solaris priv_set(). Fixes #670 Fixes #671 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 09:19:55 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 09:19:55 -0000 Subject: [Varnish] #629: Fix the (Open)Solaris event port acceptor In-Reply-To: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> References: <042.80ab49441cc8c341e7967f8ebc50ce39@varnish-cache.org> Message-ID: <051.d06bcb1e5c032dc7f12be7e42cae51b7@varnish-cache.org> #629: Fix the (Open)Solaris event port acceptor ----------------------+----------------------------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5367]) Merge r5227: Update the Solaris "port" based waiter. Fixes #629 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 09:36:16 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 09:36:16 -0000 Subject: [Varnish] #761: critbit segfault In-Reply-To: <040.60f07b58d2dfaf8df27b4a4d77300498@varnish-cache.org> References: <040.60f07b58d2dfaf8df27b4a4d77300498@varnish-cache.org> Message-ID: <049.64c383185a137946df03729851167fff@varnish-cache.org> #761: critbit segfault ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5368]) Merge r5304: Remove bogus assert After considerable thinking, I have come to the conclusion that this assert is bogus. There is a window from our lookup until we lock the refcount where a different thread conceiveably could loose the last reference to the objhdr, before we get the lock to increase it. The situation the assert was meant to protect, where we insert a new objhdr, is handled in the "oh == noh" clause earlier, were the weaker "> 0" check is used (rather than "== 1") to cater for the exact same race. Fixes: #761 Fixes: #783 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 09:36:18 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 09:36:18 -0000 Subject: [Varnish] #783: Critbit crash in Varnish 2.1.3 In-Reply-To: <043.1cb99d4518a46b0c4d8e4001edfba412@varnish-cache.org> References: <043.1cb99d4518a46b0c4d8e4001edfba412@varnish-cache.org> Message-ID: <052.ae34c79667d2d37f6069300d34c7de14@varnish-cache.org> #783: Critbit crash in Varnish 2.1.3 ----------------------+----------------------------------------------------- Reporter: anders | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Comment(by tfheen): (In [5368]) Merge r5304: Remove bogus assert After considerable thinking, I have come to the conclusion that this assert is bogus. There is a window from our lookup until we lock the refcount where a different thread conceiveably could loose the last reference to the objhdr, before we get the lock to increase it. The situation the assert was meant to protect, where we insert a new objhdr, is handled in the "oh == noh" clause earlier, were the weaker "> 0" check is used (rather than "== 1") to cater for the exact same race. Fixes: #761 Fixes: #783 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 09:52:12 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 09:52:12 -0000 Subject: [Varnish] #763: problem with invalid Headers In-Reply-To: <050.7fd2b5e740c9a9cd98d2c557a6da5890@varnish-cache.org> References: <050.7fd2b5e740c9a9cd98d2c557a6da5890@varnish-cache.org> Message-ID: <059.3eacb004e35d1f83c61c81c1df3047a6@varnish-cache.org> #763: problem with invalid Headers ---------------------------+------------------------------------------------ Reporter: danielpicolli | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ---------------------------+------------------------------------------------ Comment(by tfheen): (In [5369]) Merge r5334, r5335: Add a limited workaround for vary headers having double colons. In general the "be liberal in what you accept" is a good thing, but I am not going to be liberal about anything that could cause us to return wrong content. The truly consistent thing to do would be to error the fetch, but that is a bit on the harsh-side for this specific cornercase, so I have added a test to ignore the first character of the vary header, if it is a colon. Fixes: #763 5335 is: Add regression test for #763 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 30 11:10:08 2010 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 30 Sep 2010 11:10:08 -0000 Subject: [Varnish] #481: Retain information about backends post-vbe_conn destruction for use in VCL In-Reply-To: <040.2e09faebea8b0cf2ab851e3c9316cc96@varnish-cache.org> References: <040.2e09faebea8b0cf2ab851e3c9316cc96@varnish-cache.org> Message-ID: <049.711c2db99291837064246eaa15cd8ce9@varnish-cache.org> #481: Retain information about backends post-vbe_conn destruction for use in VCL -------------------------+-------------------------------------------------- Reporter: mbm | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: VCL backend | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: (In [5371]) Add three new VCL variables, readble from vcl_fetch{} only: beresp.backend.name (STRING) VCL name of backend fetched from. This name may have the form "somedirector[29]" if backends are declared directly in directors. beresp.backend.ip (IP) IP number of remote end of connection. beresp.backend.port (INT) TCP port number of remote end of connection. Fixes: #481 -- Ticket URL: Varnish The Varnish HTTP Accelerator