From varnish-bugs at varnish-cache.org Fri Apr 1 08:21:19 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Apr 2011 08:21:19 -0000 Subject: [Varnish] #890: Assert error in cnt_fetch() Message-ID: <045.8f3c1c4316d47d2873cf4d5c515feb22@varnish-cache.org> #890: Assert error in cnt_fetch() ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Using nightl RPMS from 31st of march (or 1st of april). {{{ Assert error in cnt_fetch(), cache_center.c line 472: Condition((sp->wrk->do_close) == 0) not true. thread = (cache-worker) ident = Linux,2.6.18-194.el5,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x42a4f6: /usr/sbin/varnishd [0x42a4f6] 0x414b65: /usr/sbin/varnishd [0x414b65] 0x4165f1: /usr/sbin/varnishd(CNT_Session+0x3b1) [0x4165f1] 0x41dd98: /usr/sbin/varnishd(ESI_Deliver+0x8a8) [0x41dd98] 0x42d138: /usr/sbin/varnishd(RES_WriteObj+0x378) [0x42d138] 0x415700: /usr/sbin/varnishd [0x415700] 0x4165a9: /usr/sbin/varnishd(CNT_Session+0x369) [0x4165a9] 0x42cb28: /usr/sbin/varnishd [0x42cb28] 0x42bd0f: /usr/sbin/varnishd [0x42bd0f] 0x3aac40673d: /lib64/libpthread.so.0 [0x3aac40673d] sp = 0x2aaae0e00008 { fd = 14, id = 14, xid = 1060976467, client = 87.238.55.186 40081, step = STP_FETCH, handling = pass, err_code = 307, err_reason = (null), restarts = 1, esi_level = 1 ws = 0x2aaae0e00080 { id = "sess", {s,f,r,e} = {0x2aaae0e00cf0,+1056,(nil),+2621440}, }, http[req] = { ws = 0x2aaae0e00080[sess] "GET", "/componada/component/show- esi/normal/football/sms/www.an.no/33?encoding=UTF-8&lang=nb_NO_www.an.no", "HTTP/1.0", "Referer: http://www.an.no/", "User-Agent: Wget/1.12 (linux-gnu)", "Accept: */*", "Connection: close", "X-Forwarded-For: 87.238.55.186", "x-orig-url: /componada/component/show- esi/normal/section/element/www.an.no/33/2713431/small/sec/element180/_/?encoding=UTF-8&lang=nb_NO_www.an.no", "x-orig-cc: max-age=86400, channel="http://localhost:9006/atomizer/event/current", channel-maxage, group="/componada-fibba", group="/relax-nominell", group="/pub33", group ="/com-section-element", group="/sec2092", group="/art2713431"", "Host: localhost", }, worker = 0x531a9de0 { ws = 0x531a9f80 { id = "wrk", {s,f,r,e} = {0x53197d90,+24,(nil),+65536}, }, http[bereq] = { ws = 0x531a9f80[wrk] "GET", "/componada/component/show- esi/normal/football/sms/www.an.no/33?encoding=UTF-8&lang=nb_NO_www.an.no", "HTTP/1.0", "Referer: http://www.an.no/", "User-Agent: Wget/1.12 (linux-gnu)", "Accept: */*", "X-Forwarded-For: 87.238.55.186", "x-orig-url: /componada/component/show- esi/normal/section/element/www.an.no/33/2713431/small/sec/element180/_/?encoding=UTF-8&lang=nb_NO_www.an.no", "x-orig-cc: max-age=86400, channel="http://localhost:9006/atomizer/event/current", channel-maxage, group="/componada-fibba", group="/relax-nominell", group="/pub33", group ="/com-section-element", group="/sec2092", group="/art2713431"", "Host: localhost", "X-Varnish: 1060976467", }, }, vcl = { srcname = { "input", "Default", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", }, }, }, }}} Can provide core-dump too. Heavily ESI'ed site. Took an hour or so to trigger it with a wget. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 1 08:33:27 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Apr 2011 08:33:27 -0000 Subject: [Varnish] #886: Ban-related crashes In-Reply-To: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> References: <045.64316b91ce1ff1e7f15f27486f68e833@varnish-cache.org> Message-ID: <054.829e3b70eab301f59bdc72b5c954b472@varnish-cache.org> #886: Ban-related crashes ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by kristian): Caught the assert now, after that was added... {{{ varnish> panic.show 200 Last panic at: Fri, 01 Apr 2011 08:31:12 GMT Assert error in ban_check_object(), cache_ban.c line 449: Condition((b) != NULL) not true. thread = (cache-worker) ident = Linux,2.6.18-194.el5,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x42a4f6: /usr/sbin/varnishd [0x42a4f6] 0x41332d: /usr/sbin/varnishd [0x41332d] 0x4246ec: /usr/sbin/varnishd(HSH_Lookup+0x38c) [0x4246ec] 0x413ea0: /usr/sbin/varnishd [0x413ea0] 0x416719: /usr/sbin/varnishd(CNT_Session+0x4d9) [0x416719] 0x41dd98: /usr/sbin/varnishd(ESI_Deliver+0x8a8) [0x41dd98] 0x42d138: /usr/sbin/varnishd(RES_WriteObj+0x378) [0x42d138] 0x415700: /usr/sbin/varnishd [0x415700] 0x4165a9: /usr/sbin/varnishd(CNT_Session+0x369) [0x4165a9] 0x42cb28: /usr/sbin/varnishd [0x42cb28] sp = 0x2aaaba200008 { fd = 5, id = 5, xid = 589004886, client = 87.238.55.186 56237, step = STP_LOOKUP, handling = hash, restarts = 0, esi_level = 1 ws = 0x2aaaba200080 { id = "sess", {s,f,r,e} = {0x2aaaba200cf0,+280,(nil),+2621440}, }, http[req] = { ws = 0x2aaaba200080[sess] "GET", "/componada/component/show- esi/normal/section/element/www.an.no/33/5540107/medium/sec/element230/_/?encoding=UTF-8&lang=nb_NO_www.an.no", "HTTP/1.0", "Referer: http://www.an.no/", "User-Agent: Wget/1.12 (linux-gnu)", "Accept: */*", "Connection: close", "Host: localhost", "X-Forwarded-For: 87.238.55.186", }, worker = 0x52151de0 { ws = 0x52151f80 { id = "wrk", {s,f,r,e} = {0x5213fd90,+5128,(nil),+65536}, }, }, vcl = { srcname = { "input", "Default", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", "/etc/varnish/include-v3art-ng.vcl", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 1 13:34:31 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Apr 2011 13:34:31 -0000 Subject: [Varnish] #892: fetching gzipped data yield guru med. Message-ID: <042.574620d0712ee59c24de86829592566c@varnish-cache.org> #892: fetching gzipped data yield guru med. --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- When fetching http://www.varnish-cache.org/lists/pipermail/varnish- misc/2011-March.txt.gz a guru error is thrown: Varnishlog: 13 ObjHeader c X-ESI: off 13 FetchError c Incomplete Gzip data (not STREAM_END) 13 FetchError c chunked read_error: 0 (Success) 13 Gzip c u F - 8106 8051 80 0 0 15 Fetch_Body b 3 -1 1 15 BackendClose b project 13 VCL_call c error 13 VCL_return c deliver 13 VCL_call c deliver 13 VCL_return c deliver 13 TxProtocol c HTTP/1.1 13 TxStatus c 503 13 TxResponse c Service Unavailable 13 TxHeader c Server: Varnish 13 TxHeader c Content-Type: text/html; charset=utf-8 13 TxHeader c Retry-After: 5 13 TxHeader c Content-Length: 418 13 TxHeader c Accept-Ranges: bytes 13 TxHeader c Date: Fri, 01 Apr 2011 13:32:09 GMT 13 TxHeader c X-Varnish: 958469919 13 TxHeader c Age: 0 13 TxHeader c Via: 1.1 varnish 13 TxHeader c Connection: close 13 Length c 418 13 ReqEnd c 958469919 1301664729.474170685 1301664729.481045961 0.000211477 0.006787777 0.000087500 13 SessionClose c error 13 StatSess c 78.41.169.2 49336 0 1 1 0 0 0 256 418 13 SessionOpen c 78.41.169.2 49337 :80 13 ReqStart c 78.41.169.2 49337 958469920 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 1 13:34:31 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Apr 2011 13:34:31 -0000 Subject: [Varnish] #891: fetching gzipped data yield guru med. Message-ID: <042.e8aa487ad7a6b6c9abbcacf5c3ed5d5b@varnish-cache.org> #891: fetching gzipped data yield guru med. --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- When fetching http://www.varnish-cache.org/lists/pipermail/varnish- misc/2011-March.txt.gz a guru error is thrown: Varnishlog: 13 ObjHeader c X-ESI: off 13 FetchError c Incomplete Gzip data (not STREAM_END) 13 FetchError c chunked read_error: 0 (Success) 13 Gzip c u F - 8106 8051 80 0 0 15 Fetch_Body b 3 -1 1 15 BackendClose b project 13 VCL_call c error 13 VCL_return c deliver 13 VCL_call c deliver 13 VCL_return c deliver 13 TxProtocol c HTTP/1.1 13 TxStatus c 503 13 TxResponse c Service Unavailable 13 TxHeader c Server: Varnish 13 TxHeader c Content-Type: text/html; charset=utf-8 13 TxHeader c Retry-After: 5 13 TxHeader c Content-Length: 418 13 TxHeader c Accept-Ranges: bytes 13 TxHeader c Date: Fri, 01 Apr 2011 13:32:09 GMT 13 TxHeader c X-Varnish: 958469919 13 TxHeader c Age: 0 13 TxHeader c Via: 1.1 varnish 13 TxHeader c Connection: close 13 Length c 418 13 ReqEnd c 958469919 1301664729.474170685 1301664729.481045961 0.000211477 0.006787777 0.000087500 13 SessionClose c error 13 StatSess c 78.41.169.2 49336 0 1 1 0 0 0 256 418 13 SessionOpen c 78.41.169.2 49337 :80 13 ReqStart c 78.41.169.2 49337 958469920 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 1 13:35:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Apr 2011 13:35:08 -0000 Subject: [Varnish] #892: fetching gzipped data yield guru med. In-Reply-To: <042.574620d0712ee59c24de86829592566c@varnish-cache.org> References: <042.574620d0712ee59c24de86829592566c@varnish-cache.org> Message-ID: <051.21f170f357864dedb4d9eb77cfde7818@varnish-cache.org> #892: fetching gzipped data yield guru med. --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------------------------------- Changes (by perbu): * status: new => closed * resolution: => invalid Comment: Duplicate. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 1 13:49:15 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 01 Apr 2011 13:49:15 -0000 Subject: [Varnish] #893: When running with -M one must specify a couple of other options Message-ID: <042.3e6fdf08f102c1d134b7ef9e9f5dcf81@varnish-cache.org> #893: When running with -M one must specify a couple of other options --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- When running varnishd -M (..) varnishd will refuse to start unless you also specify one of the following options: perbu at smoke:~/git/varnish-cache/bin/varnishd$ ./varnishd -a localhost:9090 -n /tmp/v -M localhost:2000 At least one of -d, -b, -f, -S or -T must be specified When running with -M this should not be necessary. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 2 17:33:47 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 02 Apr 2011 17:33:47 -0000 Subject: [Varnish] #894: Missing errorhandling code in vep_do_include(), cache_esi_parse.c line 453: Message-ID: <042.790980b464289c7c5c421f7d6af94025@varnish-cache.org> #894: Missing errorhandling code in vep_do_include(), cache_esi_parse.c line 453: --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Still on 3c8e5203ebd7ad232c80406511d4288a41a6fc87 ("Only do CRC calculation once."). Some bot came along and crashed varnish. {{{ Last panic at: Sat, 02 Apr 2011 11:56:20 GMT Missing errorhandling code in vep_do_include(), cache_esi_parse.c line 453: Condition((vep->include_src) == 0) not true.thread = (cache-worker) ident = Linux,2.6.32-30-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x42cd98: pan_ic+b8 0x41e5d7: vep_do_include+47 0x41e3a9: VEP_parse+ef9 0x41c14b: vfp_esi_bytes+14b 0x42223b: FetchBody+94b 0x4164d8: cnt_fetchbody+418 0x417a25: CNT_Session+315 0x42e558: wrk_do_cnt_sess+b8 0x42e9e1: wrk_thread_real+411 0x7f99434d69ca: _end+7f9942e5e752 sp = 0x7f993b129008 { fd = 11, id = 11, xid = 852536757, client = 95.108.241.252 52903, step = STP_FETCHBODY, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f993b129080 { id = "sess", {s,f,r,e} = {0x7f993b129cf0,+504,(nil),+65536}, }, http[req] = { ws = 0x7f993b129080[sess] "GET", "/trac/ticket/786?format=csv", "HTTP/1.1", "Host: www.varnish-cache.org", "Connection: Keep-Alive", "Accept: */*", "Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01", "User-Agent: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)", "From: support at search.yandex.ru", "X-Forwarded-For: 95.108.241.252, 95.108.241.252", "Accept-Encoding: gzip", }, worker = 0x7f99342ebb70 { ws = 0x7f99342ebd10 { id = "wrk", {s,f,r,e} = {0x7f99342d9b00,+1768,(nil),+65536}, }, http[bereq] = { ws = 0x7f99342ebd10[wrk] "GET", "/trac/ticket/786?format=csv", "HTTP/1.1", "Host: www.varnish-cache.org", "Accept: */*", "Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01", "User-Agent: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)", "From: support at search.yandex.ru", "X-Forwarded-For: 95.108.241.252, 95.108.241.252", "X-Varnish: 852536757", "Accept-Encoding: gzip", }, http[beresp] = { ws = 0x7f99342ebd10[wrk] "HTTP/1.1", "200", "Ok", "Date: Sat, 02 Apr 2011 11:56:16 GMT", "Server: Apache/2.2.14 (Ubuntu)", "Content-Disposition: filename=t786.csv", "Content-Length: 1121", "Content-Type: text/csv;charset=utf-8", "X-ESI: on", }, }, vcl = { srcname = { "input", "Default", }, }, obj = 0x7f9933907400 { xid = 852536757, ws = 0x7f9933907418 { id = "obj", {s,f,r,e} = {0x7f9933907618,+192,(nil),+248}, }, http[obj] = { ws = 0x7f9933907418[obj] "HTTP/1.1", "Ok", "Date: Sat, 02 Apr 2011 11:56:16 GMT", "Server: Apache/2.2.14 (Ubuntu)", "Content-Disposition: filename=t786.csv", "Content-Type: text/csv;charset=utf-8", "X-ESI: on", }, len = 0, store = { 0 { }, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 3 08:29:23 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 03 Apr 2011 08:29:23 -0000 Subject: [Varnish] #894: Missing errorhandling code in vep_do_include(), cache_esi_parse.c line 453: In-Reply-To: <042.790980b464289c7c5c421f7d6af94025@varnish-cache.org> References: <042.790980b464289c7c5c421f7d6af94025@varnish-cache.org> Message-ID: <051.78cbd796cd27d9aa3ae67f774477389d@varnish-cache.org> #894: Missing errorhandling code in vep_do_include(), cache_esi_parse.c line 453: --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: This should be fixed now. Check that you don't have an ESI tag with two src= attributes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 3 08:35:26 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 03 Apr 2011 08:35:26 -0000 Subject: [Varnish] #891: fetching gzipped data yield guru med. In-Reply-To: <042.e8aa487ad7a6b6c9abbcacf5c3ed5d5b@varnish-cache.org> References: <042.e8aa487ad7a6b6c9abbcacf5c3ed5d5b@varnish-cache.org> Message-ID: <051.72b12d066594849d06524c030fda5877@varnish-cache.org> #891: fetching gzipped data yield guru med. --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Description changed by phk: Old description: > When fetching http://www.varnish-cache.org/lists/pipermail/varnish- > misc/2011-March.txt.gz a guru error is thrown: > > Varnishlog: > > 13 ObjHeader c X-ESI: off > 13 FetchError c Incomplete Gzip data (not STREAM_END) > 13 FetchError c chunked read_error: 0 (Success) > 13 Gzip c u F - 8106 8051 80 0 0 > 15 Fetch_Body b 3 -1 1 > 15 BackendClose b project > 13 VCL_call c error > 13 VCL_return c deliver > 13 VCL_call c deliver > 13 VCL_return c deliver > 13 TxProtocol c HTTP/1.1 > 13 TxStatus c 503 > 13 TxResponse c Service Unavailable > 13 TxHeader c Server: Varnish > 13 TxHeader c Content-Type: text/html; charset=utf-8 > 13 TxHeader c Retry-After: 5 > 13 TxHeader c Content-Length: 418 > 13 TxHeader c Accept-Ranges: bytes > 13 TxHeader c Date: Fri, 01 Apr 2011 13:32:09 GMT > 13 TxHeader c X-Varnish: 958469919 > 13 TxHeader c Age: 0 > 13 TxHeader c Via: 1.1 varnish > 13 TxHeader c Connection: close > 13 Length c 418 > 13 ReqEnd c 958469919 1301664729.474170685 1301664729.481045961 > 0.000211477 0.006787777 0.000087500 > 13 SessionClose c error > 13 StatSess c 78.41.169.2 49336 0 1 1 0 0 0 256 418 > 13 SessionOpen c 78.41.169.2 49337 :80 > 13 ReqStart c 78.41.169.2 49337 958469920 New description: When fetching http://www.varnish-cache.org/lists/pipermail/varnish- misc/2011-March.txt.gz a guru error is thrown: Varnishlog: {{{ 13 ObjHeader c X-ESI: off 13 FetchError c Incomplete Gzip data (not STREAM_END) 13 FetchError c chunked read_error: 0 (Success) 13 Gzip c u F - 8106 8051 80 0 0 15 Fetch_Body b 3 -1 1 15 BackendClose b project 13 VCL_call c error 13 VCL_return c deliver 13 VCL_call c deliver 13 VCL_return c deliver 13 TxProtocol c HTTP/1.1 13 TxStatus c 503 13 TxResponse c Service Unavailable 13 TxHeader c Server: Varnish 13 TxHeader c Content-Type: text/html; charset=utf-8 13 TxHeader c Retry-After: 5 13 TxHeader c Content-Length: 418 13 TxHeader c Accept-Ranges: bytes 13 TxHeader c Date: Fri, 01 Apr 2011 13:32:09 GMT 13 TxHeader c X-Varnish: 958469919 13 TxHeader c Age: 0 13 TxHeader c Via: 1.1 varnish 13 TxHeader c Connection: close 13 Length c 418 13 ReqEnd c 958469919 1301664729.474170685 1301664729.481045961 0.000211477 0.006787777 0.000087500 13 SessionClose c error 13 StatSess c 78.41.169.2 49336 0 1 1 0 0 0 256 418 13 SessionOpen c 78.41.169.2 49337 :80 13 ReqStart c 78.41.169.2 49337 958469920 }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 3 09:13:00 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 03 Apr 2011 09:13:00 -0000 Subject: [Varnish] #891: fetching gzipped data yield guru med. In-Reply-To: <042.e8aa487ad7a6b6c9abbcacf5c3ed5d5b@varnish-cache.org> References: <042.e8aa487ad7a6b6c9abbcacf5c3ed5d5b@varnish-cache.org> Message-ID: <051.a52cc361c3a792b3ba378a8eb6b9c0c9@varnish-cache.org> #891: fetching gzipped data yield guru med. ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: I am not able to reproduce this, neither on my own machine nor running on projects. I do notice that when I try to fetch this directly from the backend, I get a load of python errors. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 4 08:32:07 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Apr 2011 08:32:07 -0000 Subject: [Varnish] #893: When running with -M one must specify a couple of other options In-Reply-To: <042.3e6fdf08f102c1d134b7ef9e9f5dcf81@varnish-cache.org> References: <042.3e6fdf08f102c1d134b7ef9e9f5dcf81@varnish-cache.org> Message-ID: <051.113ba851629ca9eab4e44319bcbfbf79@varnish-cache.org> #893: When running with -M one must specify a couple of other options --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [a36d77c39f5e7c451505ff1d77439afbf5717f84]) Allow -M without -S In general I would not advice doing this, but if you are strictly on a fortified localhost or localnet I can see the point. Fixes #893 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 4 09:07:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Apr 2011 09:07:49 -0000 Subject: [Varnish] #890: Assert error in cnt_fetch() In-Reply-To: <045.8f3c1c4316d47d2873cf4d5c515feb22@varnish-cache.org> References: <045.8f3c1c4316d47d2873cf4d5c515feb22@varnish-cache.org> Message-ID: <054.d7c0803494bd8f396110f9278a64ab4c@varnish-cache.org> #890: Assert error in cnt_fetch() ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [6e4935020849560dd09aa71fa7e8ed3971168f68]) Tighten up the management of the do_close flag. Fixes #890 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 4 10:10:00 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Apr 2011 10:10:00 -0000 Subject: [Varnish] #879: Panic message: Assert error in cnt_fetch(). In varnish 5ec2bb09c50629eafaabc9f6d6f43ae145e4f254 In-Reply-To: <043.bf223017088313af356149366e1070a7@varnish-cache.org> References: <043.bf223017088313af356149366e1070a7@varnish-cache.org> Message-ID: <052.9d5cb13bcd5928ccdbf5ee42bff2f498@varnish-cache.org> #879: Panic message: Assert error in cnt_fetch(). In varnish 5ec2bb09c50629eafaabc9f6d6f43ae145e4f254 ---------------------+------------------------------------------------------ Reporter: kdajka | Type: defect Status: closed | Priority: high Milestone: | Component: varnishd Version: trunk | Severity: critical Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: This should be fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 4 10:12:37 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Apr 2011 10:12:37 -0000 Subject: [Varnish] #891: fetching gzipped data yield guru med. In-Reply-To: <042.e8aa487ad7a6b6c9abbcacf5c3ed5d5b@varnish-cache.org> References: <042.e8aa487ad7a6b6c9abbcacf5c3ed5d5b@varnish-cache.org> Message-ID: <051.9c0d77ca86889327952fa9c0e487cbf2@varnish-cache.org> #891: fetching gzipped data yield guru med. ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by tfheen): Running curl http://localhost/lists/pipermail/varnish- misc/2011-March.txt.gz -H 'Host: www.varnish-cache.org' on project should get you the object fine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 4 18:58:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Apr 2011 18:58:06 -0000 Subject: [Varnish] #895: Varnish won't start with DNS entry in acl list that doesn't resolve Message-ID: <042.c5c5168b400f9e321cba493275954635@varnish-cache.org> #895: Varnish won't start with DNS entry in acl list that doesn't resolve -------------------+-------------------------------------------------------- Reporter: ricka | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- We are using Varnish in Amazon and using DNS names from elastic IPs in our ACL list. I noticed that while one of our servers in the ACL list was down, Varnish would not start up. I feel this is a bug as just because a name in the ACL list doesn't resolve should not keep Varnish from starting up. To test this, just put some fake entry into the acl purge section like "foo.foo.foo.foo"; and try to start up varnish. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 4 19:08:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 04 Apr 2011 19:08:04 -0000 Subject: [Varnish] #895: Varnish won't start with DNS entry in acl list that doesn't resolve In-Reply-To: <042.c5c5168b400f9e321cba493275954635@varnish-cache.org> References: <042.c5c5168b400f9e321cba493275954635@varnish-cache.org> Message-ID: <051.fc826b40eb4ef339b4b5525da3d62e9f@varnish-cache.org> #895: Varnish won't start with DNS entry in acl list that doesn't resolve -------------------------+-------------------------------------------------- Reporter: ricka | Type: defect Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: worksforme | Keywords: -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: For just this reason you can put acl entries in (...) and they will be ignored if they cannot be resolved. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 7 14:36:59 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 07 Apr 2011 14:36:59 -0000 Subject: [Varnish] #896: Strings longer than 256 characters are bad handled in VCL Message-ID: <045.4073b1bf985d9d274b5103c88701aa39@varnish-cache.org> #896: Strings longer than 256 characters are bad handled in VCL -----------------------------------+---------------------------------------- Reporter: tmagnien | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: string regexp vcl 256 | -----------------------------------+---------------------------------------- Hi, While trying my 2.1.5 VCL file on a trunk version, I got errors related to regexps : Regexp compilation error: missing ). I made some tests and found that any regexp longer that 256 characters was failing to compile. For example, the following line : {{{ if (req.http.host ~ "^(www.abc.fr|www.def.com|...)$") { --- do something --- } }}} was failing with a domain list longer than 256 characters. After investigation, it seems that the problem is in vcc_decstr function : the length of a string is calculated using an unsigned char, which may not be enough... This affects all strings in the VCL. Here is a simple match proposal : {{{ diff --git a/lib/libvcl/vcc_token.c b/lib/libvcl/vcc_token.c index 6818777..56c9672 100644 --- a/lib/libvcl/vcc_token.c +++ b/lib/libvcl/vcc_token.c @@ -350,7 +350,7 @@ static int vcc_decstr(struct vcc *tl) { char *q; - unsigned char l; + unsigned int l; assert(tl->t->tok == CSTR); l = (tl->t->e - tl->t->b) - 2; }}} Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 8 06:06:09 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 08 Apr 2011 06:06:09 -0000 Subject: [Varnish] #896: Strings longer than 256 characters are bad handled in VCL In-Reply-To: <045.4073b1bf985d9d274b5103c88701aa39@varnish-cache.org> References: <045.4073b1bf985d9d274b5103c88701aa39@varnish-cache.org> Message-ID: <054.983c220213dede3b7d0394c03eba82b8@varnish-cache.org> #896: Strings longer than 256 characters are bad handled in VCL -----------------------+---------------------------------------------------- Reporter: tmagnien | Type: defect Status: closed | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Resolution: fixed | Keywords: string regexp vcl 256 -----------------------+---------------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [a1ed842aa2a16a95acc889ab2d158c1afa087e6d]) Allow strings longer than 256 bytes Use an int rather than a char for counting. Thanks to Thierry for the diagnosis. Fixes #896 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 8 19:54:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 08 Apr 2011 19:54:20 -0000 Subject: [Varnish] #849: Session timeout while receiving POST data from client causes multiple broken backend requests In-Reply-To: <040.5f9f459ac69310e4298e91826395f877@varnish-cache.org> References: <040.5f9f459ac69310e4298e91826395f877@varnish-cache.org> Message-ID: <049.82ce9471d4c39a976dd6b1256da46cf1@varnish-cache.org> #849: Session timeout while receiving POST data from client causes multiple broken backend requests ----------------------+----------------------------------------------------- Reporter: lew | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 2.1.4 Severity: normal | Keywords: 503, post, backend write error: 11 (Resource temporarily unavailable) ----------------------+----------------------------------------------------- Comment(by nathan): I can also confirm this issue, worked around using: {{{ /* pipeline post requests trac #4124 */ if (req.request == "POST") { return(pipe); } }}} and added this: {{{ sub vcl_pipe { /* Force the connection to be closed afterwards so subsequent reqs don't use pipe */ set bereq.http.connection = "close"; } }}} Issue was happening with post file uploads from clients on a slow connection. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Apr 9 00:36:29 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 09 Apr 2011 00:36:29 -0000 Subject: [Varnish] #897: sess_mem "leak" on hyper-threaded cpu Message-ID: <045.14a2eaf653169bfcd2936fa771c688f0@varnish-cache.org> #897: sess_mem "leak" on hyper-threaded cpu -------------------------------------------------+-------------------------- Reporter: askalski | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: major Keywords: sess_mem leak n_sess race condition | -------------------------------------------------+-------------------------- There is a race condition on the n_sess statistic, which causes the counter to drift upward to ridiculously high levels: {{{ 100000 . . N struct sess_mem 867438 . . N struct sess }}} Because SES_Delete() uses the n_sess counter to decide whether to pre- allocate additional workspaces (sess_mem), this leads varnish eventually to allocate session_max of them (100000 by default), which consumes an excessive amount of memory. {{{ 97a1d998 (Poul-Henning Kamp 2010-06-17 08:47:19 +0000 220) VSC_main->n_sess++; /* XXX: locking ? */ ... 97a1d998 (Poul-Henning Kamp 2010-06-17 08:47:19 +0000 261) VSC_main->n_sess--; /* XXX: locking ? */ ... 28e7319e (Poul-Henning Kamp 2010-01-26 21:58:30 +0000 285) /* Try to precreate some ses-mem so the acceptor will not have to */ 97a1d998 (Poul-Henning Kamp 2010-06-17 08:47:19 +0000 286) if (VSC_main->n_sess_mem < VSC_main->n_sess + 10) { 28e7319e (Poul-Henning Kamp 2010-01-26 21:58:30 +0000 287) sm = ses_sm_alloc(); 28e7319e (Poul-Henning Kamp 2010-01-26 21:58:30 +0000 288) if (sm != NULL) { 28e7319e (Poul-Henning Kamp 2010-01-26 21:58:30 +0000 289) ses_setup(sm); 28e7319e (Poul-Henning Kamp 2010-01-26 21:58:30 +0000 290) Lck_Lock(&ses_mem_mtx); 28e7319e (Poul-Henning Kamp 2010-01-26 21:58:30 +0000 291) VTAILQ_INSERT_HEAD(&ses_free_mem[1 - ses_qp], sm, li 28e7319e (Poul-Henning Kamp 2010-01-26 21:58:30 +0000 292) Lck_Unlock(&ses_mem_mtx); 28e7319e (Poul-Henning Kamp 2010-01-26 21:58:30 +0000 293) } 28e7319e (Poul-Henning Kamp 2010-01-26 21:58:30 +0000 294) } }}} The bug only seems to manifest itself on machines with hyper-threaded CPU's. I was able to reproduce the issue on my laptop (Core i7, 2-core + HT = 4 virtual cores) by hitting varnish with heavy concurrency (ab -c128). {{{ # Test 1: All virtual cores active - Bug exists $ egrep 'core id' /proc/cpuinfo core id : 0 core id : 2 core id : 0 core id : 2 # Test 2: Two virtual cores disabled, HT disabled - No bug $ egrep 'core id' /proc/cpuinfo core id : 0 core id : 2 # Test 3: Two virtual cores disabled, HT enabled - Bug exists $ egrep 'core id' /proc/cpuinfo core id : 0 core id : 0 }}} Locking stat_mtx solves the problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Apr 10 03:59:23 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 10 Apr 2011 03:59:23 -0000 Subject: [Varnish] #897: sess_mem "leak" on hyper-threaded cpu In-Reply-To: <045.14a2eaf653169bfcd2936fa771c688f0@varnish-cache.org> References: <045.14a2eaf653169bfcd2936fa771c688f0@varnish-cache.org> Message-ID: <054.7c0356de1f237f2af420adea3d398caa@varnish-cache.org> #897: sess_mem "leak" on hyper-threaded cpu -------------------------------------------------+-------------------------- Reporter: askalski | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: major Keywords: sess_mem leak n_sess race condition | -------------------------------------------------+-------------------------- Comment(by askalski): I wrote a short program to test the increment/decrement race condition, and ran it on a dual socket quad core machine with HT. The program runs through a series of 2-thread trials, with each trial setting thread CPU affinities to a different pair (ex: thread A runs on cpu0, thread B runs on cpu1.) {{{ for (i = arg->iterations; i > 0; --i) { ++counter; --counter; } }}} Cpu0 and cpu8 share the same physical id and core id. {{{ $ ./racetest cpu0 vs cpu0 (1000000000 iterations)... counter drift = 2 cpu0 vs cpu1 (1000000000 iterations)... counter drift = 318 cpu0 vs cpu2 (1000000000 iterations)... counter drift = 709 cpu0 vs cpu3 (1000000000 iterations)... counter drift = 313 cpu0 vs cpu4 (1000000000 iterations)... counter drift = 690 cpu0 vs cpu5 (1000000000 iterations)... counter drift = 336 cpu0 vs cpu6 (1000000000 iterations)... counter drift = 578 cpu0 vs cpu7 (1000000000 iterations)... counter drift = 359 cpu0 vs cpu8 (1000000000 iterations)... counter drift = 13720798 cpu0 vs cpu9 (1000000000 iterations)... counter drift = 325 cpu0 vs cpu10 (1000000000 iterations)... counter drift = 581 cpu0 vs cpu11 (1000000000 iterations)... counter drift = 361 cpu0 vs cpu12 (1000000000 iterations)... counter drift = 685 cpu0 vs cpu13 (1000000000 iterations)... counter drift = 316 cpu0 vs cpu14 (1000000000 iterations)... counter drift = 637 cpu0 vs cpu15 (1000000000 iterations)... counter drift = 337 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 11 22:21:49 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 11 Apr 2011 22:21:49 -0000 Subject: [Varnish] #897: sess_mem "leak" on hyper-threaded cpu In-Reply-To: <045.14a2eaf653169bfcd2936fa771c688f0@varnish-cache.org> References: <045.14a2eaf653169bfcd2936fa771c688f0@varnish-cache.org> Message-ID: <054.1a5f4ff4f5376f197cafc50caa2b6d80@varnish-cache.org> #897: sess_mem "leak" on hyper-threaded cpu -------------------------------------------------+-------------------------- Reporter: askalski | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: major Keywords: sess_mem leak n_sess race condition | -------------------------------------------------+-------------------------- Comment(by askalski): I did some testing to figure out how this bug relates to abnormally high memory usage on production varnish servers (the original issue that got me looking into this.) I generated synthetic load against a varnishd (malloc,64M) running on my laptop (Ubuntu 10.10, kernel 2.6.35), until the n_sess_mem counter maxed out at 100000. Varnish memory usage reached 2GB resident. {{{ USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND nobody 23388 5.7 52.7 8369944 2032540 ? Sl 15:07 9:24 /usr/sbin/varnishd \ -P /var/run/varnishd.pid -a :6081 -T localhost:6082 \ -f /etc/varnish/default.vcl -S /etc/varnish/secret \ -s malloc,64M }}} I then ran a program which attached to the varnishd process via ptrace, scanned its mapped memory for sess_mem objects (magic number 0x555859c5), then tallied up the number of dirty pages belonging to each (scanning 17 pages per struct: 3288 byte sess_mem/http + 65536 bytes workspace). The scanner found all 100000 of the structs. (Note: The 64MB of SMA-cached data had all expired by the time I was able to scan the process memory; -- I used short TTL's.) {{{ sess_mem_count = 100000 dirty_pages = 504430 memory_used = 2017720kB (1970 MB) }}} The reason that so much session workspace memory was dirtied was not because of my generated request/response load (they relatively little of the workspace.) Rather, it was because the workspaces were allocated, by malloc, to memory locations that had previously been dirtied by the SMA stevedore (objects that either had expired, or were LRU-evicted.) I have a few production machines where the varnishd is using 6.5GB over what SMA was configured to use. Unfortunately, I cannot perform the same analysis on the memory of those processes, because ptrace() causes the varnish child to exit on RHEL5/2.6.18 (the poll() in CLS_Poll returns EINTR, which is interpreted as an error. Kernel 2.6.24+ is able to restart sys_poll() without userspace intervention.) Here's the post-mortem varnishstat: {{{ client_conn 3846502 362.50 Client connections accepted client_drop 96 0.01 Connection dropped, no sess/wrk client_req 3813266 359.37 Client requests received cache_hit 0 0.00 Cache hits cache_hitpass 0 0.00 Cache hits for pass cache_miss 185362 17.47 Cache misses backend_conn 1833 0.17 Backend conn. success backend_unhealthy 0 0.00 Backend conn. not attempted backend_busy 0 0.00 Backend conn. too many backend_fail 0 0.00 Backend conn. failures backend_reuse 183098 17.26 Backend conn. reuses backend_toolate 0 0.00 Backend conn. was closed backend_recycle 183527 17.30 Backend conn. recycles backend_unused 0 0.00 Backend conn. unused fetch_head 0 0.00 Fetch head fetch_length 0 0.00 Fetch with Length fetch_chunked 185362 17.47 Fetch chunked fetch_eof 0 0.00 Fetch EOF fetch_bad 0 0.00 Fetch had bad headers fetch_close 0 0.00 Fetch wanted close fetch_oldhttp 0 0.00 Fetch pre HTTP/1.1 closed fetch_zero 0 0.00 Fetch zero len fetch_failed 0 0.00 Fetch failed n_sess_mem 100000 . N struct sess_mem n_sess 100442 . N struct sess n_object 0 . N struct object n_vampireobject 0 . N unresurrected objects n_objectcore 3 . N struct objectcore n_objecthead 3 . N struct objecthead n_smf 0 . N struct smf n_smf_frag 0 . N small free smf n_smf_large 0 . N large free smf n_vbe_conn 1 . N struct vbe_conn n_wrk 10 . N worker threads n_wrk_create 502 0.05 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 1829 0.17 N worker threads limited n_wrk_queue 0 0.00 N queued work requests n_wrk_overflow 94955 8.95 N overflowed work requests n_wrk_drop 303 0.03 N dropped work requests n_backend 1 . N backends n_expired 1001 . N expired objects n_lru_nuked 184361 . N LRU nuked objects n_lru_saved 0 . N LRU saved objects n_lru_moved 1 . N LRU moved objects n_deathrow 0 . N objects on deathrow losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 3808607 358.93 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 3846406 362.49 Total Sessions s_req 3813266 359.37 Total Requests s_pipe 0 0.00 Total pipe s_pass 0 0.00 Total pass s_fetch 185362 17.47 Total fetch s_hdrbytes 877580576 82704.79 Total header bytes s_bodybytes 13580918034 1279890.49 Total body bytes sess_closed 3831452 361.08 Session Closed sess_pipeline 0 0.00 Session Pipeline sess_readahead 0 0.00 Session Read Ahead sess_linger 185362 17.47 Session Linger sess_herd 411446 38.78 Session herd shm_records 129034970 12160.49 SHM records shm_writes 16142937 1521.34 SHM writes shm_flushes 25 0.00 SHM flushes due to overflow shm_cont 1069825 100.82 SHM MTX contention shm_cycles 37 0.00 SHM cycles through buffer sm_nreq 0 0.00 allocator requests sm_nobj 0 . outstanding allocations sm_balloc 0 . bytes allocated sm_bfree 0 . bytes free sma_nreq 555085 52.31 SMA allocator requests sma_nobj 0 . SMA outstanding allocations sma_nbytes 0 . SMA outstanding bytes sma_balloc 24435160288 . SMA bytes allocated sma_bfree 24435160288 . SMA bytes free sms_nreq 3627904 341.90 SMS allocator requests sms_nobj 0 . SMS outstanding allocations sms_nbytes 0 . SMS outstanding bytes sms_balloc 1443905792 . SMS bytes allocated sms_bfree 1443905792 . SMS bytes freed backend_req 184726 17.41 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded n_purge 1 . N total active purges n_purge_add 1 0.00 N new purges added n_purge_retire 0 0.00 N old purges deleted n_purge_obj_test 0 0.00 N objects tested n_purge_re_test 0 0.00 N regexps tested against n_purge_dups 0 0.00 N duplicate purges removed hcb_nolock 183710 17.31 HCB Lookups without lock hcb_lock 185362 17.47 HCB Lookups with lock hcb_insert 185360 17.47 HCB Inserts esi_parse 0 0.00 Objects ESI parsed (unlock) esi_errors 0 0.00 ESI parse errors (unlock) accept_fail 0 0.00 Accept failures client_drop_late 207 0.02 Connection dropped late uptime 10611 1.00 Client uptime backend_retry 0 0.00 Backend conn. retry dir_dns_lookups 0 0.00 DNS director lookups dir_dns_failed 0 0.00 DNS director failed lookups dir_dns_hit 0 0.00 DNS director cached lookups hit dir_dns_cache_full 0 0.00 DNS director full dnscache fetch_1xx 0 0.00 Fetch no body (1xx) fetch_204 0 0.00 Fetch no body (204) fetch_304 0 0.00 Fetch no body (304) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 12 11:57:27 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 12 Apr 2011 11:57:27 -0000 Subject: [Varnish] #891: fetching gzipped data yield guru med. In-Reply-To: <042.e8aa487ad7a6b6c9abbcacf5c3ed5d5b@varnish-cache.org> References: <042.e8aa487ad7a6b6c9abbcacf5c3ed5d5b@varnish-cache.org> Message-ID: <051.29dddbda6cdbe1317421f7176b1d8a1d@varnish-cache.org> #891: fetching gzipped data yield guru med. ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [2c8505ba39f2e7997efd6f5eb28cfb3cbb5c3822]) VGZ_OK is acceptable at end of gzip objects. Fixes #891 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 12 22:41:35 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 12 Apr 2011 22:41:35 -0000 Subject: [Varnish] #898: varnishncsa in varnish-trunk (3.0 dev) leaks memory Message-ID: <041.1b8fc9e75051d04944bc4fc03fa7afcb@varnish-cache.org> #898: varnishncsa in varnish-trunk (3.0 dev) leaks memory -------------------------------------+-------------------------------------- Reporter: omes | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishncsa Version: trunk | Severity: normal Keywords: varnishncsa memory leak | -------------------------------------+-------------------------------------- As ay noted on IRC; varnishncsa leaks memory. I did a short session with Valgrind and it turns out clean_logline does not clean up lp->df_ttfb between each iteration. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 13 11:08:56 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 13 Apr 2011 11:08:56 -0000 Subject: [Varnish] #898: varnishncsa in varnish-trunk (3.0 dev) leaks memory In-Reply-To: <041.1b8fc9e75051d04944bc4fc03fa7afcb@varnish-cache.org> References: <041.1b8fc9e75051d04944bc4fc03fa7afcb@varnish-cache.org> Message-ID: <050.3bfba3723f98ffca4fb0646d1569792c@varnish-cache.org> #898: varnishncsa in varnish-trunk (3.0 dev) leaks memory ------------------------------+--------------------------------------------- Reporter: omes | Type: defect Status: closed | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishncsa Version: trunk | Severity: normal Resolution: fixed | Keywords: varnishncsa memory leak ------------------------------+--------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [c6a24d71bb1a0354bd94f537507852b1cbe76bac]) Fix memory leak in time to first byte handling Fixes #898 Thanks to omes and vorpal for diagnosis and patch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 13 12:42:19 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 13 Apr 2011 12:42:19 -0000 Subject: [Varnish] #899: Mixing of compressed and uncompressed content with ESI Message-ID: <045.99e9b964d95a218449d472a162a93924@varnish-cache.org> #899: Mixing of compressed and uncompressed content with ESI ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- To reproduce: Start varnish without gzip (gzip = false). Use a lot of ESI warm the cache Enable GZIP with restarting (or purging) the content Refresh some esi-elements, but not all. Result: Top page in plain-text that includes compressed data. Tested on 2c8505b (nightly build from Tues April 12th). -- Ticket URL: Varnish The Varnish HTTP Accelerator From daniel.bilik at neosystem.cz Wed Apr 13 10:15:42 2011 From: daniel.bilik at neosystem.cz (Daniel Bilik) Date: Wed, 13 Apr 2011 12:15:42 +0200 Subject: TCP_Check() compatibility for NetBSD Message-ID: <20110413121542.48140fee.daniel.bilik@neosystem.cz> Hi. Macro TCP_Check() as defined in include/libvarnish.h has two variants - for Solaris and the rest of world. There is a note that EINVAL for socket reset by the remote is a bug in Solaris. Well, I see the same on NetBSD (5.1), where this is documented behaviour (ie. not a bug) - getsockname(2) explicitly says: [EINVAL] The socket has been shut down. This causes varnishd to panic approx. once a day on my NetBSD box with messages like this: varnishd[27350]: Child (25744) Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 768: Condition(TCP_Check(i)) not true. errno = 22 (Invalid argument) It can be fixed by simply extending the condition for macro definition, see attached patch. -- Daniel Bilik neosystem.cz -------------- next part -------------- A non-text attachment was scrubbed... Name: varnish-2.1.5.patch Type: text/x-diff Size: 644 bytes Desc: not available URL: From varnish-bugs at varnish-cache.org Wed Apr 13 13:02:44 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 13 Apr 2011 13:02:44 -0000 Subject: [Varnish] #868: varnishncsa generates wrong log formats when Authorization header is sent empty In-Reply-To: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> References: <042.bbd3c6763d239b5c8604900d62141607@varnish-cache.org> Message-ID: <051.b7de13384af7500dbe43a78f91e5f44c@varnish-cache.org> #868: varnishncsa generates wrong log formats when Authorization header is sent empty -------------------------+-------------------------------------------------- Reporter: jdzst | Owner: tfheen Type: defect | Status: closed Priority: low | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishncsa | -------------------------+-------------------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [59bab9f19ae226fe0c553a202b66d630cf5f32ef]) Fix formatting of broken Authorization headers in varnishncsa varnishncsa would format an authorization headers like Authorization: Basic as 127.0.0.1 - [?] rather than 127.0.0.1 - - [?] Fixes #868 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 13 13:24:14 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 13 Apr 2011 13:24:14 -0000 Subject: [Varnish] #900: The \" escape does not work. Message-ID: <045.fcd0302b4f0ba87497f2e36884ddaa32@varnish-cache.org> #900: The \" escape does not work. ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- SSIA. \" barfed %22 too. Ended up with long-strings (This was for bans, but I can't imagine that's relevant). Our workaround: {{{ ban({"obj.http.cache-control ~ group=""} + req.url + {"""}); }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 13 16:52:42 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 13 Apr 2011 16:52:42 -0000 Subject: [Varnish] #897: sess_mem "leak" on hyper-threaded cpu In-Reply-To: <045.14a2eaf653169bfcd2936fa771c688f0@varnish-cache.org> References: <045.14a2eaf653169bfcd2936fa771c688f0@varnish-cache.org> Message-ID: <054.6795538a50f9d74b03fa8163a9e14d00@varnish-cache.org> #897: sess_mem "leak" on hyper-threaded cpu -------------------------------------------------+-------------------------- Reporter: askalski | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: major Keywords: sess_mem leak n_sess race condition | -------------------------------------------------+-------------------------- Comment(by askalski): Attached is a patch that solves the race condition without locking in the acceptor thread (thanks to Mithrandir for pointing that out.) It does so by splitting the "n_sess" statistic into "n_sess_new" (no mutex), and "n_sess_delete" (mutex, worker). The worker threads then calculate the number of outstanding sessions by subtracting. I didn't bother checking for counter overflow, because it would take 1000 years at a rate of 500+ million sessions per second for that to happen. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 14 00:24:55 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Apr 2011 00:24:55 -0000 Subject: [Varnish] #901: Erros on http://www.varnish-cache.org/trac/wiki/VCLExampleRedirectInVCL Message-ID: <042.4fc072e4d3de6e89237dfa39b2aa66a5@varnish-cache.org> #901: Erros on http://www.varnish-cache.org/trac/wiki/VCLExampleRedirectInVCL -------------------+-------------------------------------------------------- Reporter: yonas | Type: documentation Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- http://www.varnish-cache.org/trac/wiki/VCLExampleRedirectInVCL Need to change all occurrences of "deliver;" to "return(deliver);" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 14 11:05:19 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 14 Apr 2011 11:05:19 -0000 Subject: [Varnish] #901: Erros on http://www.varnish-cache.org/trac/wiki/VCLExampleRedirectInVCL In-Reply-To: <042.4fc072e4d3de6e89237dfa39b2aa66a5@varnish-cache.org> References: <042.4fc072e4d3de6e89237dfa39b2aa66a5@varnish-cache.org> Message-ID: <051.82e79ceef05838153fc0118215800769@varnish-cache.org> #901: Erros on http://www.varnish-cache.org/trac/wiki/VCLExampleRedirectInVCL ---------------------+------------------------------------------------------ Reporter: yonas | Type: documentation Status: closed | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Thanks, fixed now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 15 06:17:14 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Apr 2011 06:17:14 -0000 Subject: [Varnish] #839: Varnish fails to start on boot for some FreeBSD machines In-Reply-To: <054.631b323b9c05fe09e2b12eed8c556e4e@varnish-cache.org> References: <054.631b323b9c05fe09e2b12eed8c556e4e@varnish-cache.org> Message-ID: <063.6304297d480dd640a4339081379ef3cb@varnish-cache.org> #839: Varnish fails to start on boot for some FreeBSD machines -------------------------------+-------------------------------------------- Reporter: james.m.henderson | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Later Component: packaging | Version: trunk Severity: normal | Resolution: worksforme Keywords: | -------------------------------+-------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => worksforme Comment: No response from submitter; time out ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 15 11:27:36 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Apr 2011 11:27:36 -0000 Subject: [Varnish] #883: Memory leaking In-Reply-To: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> References: <042.b69c0f6805f4b0a29b094b703448dcdc@varnish-cache.org> Message-ID: <051.773dac18dc7aed1329a90070f645f614@varnish-cache.org> #883: Memory leaking ----------------------+----------------------------------------------------- Reporter: arety | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.5 Severity: normal | Keywords: memory usage ----------------------+----------------------------------------------------- Comment(by kristian): You can mail me the data if you like (kristian at varnish-software.com), though I'll keep this ticket updated (no sensitive data added, of course). We haven't seen any reports for 2.1.4/2.1.5 leakage, so it's a bit strange. The varnishstat -1 from the 2.1.4 rig will still be useful, btw. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 15 11:35:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Apr 2011 11:35:52 -0000 Subject: [Varnish] #755: Incorrect escaping of purges In-Reply-To: <045.170f5c50b281940c10f9c218b24bde03@varnish-cache.org> References: <045.170f5c50b281940c10f9c218b24bde03@varnish-cache.org> Message-ID: <054.90f706f5bb0509507538c1c4e0568e06@varnish-cache.org> #755: Incorrect escaping of purges ----------------------+----------------------------------------------------- Reporter: kristian | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Comment(by kristian): Dear Diary, It's still there! Well, except now it's called bans. I'll take a poke at it when I get the time. - Kristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 15 11:36:09 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Apr 2011 11:36:09 -0000 Subject: [Varnish] #755: Incorrect escaping of purges In-Reply-To: <045.170f5c50b281940c10f9c218b24bde03@varnish-cache.org> References: <045.170f5c50b281940c10f9c218b24bde03@varnish-cache.org> Message-ID: <054.0d24ed2650949232c9059322c18d015e@varnish-cache.org> #755: Incorrect escaping of purges ----------------------+----------------------------------------------------- Reporter: kristian | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Changes (by kristian): * milestone: Varnish 3.0 dev => Comment: Not really a blocker for 3.0, if you ask me. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 15 11:51:21 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Apr 2011 11:51:21 -0000 Subject: [Varnish] #827: varnish child died in object_cmp In-Reply-To: <043.3b98080c99e4f9f35543ee1216c618e7@varnish-cache.org> References: <043.3b98080c99e4f9f35543ee1216c618e7@varnish-cache.org> Message-ID: <052.ed616c1769870dcba53f62f7080e2a86@varnish-cache.org> #827: varnish child died in object_cmp ----------------------+----------------------------------------------------- Reporter: dmyaho | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.1.3 Severity: normal | Keywords: Assert error ----------------------+----------------------------------------------------- Changes (by kristian): * milestone: Varnish 3.0 dev => Comment: What you're looking at is memory corruption of some sort. Until we get more reports, there's little we can/will do on a 2.1.3 release on 32-bit. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 15 13:15:23 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 15 Apr 2011 13:15:23 -0000 Subject: [Varnish] #825: varnish.spec dependency 'initscripts' not valid for SuSE/SLES In-Reply-To: <040.fc90388613640974d9c37e4c5d2c703f@varnish-cache.org> References: <040.fc90388613640974d9c37e4c5d2c703f@varnish-cache.org> Message-ID: <049.f735ecf8495e69fa201ef0966e881cec@varnish-cache.org> #825: varnish.spec dependency 'initscripts' not valid for SuSE/SLES ---------------------+------------------------------------------------------ Reporter: pom | Type: defect Status: closed | Priority: normal Milestone: Later | Component: packaging Version: trunk | Severity: minor Resolution: fixed | Keywords: rpmbuild SUSE SLES ---------------------+------------------------------------------------------ Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [d75d6d2b8c8725b965216d78eec01afe5035432b]) Don't require initscripts on SUSE Fixes #825 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 18 07:57:52 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Apr 2011 07:57:52 -0000 Subject: [Varnish] #902: http_CollectHdr() can fail on consecuitive headers Message-ID: <040.7b82550afe51caedc0257309b80671c7@varnish-cache.org> #902: http_CollectHdr() can fail on consecuitive headers --------------------+------------------------------------------------------- Reporter: phk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Bug, this ticket her to allocate number for regression test. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 18 08:09:46 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Apr 2011 08:09:46 -0000 Subject: [Varnish] #902: http_CollectHdr() can fail on consecuitive headers In-Reply-To: <040.7b82550afe51caedc0257309b80671c7@varnish-cache.org> References: <040.7b82550afe51caedc0257309b80671c7@varnish-cache.org> Message-ID: <049.4518e2ed2e6ee31795b4010d19911e02@varnish-cache.org> #902: http_CollectHdr() can fail on consecuitive headers --------------------+------------------------------------------------------- Reporter: phk | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [9ee99237d6a3d6b584d6b2e5af32006a2af06284]) Fix a problem in http_CollectHdr() where it would overlook the second of two headers in a row. Fixes #902 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 18 09:58:28 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Apr 2011 09:58:28 -0000 Subject: [Varnish] #903: Segmentation fault in varnish 3b4859455803b606107c07b25b784372d5665a1f Message-ID: <043.04455f1c56c4d22970fbcd4e327fc60b@varnish-cache.org> #903: Segmentation fault in varnish 3b4859455803b606107c07b25b784372d5665a1f --------------------+------------------------------------------------------- Reporter: kdajka | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: blocker Keywords: | --------------------+------------------------------------------------------- Hi, I'm seeing segmentation fault in trunk 3b4859455803b606107c07b25b784372d5665a1f. {{{ /usr/local/inp/varnish/sbin/varnishd -P /var/tmp/foo.bar_varnishd.pid -a 193.42.231.45:8084 -i foo.bar_varnishic06 -n foo.bar_varnishic06 -f /exp/config/varnish//foo.bar/foo.bar.vcl -T 193.42.231.45:2084 -h classic,20011 -p thread_pools=4 -p ban_lurker_sleep=0.1 -w 200,4000,2 -t 0 -s malloc,3G -d }}} {{{ $file /usr/local/inp/varnish_3b4859455803b606107c07b25b784372d5665a1f_debug/sbin/varnishd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped }}} {{{ $ ulimit -c unlimited }}} {{{ $ gdb -c /usr/local/inp/varnish_3b4859455803b606107c07b25b784372d5665a1f_debug/var/varnish/foo.bar_varnishic06/core.20615 /usr/local/inp/varnish_3b4859455803b606107c07b25b784372d5665a1f_debug/sbin/varnishd ... Program terminated with signal 11, Segmentation fault. ... (gdb) bt #0 0x0000000000418298 in cnt_error (sp=0x7f350ab68008) at cache_center.c:420 #1 0x000000000041be90 in CNT_Session (sp=0x7f350ab68008) at steps.h:47 #2 0x0000000000436853 in wrk_do_cnt_sess (w=0x7f3581082e10, priv=0x7f350ab68008) at cache_pool.c:303 #3 0x00000000004360be in wrk_thread_real (qp=0x7f3670d0e290, shm_workspace=8192, sess_workspace=65536, nhttp=64, http_space=1160, siov=128) at cache_pool.c:187 #4 0x00000000004364bf in wrk_thread (priv=0x7f3670d0e290) at cache_pool.c:233 #5 0x00007f36715a0fc7 in start_thread () from /lib/libpthread.so.0 #6 0x00007f367131664d in clone () from /lib/libc.so.6 #7 0x0000000000000000 in ?? () (gdb) print *sp $1 = {magic = 741317722, fd = 172, id = 172, xid = 1580802727, restarts = 0, esi_level = 0, disable_esi = 0, hash_ignore_busy = 0 '\0', hash_always_miss = 0 '\0', wrk = 0x7f3581082e10, sockaddrlen = 16, mysockaddrlen = 128, sockaddr = 0x7f350ab682e0, mysockaddr = 0x7f350ab68360, mylsock = 0x7f3670d20eb0, addr = 0x7f350ab68cf0 "188.165.144.187", port = 0x7f350ab68d00 "48411", client_identity = 0x0, doclose = 0x4707b9 "not HTTP/1.1", http = 0x7f350ab683e0, http0 = 0x7f350ab68868, ws = {{magic = 905626964, id = 0x47215e "sess", s = 0x7f350ab68cf0 "188.165.144.187", f = 0x7f350ab68e10 "te", r = 0x0, e = 0x7f350ab78cf0 "", overflow = 0}}, ws_ses = 0x7f350ab68d08 "GET", ws_req = 0x7f350ab68dd8 "188.165.144.187", digest = "\025\001W?b ?\2241?\203??I?6???\022\225i\226\t\027?\206q|??i", htc = {{magic = 1041886673, fd = 172, maxbytes = 32768, maxhdr = 2048, ws = 0x7f350ab68080, rxbuf = {b = 0x7f350ab68d08 "GET", e = 0x7f350ab68dd3 ""}, pipeline = { b = 0x0, e = 0x0}}}, t_open = 1302868999.9459498, t_req = 1302868999.9459774, t_resp = nan(0x8000000000000), t_end = 1302868999.9459498, exp = {ttl = -1, grace = 30, keep = -1}, step = STP_ERROR, cur_method = 0, handling = 1, sendbody = 1 '\001', wantbody = 1 '\001', err_code = 503, err_reason = 0x0, list = {vtqe_next = 0x0, vtqe_prev = 0x0}, director = 0x0, vbc = 0x0, obj = 0x0, objcore = 0x0, vcl = 0x7f3670d065e8, hash_objhead = 0x0, mem = 0x7f350ab68000, workreq = {list = {vtqe_next = 0x0, vtqe_prev = 0x0}, func = 0x436729 , priv = 0x7f350ab68008}, acct_tmp = {first = 0, sess = 1, req = 1, pipe = 0, pass = 1, 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 = 1302868999.9459498, sess = 0, req = 0, pipe = 0, pass = 0, fetch = 0, hdrbytes = 0, bodybytes = 0}, ev = {events = 0, data = { ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}} }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 18 10:45:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Apr 2011 10:45:06 -0000 Subject: [Varnish] #904: Panic message: Assert error in VGZ_Ibuf(), cache_gzip.c line 225 Message-ID: <043.a55bb5c7e0f6d45c0cf2204f3eded535@varnish-cache.org> #904: Panic message: Assert error in VGZ_Ibuf(), cache_gzip.c line 225 ------------------------------------------------------+--------------------- Reporter: kdajka | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: major Keywords: 3b4859455803b606107c07b25b784372d5665a1f | ------------------------------------------------------+--------------------- Hi, I'm seeing Panic message: Assert error in VGZ_Ibuf(), cache_gzip.c in trunk 3b4859455803b606107c07b25b784372d5665a1f. [[BR]] I think problem is reproducible when backend gzips bitmap files and client asks for ungzipped version. I had few similar panics (all with *.bmp files) until I stopped gzipping bmps on backend (which was unnecessary btw) {{{ /usr/local/inp/varnish/sbin/varnishd -P /var/tmp/foo.bar_varnishd.pid -a 193.42.231.45:8084 -i foo.bar_varnishic06 -n foo.bar_varnishic06 -f /exp/config/varnish//foo.bar/foo.bar.vcl -T 193.42.231.45:2084 -h classic,20011 -p thread_pools=4 -p ban_lurker_sleep=0.1 -w 200,4000,2 -t 0 -s malloc,3G -d }}} {{{ $file /usr/local/inp/varnish_3b4859455803b606107c07b25b784372d5665a1f_debug/sbin/varnishd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped }}} {{{ $ ulimit -c unlimited }}} {{{ /usr/local/inp/varnish/sbin/varnishd -P /var/tmp/foo.bar_varnishd.pid -a 193.42.231.45:8084 -i foo.bar_varnishic06 -n foo.bar_varnishic06 -f /exp/config/varnish//foo.bar/foo.bar.vcl -T 193.42.231.45:2084 -h classic,20011 -p thread_pools=4 -p ban_lurker_sleep=0.1 -w 200,4000,2 -t 0 -s malloc,3G -d ... start child (11512) Started 200 0 Child (11512) said Not running as root, no priv-sep Child (11512) said Child starts Child (11512) died signal=6 Child (11512) Panic message: Assert error in VGZ_Ibuf(), cache_gzip.c line 225: Condition((vg->vz.avail_in) == 0) not true. thread = (cache-worker) ident = Linux,2.6.26-2-amd64,x86_64,-smalloc,-smalloc,-hclassic,epoll Backtrace: 0x4349c0: pan_backtrace+16 0x434c29: pan_ic+164 0x429596: VGZ_Ibuf+bb 0x429d1c: VGZ_WrwGunzip+d4 0x4387ba: res_WriteGunzipObj+26e 0x438dad: RES_WriteObj+26b 0x417ae3: cnt_deliver+30 0x41be5d: CNT_Session+647 0x436853: wrk_do_cnt_sess+12a 0x4360be: wrk_thread_real+851 sp = 0x7f5e35381008 { fd = 154, id = 154, xid = 1697784078, client = 95.108.158.243 21561, step = STP_DELIVER, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 ws = 0x7f5e35381080 { id = "sess", {s,f,r,e} = {0x7f5e35381cf0,+400,(nil),+65536}, }, http[req] = { ws = 0x7f5e35381080[sess] "GET", "/resource/HARIBO_Soft_Barchen.bmp", "HTTP/1.1", "Host: foo.bar", "Connection: Keep-Alive", "Accept: image/jpeg, image/pjpeg, image/png, image/gif", "User-Agent: Mozilla/5.0 (compatible; YandexImages/3.0; +http://yandex.com/bots)", "From: support at search.yandex.ru", "x-real-forwarded-for: 95.108.158.243", "X-Forwarded-For: 95.108.158.243", }, worker = 0x7f5e878e8e10 { ws = 0x7f5e878e8fb0 { id = "wrk", {s,f,r,e} = {0x7f5e878d6d20,+3248,(nil),+65536}, }, http[resp] = { ws = 0x7f5e878e8fb0[wrk] "HTTP/1.1", "200", "OK", "Server: Apache", "Cache-Control: PUBLIC, max-age=0, must-revalidate", "Last-Modified: Thu, 13 Jan 2011 00:02:57 GMT", "Expires: Thu, 01 Jan 1970 00:00:00 GMT", "Content-Type: image/bmp", "Vary: Accept-Encoding", "Transfer-Encoding: chunked", "Date: Fri, 15 Apr 2011 09:05:06 GMT", "X-Varnish: 1697784078", "Age: 0", "Connection: keep-alive", "X-Cache: MISS", "Via: foo.bar_varnishic06", }, }, vcl = { srcname = { "input", "Default", "/exp/config/varnish/foo.bar/backends_foo.bar.vcl", }, }, obj = 0x7f5b96514000 { xid = 1697784078, ws = 0x7f5b96514018 { id = "obj", {s,f,r,e} = {0x7f5b96514270,+424,(nil),+448}, }, http[obj] = { ws = 0x7f5b96514018[obj] "HTTP/1.1", "OK", "Date: Fri, 15 Apr 2011 09:05:06 GMT", "Server: Apache", "Cache-Control: PUBLIC, max-age=0, must-revalidate", "Last-Modified: Thu, 13 Jan 2011 00:02:57 GMT", "Expires: Thu, 01 Jan 1970 00:00:00 GMT", "Content-Encoding: gzip", "Content-Type: image/bmp", "x-url: /resource/HARIBO_Soft_Barchen.bmp", "x-host: foo.bar", "Vary: Accept-Encoding", "Content-Length: 333104", }, len = 333104, store = { 131072 { 1f 8b 08 00 00 00 00 00 00 03 a4 fd 07 74 1c 57 |.............t.W| 9a 26 0a f6 bc 73 76 76 76 de 6c f7 6b 5f 5d b6 |.&...svvv.l.k_].| ab aa 4d a9 54 92 4a 86 de 93 f0 de 7b 8f cc 84 |..M.T.J.....{...| 4f 00 99 48 78 ef bd f7 de 7b 0f 10 00 09 7a 6f |O..Hx....{....zo| [131008 more] }, 131072 { a7 cf 85 e4 43 b0 95 83 b6 09 7b d8 b7 21 c6 3d |....C.....{..!.=| a7 ff c3 85 8a 7c 55 55 ff 1c f8 d4 f6 3b c0 81 |.....|UU.....;..| f4 f7 00 59 3a 68 95 cd 52 cc a6 29 a0 16 f7 28 |...Y:h..R..)...(| 87 e4 4e 50 21 84 b2 61 94 8f d8 d4 9b 67 43 42 |..NP!..a.....gCB| [131008 more] }, 70960 { ad 52 b7 6b f2 d0 26 f8 4f 74 a7 18 0d 2f ca b4 |.R.k..&.Ot.../..| 6c 94 42 f6 3c 5d 9e bd 4b 06 ee 78 a3 76 e6 84 |l.B.<]..K..x.v..| c4 91 0f 58 b2 58 53 52 20 27 b1 25 3f 1e 0c 1f |...X.XSR '.%?...| ae 4e 7d 42 5b 61 72 87 01 e2 91 86 64 6f fa 3e |.N}B[ar.....do.>| [70896 more] }, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Apr 18 14:58:39 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Apr 2011 14:58:39 -0000 Subject: [Varnish] #905: Modification of multi-line beresp or resp header mangles value Message-ID: <042.3754aa30b0723f9ee2df26331b4df940@varnish-cache.org> #905: Modification of multi-line beresp or resp header mangles value -------------------+-------------------------------------------------------- Reporter: lrowe | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 2.1.5 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- In order to work around an nginx bug (nginx is in front of varnish), I would like to merge the multiline Vary header from my backend into a single line. Attempting this with the following minimal vcl {{{ backend default { .host = "127.0.0.1"; .port = "8080"; } sub vcl_fetch { set beresp.http.Vary = regsuball(beresp.http.Vary, ",\s+", ", "); } }}} Results in the multiple lines of the header being split up, as can be seen in the varnishlog excerpts (full log attached): {{{ 9 RxProtocol b HTTP/1.1 9 RxStatus b 200 9 RxResponse b OK 9 RxHeader b Server: Zope/(2.13.6, python 2.6.6, darwin) ZServer/1.1 9 RxHeader b Date: Mon, 18 Apr 2011 14:44:14 GMT 9 RxHeader b Content-Length: 2701 9 RxHeader b X-Cache-Operation: plone.app.caching.moderateCaching 9 RxHeader b Content-Language: 9 RxHeader b Content-Encoding: gzip 9 RxHeader b Expires: Fri, 20 Apr 2001 14:44:14 GMT 9 RxHeader b Vary: X-Anonymous, 9 RxHeader b Accept-Encoding 9 RxHeader b ETag: "||373||1|Sunburst Theme|0|0|1302790083.61" 9 RxHeader b Cache-Control: max-age=0, s-maxage=3600, must-revalidate 9 RxHeader b X-Cache-Rule: plone.content.folderView 9 RxHeader b Content-Type: text/html;charset=utf-8 ... 7 VCL_call c fetch 7 VCL_return c deliver 7 ObjProtocol c HTTP/1.1 7 ObjStatus c 200 7 ObjResponse c OK 7 ObjHeader c Server: Zope/(2.13.6, python 2.6.6, darwin) ZServer/1.1 7 ObjHeader c Date: Mon, 18 Apr 2011 14:44:14 GMT 7 ObjHeader c X-Cache-Operation: plone.app.caching.moderateCaching 7 ObjHeader c Content-Language: 7 ObjHeader c Content-Encoding: gzip 7 ObjHeader c Expires: Fri, 20 Apr 2001 14:44:14 GMT 7 ObjHeader c Accept-Encoding 7 ObjHeader c ETag: "||373||1|Sunburst Theme|0|0|1302790083.61" 7 ObjHeader c Cache-Control: max-age=0, s-maxage=3600, must-revalidate 7 ObjHeader c X-Cache-Rule: plone.content.folderView 7 ObjHeader c Content-Type: text/html;charset=utf-8 7 ObjHeader c Vary: X-Anonymous, }}} The same effect is seen when using: {{{ sub vcl_deliver { set resp.http.Vary = regsuball(resp.http.Vary, ",\s+", ", "); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From kbrownfield at google.com Mon Apr 18 19:53:49 2011 From: kbrownfield at google.com (Ken Brownfield) Date: Mon, 18 Apr 2011 12:53:49 -0700 Subject: [Varnish] #905: Modification of multi-line beresp or resp header mangles value In-Reply-To: <042.3754aa30b0723f9ee2df26331b4df940@varnish-cache.org> References: <042.3754aa30b0723f9ee2df26331b4df940@varnish-cache.org> Message-ID: Your back-end is emitting this broken header, but you seem to expect both nginx and Varnish to understand it. This isn't a bug in nginx, this is an unfixable behavior problem of your backend, IMHO. Also, your regex is seemingly replacing ",\s+" with ", ", which is essentially a NOP. The regex does not (and cannot) address the spurious newline -- NL is not in \s, and the regex is not multi-line. Finally, this is definitely not a Varnish bug. Perhaps the code in your app or plone is manually adding the errant NL. -- kb On Mon, Apr 18, 2011 at 07:58, Varnish wrote: > 9 RxHeader b Vary: X-Anonymous, > 9 RxHeader b Accept-Encoding > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at varnish-cache.org Mon Apr 18 22:17:20 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 18 Apr 2011 22:17:20 -0000 Subject: [Varnish] #906: Varnish 2.1.x packages for el5 are not signed Message-ID: <041.4aa6d7c420932c17d0e884dba43bd18d@varnish-cache.org> #906: Varnish 2.1.x packages for el5 are not signed ------------------------------+--------------------------------------------- Reporter: maxp | Type: defect Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: major Keywords: gpg rpm security | ------------------------------+--------------------------------------------- Of the packages available at http://repo.varnish- cache.org/redhat/varnish-2.1/el5/ none are signed with a gpg key. Signing packages with a gpg key is an easy and effective way to prevent malicious parties from subverting your packages for the distribution of malware. Without signed packages repo.varnish-cache.org/redhat/ is worse than useless for the distribution of packages for production, it is in fact a gaping security hole. This issue of broken key verification was previously broached here: http://www.varnish-cache.org/trac/ticket/810 The apparent 'solution' of removing GPG verification is apparent based on the difference between: http://repo.varnish-cache.org/redhat/el5/noarch/varnish- release-2.1-2.noarch.rpm and http://repo.varnish-cache.org/redhat/el5/noarch/varnish- release-2.1-1.noarch.rpm Wherein a GPG key is no longer distributed and gpgcheck is set to 0 (where it previously was 1) in the varnish-2.1.repo definition. I have checked out the latest revision of the only apparent repository on git.varnish-cache.org and cannot find any script which defines the behavior of your rpm building system and thus cannot submit a patch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 20 16:22:00 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 20 Apr 2011 16:22:00 -0000 Subject: [Varnish] #907: Varnish alternates between 200 and 304 responses with ETags Message-ID: <042.9c4ec3d6f94dfb542b47fb0f16bc4c24@varnish-cache.org> #907: Varnish alternates between 200 and 304 responses with ETags -------------------+-------------------------------------------------------- Reporter: lrowe | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 2.1.5 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- I'm using Varnish 2.1.5 with a backend that produces ETags. This almost works fine, except I see page loads alternating between 304 Not Modified and 200 OK responses. This seems to be due to the 304 Not Modified response inserting a Last-Modified header in the response. On the next page load this causes the browser to send an If-Modified-Since header in addition to the If-None-Match header. Varnish then responds with a 200 OK rather then a 304 Not Modified. VCL: {{{ backend backend_0 { .host = "127.0.0.1"; .port = "8080"; } }}} When I add the following VCL to remove the If-Modified-Since header, I always get a 304 Not Modified response: {{{ sub vcl_recv { if (req.http.If-None-Match) { remove req.http.If-Modified-Since; } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Apr 26 07:40:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 26 Apr 2011 07:40:04 -0000 Subject: [Varnish] #906: Varnish 2.1.x packages for el5 are not signed In-Reply-To: <041.4aa6d7c420932c17d0e884dba43bd18d@varnish-cache.org> References: <041.4aa6d7c420932c17d0e884dba43bd18d@varnish-cache.org> Message-ID: <050.589a328c5218f983fc83d016c996d47c@varnish-cache.org> #906: Varnish 2.1.x packages for el5 are not signed ------------------------------+--------------------------------------------- Reporter: maxp | Type: defect Status: new | Priority: high Milestone: | Component: build Version: trunk | Severity: major Keywords: gpg rpm security | ------------------------------+--------------------------------------------- Comment(by tfheen): The reason for the RPMs being unsigned is signing them breaks RPM and corrupts the RPM database. Now, this is of course a bug in, but rather than breaking machines we distribute unsigned packages. I'm unlikely to change this, but will leave the bug open for now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Apr 27 06:15:13 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 27 Apr 2011 06:15:13 -0000 Subject: [Varnish] #908: beresp.cacheable doesn't consider HTTP status 307 to be cacheable Message-ID: <046.30ca96fa862f0e17f0d65adc58e171b7@varnish-cache.org> #908: beresp.cacheable doesn't consider HTTP status 307 to be cacheable ---------------------------+------------------------------------------------ Reporter: thiagocsf | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 2.1.5 | Severity: normal Keywords: cacheable 307 | ---------------------------+------------------------------------------------ Varnish variable beresp.cacheable doesn't consider 307 responses to be cacheable. This is by design and documented: http://www.varnish- cache.org/docs/2.1/reference/vcl.html?highlight=cacheable#variables However, RFC 2616 does state that such requests are cacheable: http://tools.ietf.org/html/rfc2616#page-65 (..) "This response is only cacheable if indicated by a Cache-Control or Expires header field." ---- Live example available below. {{{ $ curl -I http://static.westfield.com/img_resized/retailer/logos/franklins_172x133.gif HTTP/1.1 307 Temporary Redirect Cache-Control: public, max-age=600 Location: http://static.westfield.com/img_resized/retailer/logos/default- logo-image_172x133.gif Status: 307 Content-Type: text/html; charset=utf-8 Server: Apache Content-Length: 151 Date: Wed, 27 Apr 2011 06:12:15 GMT Age: 0 Via: 1.1 varnish Connection: keep-alive }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 28 10:20:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 28 Apr 2011 10:20:08 -0000 Subject: [Varnish] #771: caching large objects In-Reply-To: <044.72d043cecc110889e5fa91f9bd2e6400@varnish-cache.org> References: <044.72d043cecc110889e5fa91f9bd2e6400@varnish-cache.org> Message-ID: <053.8399f5b01eaa70cdbc98f4f13f5697a9@varnish-cache.org> #771: caching large objects ----------------------+----------------------------------------------------- Reporter: bcakipp | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => fixed Comment: This works with recent versions. Feel free to re-open if that's not the case. (Recent versions: post-easter git) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Apr 28 21:15:12 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 28 Apr 2011 21:15:12 -0000 Subject: [Varnish] #880: Error when pushing 5G objects through Varnish In-Reply-To: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> References: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> Message-ID: <051.b579b17111805b569812423e5de2bef3@varnish-cache.org> #880: Error when pushing 5G objects through Varnish --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment(by rrauenza): Could this be the same issue? The file I am retrieving is 2,525,396,992 bytes My varnish cache file is 107,374,182,400 bytes /usr/sbin/varnishd -P /var/run/varnish.pid -a :6081 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,120 -u varnish -g varnish -S /etc/varnish/secret -s file,/varnish/varnish_storage.bin,100G Apr 28 13:53:21 rich-fedora abrtd: Directory 'ccpp-1304024000-24054' creation detected Apr 28 13:53:21 rich-fedora varnishd[24053]: Child (24054) died signal=6 (core dumped) Apr 28 13:53:21 rich-fedora varnishd[24053]: Child (24054) Panic message: Assert error in STV_alloc(), stevedore.c line 192:#012 Condition((st) != NULL) not true.#012thread = (cache-worker)#012ident = Linux,2.6.35.11-83.fc14.x86_64,x86_64,-sfile,-hcritbit,epoll#012Backtrace:#012 0x424c68: /usr/sbin/varnishd() [0x424c68]#012 0x43afc5: /usr/sbin/varnishd(STV_alloc+0x165) [0x43afc5]#012 0x41beb4: /usr/sbin/varnishd(FetchBody+0x314) [0x41beb4]#012 0x414230: /usr/sbin/varnishd(CNT_Session+0x1ea0) [0x414230]#012 0x425ed8: /usr/sbin/varnishd() [0x425ed8]#012 0x426827: /usr/sbin/varnishd() [0x426827]#012 0x3e8fa06ccb: /lib64/libpthread.so.0() [0x3e8fa06ccb]#012 0x3e8f6e0c2d: /lib64/libc.so.6(clone+0x6d) [0x3e8f6e0c2d]#012sp = 0x7fc5c6417008 {#012 fd = 13, id = 13, xid = 963382896,#012 client = 10.20.98.81 62220,#012 step = STP_FETCH,#012 handling = deliver,#012 err_code = 200, err_reason = (null),#012 restarts = 0, esis = 0#012 ws = 0x7fc5c6417080 { #012 id = "sess",#012 {s,f,r,e} = {0x7fc5c6417cd8,+272,(nil),+65536},#012 },#012 http[req] = {#012 ws = 0x7fc5c6417080[sess]#012 "GET",#012 "/build/storage19/release/bora-403981/publish/VMware-VIMSetup- all-5.0.0-403981.iso",#012 "HTTP/1.0",#012 "User-Agent: Wget/1.12 (linux-gnu)",#012 "Accept: */*",#012 "Host: rich- fedora:6081",#012 "Connection: Keep-Alive",#012 "X-Forwarded- For: 10.20.98.81",#012 },#012 worker = 0x7fc5c63febc0 {#012 ws = 0x7fc5c63fed40 { #012 id = "wrk",#012 {s,f,r,e} = {0x7fc5c63ecb70,+2920,(nil),+65536},#012 },#012 http[bereq] = {#012 ws = 0x7fc5c63fed40[wrk]#012 "GET",#012 ".iso",#012 "HTTP/1.1",#012 "User-Agent: Wget/1.12 (linux-gnu)",#012 "Accept: */*",#012 "Host: rich- fedora:6081",#012 "X-Forwarded-For: 10.20.98.81",#012 "X-Varnish: 963382896",#012 },#012 http[beresp] = {#012 ws = 0x7fc5c63fed40[wrk]#012 "HTTP/1.1",#012 Apr 28 13:53:21 rich-fedora varnishd[24053]: child (24074) Started Apr 28 13:53:21 rich-fedora varnishd[24053]: Child (24074) said Apr 28 13:53:21 rich-fedora varnishd[24053]: Child (24074) said Child starts Apr 28 13:53:21 rich-fedora varnishd[24053]: Child (24074) said managed to mmap 107374182400 bytes of 107374182400 My cache is essentially empty. I retrieved a small text file (succesfully) and this iso (crashes). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 29 08:21:04 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 29 Apr 2011 08:21:04 -0000 Subject: [Varnish] #880: Error when pushing 5G objects through Varnish In-Reply-To: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> References: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> Message-ID: <051.c287ada7aa0979d4ceb759a349df6cb0@varnish-cache.org> #880: Error when pushing 5G objects through Varnish --------------------+------------------------------------------------------- Reporter: perbu | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by kristian): * status: closed => reopened * resolution: fixed => Comment: Depends on your definition of "same issue". It's not the same assert error, and the file you're asking for is smaller than 4GB, yet larger than 2GB, so could get hit by signed 32-bit integers. What precise version of Varnish are you using? If you are not using a recent version from git, it's likely that this has been cleared up along with other changes. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 29 08:31:59 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 29 Apr 2011 08:31:59 -0000 Subject: [Varnish] #880: Error when pushing 5G objects through Varnish In-Reply-To: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> References: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> Message-ID: <051.d2873d1b06a25bd2862978a8d1f851b1@varnish-cache.org> #880: Error when pushing 5G objects through Varnish --------------------+------------------------------------------------------- Reporter: perbu | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by kristian): * owner: => kristian * status: reopened => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 29 14:14:45 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 29 Apr 2011 14:14:45 -0000 Subject: [Varnish] #880: Error when pushing 5G objects through Varnish In-Reply-To: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> References: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> Message-ID: <051.ad5bcf78e60f0de3a682265f9f87e589@varnish-cache.org> #880: Error when pushing 5G objects through Varnish --------------------+------------------------------------------------------- Reporter: perbu | Owner: kristian Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment(by rrauenza): I grabbed the latest git code last night and the problem went away. Good to see this issue is already being addressed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Apr 29 14:35:22 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 29 Apr 2011 14:35:22 -0000 Subject: [Varnish] #880: Error when pushing 5G objects through Varnish In-Reply-To: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> References: <042.409c629cd315987d8bc77e4b3798db58@varnish-cache.org> Message-ID: <051.a9aad9de08a1ef1f653b1ddbf203966f@varnish-cache.org> #880: Error when pushing 5G objects through Varnish --------------------+------------------------------------------------------- Reporter: perbu | Owner: kristian Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by kristian): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From maxp at pdx.edu Wed Apr 27 20:52:15 2011 From: maxp at pdx.edu (Max Parmer) Date: Wed, 27 Apr 2011 13:52:15 -0700 Subject: [Varnish] #906: Varnish 2.1.x packages for el5 are not signed In-Reply-To: <050.589a328c5218f983fc83d016c996d47c@varnish-cache.org> References: <041.4aa6d7c420932c17d0e884dba43bd18d@varnish-cache.org> <050.589a328c5218f983fc83d016c996d47c@varnish-cache.org> Message-ID: <1303937535.32441.35.camel@paimon.oit.pdx.edu> On Tue, 2011-04-26 at 07:40 +0000, Varnish wrote: > #906: Varnish 2.1.x packages for el5 are not signed > ------------------------------+--------------------------------------------- > Reporter: maxp | Type: defect > Status: new | Priority: high > Milestone: | Component: build > Version: trunk | Severity: major > Keywords: gpg rpm security | > ------------------------------+--------------------------------------------- > > Comment(by tfheen): > > The reason for the RPMs being unsigned is signing them breaks RPM and > corrupts the RPM database. Now, this is of course a bug in, but rather > than breaking machines we distribute unsigned packages. > > I'm unlikely to change this, but will leave the bug open for now. > Could you tell me more about how it breaks? I am willing to help fix this issue. -- Max Parmer CIS UNIX 503.725.9157