From varnish-bugs at varnish-cache.org Tue Oct 1 12:48:22 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 01 Oct 2013 12:48:22 -0000 Subject: [Varnish] #1351: varnishlog segfault in vtx_scan_linktag In-Reply-To: <046.027c3895b7f89072c5e8e2654f1a32d2@varnish-cache.org> References: <046.027c3895b7f89072c5e8e2654f1a32d2@varnish-cache.org> Message-ID: <061.ec54818c62c21c86974faad650906b56@varnish-cache.org> #1351: varnishlog segfault in vtx_scan_linktag ------------------------+----------------------------------------------- Reporter: lkarsten | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [782251a341fab3eb3a8dc6f6db91cf94ed5e633a]: {{{ #!CommitTicketReference repository="" revision="782251a341fab3eb3a8dc6f6db91cf94ed5e633a" Redo SLT_VSL diagnostic log records from the API A vtx_diag log record could realloc the memory buffers while processing a vtx, causing ptrs to previous memory to be still used. Fix this by having generated log records be malloced and kept on a separate list, which is always reported first on a reset cursor. Fixes: #1351 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 06:56:16 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 06:56:16 -0000 Subject: [Varnish] #1347: varnishtest: cache_hitpass counter does not counting hit_for_pass In-Reply-To: <040.e7cb1743e83e491b15d7ace8e8d4ffed@varnish-cache.org> References: <040.e7cb1743e83e491b15d7ace8e8d4ffed@varnish-cache.org> Message-ID: <055.8b62429b42b7d8b40b430fb99b999994@varnish-cache.org> #1347: varnishtest: cache_hitpass counter does not counting hit_for_pass -------------------------+------------------------- Reporter: lo | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: 3.0.4 Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Correct, it's only when we encounter a hit-for-pass object on lookup that we increment it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 07:52:37 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 07:52:37 -0000 Subject: [Varnish] #1350: IMS+Vary asserts In-Reply-To: <043.94ca1de2e0fa693c674e71707fedece7@varnish-cache.org> References: <043.94ca1de2e0fa693c674e71707fedece7@varnish-cache.org> Message-ID: <058.d3907eb66ca1e0bdf916761ff351ccf6@varnish-cache.org> #1350: IMS+Vary asserts ----------------------+---------------------------------------- Reporter: scoof | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [c0fc574a530b7a66060e80b22bd91de8e2eb5b32]: {{{ #!CommitTicketReference repository="" revision="c0fc574a530b7a66060e80b22bd91de8e2eb5b32" VRY_Len() returns only the length of a single entry in the VRY spec, for conditional fetch-copying, we need the length of the full VRY-spec. Fixes: #1350 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 08:18:50 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 08:18:50 -0000 Subject: [Varnish] #1352: Assert error in VEP_Init(), cache_esi_parse.c line 1001:#012 Condition((sp->wrk->vep) != 0) not true. Message-ID: <042.2d1c8bf37c8fbd9c4b2d6a9251293ded@varnish-cache.org> #1352: Assert error in VEP_Init(), cache_esi_parse.c line 1001:#012 Condition((sp->wrk->vep) != 0) not true. ---------------------+-------------------- Reporter: Smar | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | ---------------------+-------------------- Hi, I got following assert error on a live server. Oct 2 02:01:58 varnish varnishd[3147]: Child (22377) not responding to CLI, killing it. Oct 2 02:01:58 varnish varnishd[3147]: Child (22377) died signal=6 Oct 2 02:01:58 varnish varnishd[3147]: Child (22377) Panic message: Assert error in VEP_Init(), cache_esi_parse.c line 1001:#012 Condition((sp->wrk->vep) != 0) not true.#012thread = (cache- worker)#012ident = Linux,2.6.39-bpo.2-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x439565: pan_backtrace+19#012 0x43983a: pan_ic+1ad#012 0x426f05: VEP_Init+bd#012 0x423c41: vfp_esi_begin+381#012 0x42b044: VFP_Begin+e2#012 0x42c6d6: FetchBody+45d#012 0x41bdd8: cnt_fetchbody+b90#012 0x41ebe1: CNT_Session+793#012 0x4276b6: ved_include+237#012 0x4284bf: ESI_Deliver+968#012sp = 0x7f9a3feee008 {#012 fd = 37, id = 37, xid = 286162510,#012 client = 46.161.41.24 63058,#012 step = STP_FETCHBODY,#012 handling = deliver,#012 err_code = 200, err_reason = (null),#012 restarts = 0, esi_level = 1#012 flags = do_esi do_close is_gunzip#012 bodystatus = 5#012 ws = 0x7f9a3feee080 { #012 id = "sess",#012 {s,f,r,e} = {0x7f9a3feeec78,+2560,(nil),+65536},#012 },#012 http[req] = {#012 ws = 0x7f9a3feee080[sess]#012 "GET",#012 "/index_part.php?get=community_id%3D31%26city_id%3D74%26region_id%3D13124%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC&post=&HTTP_HOST =kara- koivukyla.nettipizza.eu&REQUEST_URI=%2Findex.php%3Fcommunity_id%3D31%26city_id%3D74%26region_id%3D13124%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DbonusPros%26sortType%3DASC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC&QUERY_STRING=community_id%3D31%26city_id%3D74%26region_id%3D13124%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DbonusPros%26sortType%3DASC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC",#012 "HTTP/1.1",#012 "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows 95) Opera 7.03 [de]",#012 "Accept: */*",#012 "Cache-Control: max-age=259200",#012 "Connection: keep-alive",#012 "Host: p Since it?s from syslog, it seems to be cut, but is this enough information to know what happened? That user agent is some kind of bot, most likely malicious, if it matters. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 09:29:16 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 09:29:16 -0000 Subject: [Varnish] #1337: Bad assert causes panic on invalid http status codes In-Reply-To: <041.8fd8fff6778724baf73c9fbe4b97f40c@varnish-cache.org> References: <041.8fd8fff6778724baf73c9fbe4b97f40c@varnish-cache.org> Message-ID: <056.e311cc1879c0eb8928c80a69af7a8683@varnish-cache.org> #1337: Bad assert causes panic on invalid http status codes ----------------------+--------------------- Reporter: mha | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.4 Severity: major | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [1b4a6b5ed8bf3389b4d920dc54579c754f475f36]: {{{ #!CommitTicketReference repository="" revision="1b4a6b5ed8bf3389b4d920dc54579c754f475f36" Spot and handle 3-digit status from backend, where the first digit is zero. Fixes: #1337 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 09:33:23 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 09:33:23 -0000 Subject: [Varnish] #1352: Assert error in VEP_Init(), cache_esi_parse.c line 1001:#012 Condition((sp->wrk->vep) != 0) not true. In-Reply-To: <042.2d1c8bf37c8fbd9c4b2d6a9251293ded@varnish-cache.org> References: <042.2d1c8bf37c8fbd9c4b2d6a9251293ded@varnish-cache.org> Message-ID: <057.fa5aa32e93243b59a86394b88240bdd9@varnish-cache.org> #1352: Assert error in VEP_Init(), cache_esi_parse.c line 1001:#012 Condition((sp->wrk->vep) != 0) not true. --------------------+---------------------- Reporter: Smar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+---------------------- Description changed by phk: Old description: > Hi, > > I got following assert error on a live server. > > Oct 2 02:01:58 varnish varnishd[3147]: Child (22377) not responding to > CLI, killing it. > Oct 2 02:01:58 varnish varnishd[3147]: Child (22377) died signal=6 > Oct 2 02:01:58 varnish varnishd[3147]: Child (22377) Panic message: > Assert error in VEP_Init(), cache_esi_parse.c line 1001:#012 > Condition((sp->wrk->vep) != 0) not true.#012thread = (cache- > worker)#012ident = > Linux,2.6.39-bpo.2-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x439565: pan_backtrace+19#012 0x43983a: pan_ic+1ad#012 0x426f05: > VEP_Init+bd#012 0x423c41: vfp_esi_begin+381#012 0x42b044: > VFP_Begin+e2#012 0x42c6d6: FetchBody+45d#012 0x41bdd8: > cnt_fetchbody+b90#012 0x41ebe1: CNT_Session+793#012 0x4276b6: > ved_include+237#012 0x4284bf: ESI_Deliver+968#012sp = 0x7f9a3feee008 > {#012 fd = 37, id = 37, xid = 286162510,#012 client = 46.161.41.24 > 63058,#012 step = STP_FETCHBODY,#012 handling = deliver,#012 err_code > = 200, err_reason = (null),#012 restarts = 0, esi_level = 1#012 flags = > do_esi do_close is_gunzip#012 bodystatus = 5#012 ws = 0x7f9a3feee080 { > #012 id = "sess",#012 {s,f,r,e} = > {0x7f9a3feeec78,+2560,(nil),+65536},#012 },#012 http[req] = {#012 ws > = 0x7f9a3feee080[sess]#012 "GET",#012 > "/index_part.php?get=community_id%3D31%26city_id%3D74%26region_id%3D13124%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC&post=&HTTP_HOST > =kara- > koivukyla.nettipizza.eu&REQUEST_URI=%2Findex.php%3Fcommunity_id%3D31%26city_id%3D74%26region_id%3D13124%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DbonusPros%26sortType%3DASC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC&QUERY_STRING=community_id%3D31%26city_id%3D74%26region_id%3D13124%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DbonusPros%26sortType%3DASC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC",#012 > "HTTP/1.1",#012 "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MSIE > 5.5; Windows 95) Opera 7.03 [de]",#012 "Accept: */*",#012 > "Cache-Control: max-age=259200",#012 "Connection: keep-alive",#012 > "Host: p > > Since it?s from syslog, it seems to be cut, but is this enough > information to know what happened? > > That user agent is some kind of bot, most likely malicious, if it > matters. New description: Hi, I got following assert error on a live server. {{{ Oct 2 02:01:58 varnish varnishd[3147]: Child (22377) not responding to CLI, killing it. Oct 2 02:01:58 varnish varnishd[3147]: Child (22377) died signal=6 Oct 2 02:01:58 varnish varnishd[3147]: Child (22377) Panic message: Assert error in VEP_Init(), cache_esi_parse.c line 1001: Condition((sp->wrk->vep) != 0) not true. thread = (cache-worker) ident = Linux,2.6.39-bpo.2-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x439565: pan_backtrace+19 0x43983a: pan_ic+1ad 0x426f05: VEP_Init+bd 0x423c41: vfp_esi_begin+381 0x42b044: VFP_Begin+e2 0x42c6d6: FetchBody+45d 0x41bdd8: cnt_fetchbody+b90 0x41ebe1: CNT_Session+793 0x4276b6: ved_include+237 0x4284bf: ESI_Deliver+968 sp = 0x7f9a3feee008 { fd = 37, id = 37, xid = 286162510, client = 46.161.41.24 63058, step = STP_FETCHBODY, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 1 flags = do_esi do_close is_gunzip bodystatus = 5 ws = 0x7f9a3feee080 { id = "sess", {s,f,r,e} = {0x7f9a3feeec78,+2560,(nil),+65536}, }, http[req] = { ws = 0x7f9a3feee080[sess] "GET", "/index_part.php?get=community_id%3D31%26city_id%3D74%26region_id%3D13124%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC&post=&HTTP_HOST =kara- koivukyla.nettipizza.eu&REQUEST_URI=%2Findex.php%3Fcommunity_id%3D31%26city_id%3D74%26region_id%3D13124%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DbonusPros%26sortType%3DASC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC&QUERY_STRING=community_id%3D31%26city_id%3D74%26region_id%3D13124%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DbonusPros%26sortType%3DASC%26sort%3DarvostelutAvg%26sortType%3DASC%26sort%3DkumppaniToiminimiValue%26sortType%3DDESC", "HTTP/1.1", "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows 95) Opera 7.03 [de]", "Accept: */*", "Cache-Control: max-age=259200", "Connection: keep-alive", "Host: p }}} Since it?s from syslog, it seems to be cut, but is this enough information to know what happened? That user agent is some kind of bot, most likely malicious, if it matters. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 10:32:44 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 10:32:44 -0000 Subject: [Varnish] #1352: Assert error in VEP_Init(), cache_esi_parse.c line 1001:#012 Condition((sp->wrk->vep) != 0) not true. In-Reply-To: <042.2d1c8bf37c8fbd9c4b2d6a9251293ded@varnish-cache.org> References: <042.2d1c8bf37c8fbd9c4b2d6a9251293ded@varnish-cache.org> Message-ID: <057.a6e1b4eb005e2a75716b62d3d377ffb8@varnish-cache.org> #1352: Assert error in VEP_Init(), cache_esi_parse.c line 1001:#012 Condition((sp->wrk->vep) != 0) not true. --------------------+---------------------- Reporter: Smar | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+---------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 10:37:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 10:37:29 -0000 Subject: [Varnish] #1348: varnishadm still loops on piped input In-Reply-To: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> References: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> Message-ID: <056.fc1eb45d1e36f6ab2ef375c49d7c33ab@varnish-cache.org> #1348: varnishadm still loops on piped input -----------------------------+--------------------- Reporter: ghp | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: Keywords: varnishadm pipe | -----------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 10:39:52 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 10:39:52 -0000 Subject: [Varnish] #979: sp->wrk->h_content_length is not cleared when do_stream and restart in vcl_deliver In-Reply-To: <044.5d092cfd81b0ae7cedd771400862058b@varnish-cache.org> References: <044.5d092cfd81b0ae7cedd771400862058b@varnish-cache.org> Message-ID: <059.d906fee129a53e7b738ac13d5bb917e9@varnish-cache.org> #979: sp->wrk->h_content_length is not cleared when do_stream and restart in vcl_deliver ----------------------+--------------------- Reporter: martin | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Resolution: Keywords: | ----------------------+--------------------- Changes (by martin): * owner: => martin * status: reopened => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 10:40:27 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 10:40:27 -0000 Subject: [Varnish] #1345: varnishlog -d does not exit after dump is completed In-Reply-To: <046.42c68e867a537b9306aafc62a4483ad0@varnish-cache.org> References: <046.42c68e867a537b9306aafc62a4483ad0@varnish-cache.org> Message-ID: <061.3abf9bd03979a4722e7553aa69b7eac2@varnish-cache.org> #1345: varnishlog -d does not exit after dump is completed ------------------------+---------------------- Reporter: lkarsten | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: unknown Severity: normal | Resolution: Keywords: | ------------------------+---------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 11:45:45 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 11:45:45 -0000 Subject: [Varnish] #1352: Assert error in VEP_Init(), cache_esi_parse.c line 1001:#012 Condition((sp->wrk->vep) != 0) not true. In-Reply-To: <042.2d1c8bf37c8fbd9c4b2d6a9251293ded@varnish-cache.org> References: <042.2d1c8bf37c8fbd9c4b2d6a9251293ded@varnish-cache.org> Message-ID: <057.253c5bdfc2af7f693af2970f6d8fbb12@varnish-cache.org> #1352: Assert error in VEP_Init(), cache_esi_parse.c line 1001:#012 Condition((sp->wrk->vep) != 0) not true. --------------------+---------------------- Reporter: Smar | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: invalid Keywords: | --------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: This assert is caused by the session workspace running out. When doing ESI deliveries, the session workspace usage will increase, especially when doing nested ESI includes. Increase the sess_workspace runtime parameter. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 12:11:11 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 12:11:11 -0000 Subject: [Varnish] #979: sp->wrk->h_content_length is not cleared when do_stream and restart in vcl_deliver In-Reply-To: <044.5d092cfd81b0ae7cedd771400862058b@varnish-cache.org> References: <044.5d092cfd81b0ae7cedd771400862058b@varnish-cache.org> Message-ID: <059.7f8ed4b4addb6a2ef75016e35bb02f31@varnish-cache.org> #979: sp->wrk->h_content_length is not cleared when do_stream and restart in vcl_deliver ----------------------+--------------------- Reporter: martin | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: In [76516d9584ba7c1baffe4049a82f13f6e841f615]: {{{ #!CommitTicketReference repository="" revision="76516d9584ba7c1baffe4049a82f13f6e841f615" Be more thorough the testing streaming+restart Reset vfp when restarting in deliver, in case it has be set in cnt_fetchbody already. Fixes: #979 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 12:11:20 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 12:11:20 -0000 Subject: [Varnish] #979: sp->wrk->h_content_length is not cleared when do_stream and restart in vcl_deliver In-Reply-To: <044.5d092cfd81b0ae7cedd771400862058b@varnish-cache.org> References: <044.5d092cfd81b0ae7cedd771400862058b@varnish-cache.org> Message-ID: <059.91f57cc2880f99c2b205a536bc0ca0c7@varnish-cache.org> #979: sp->wrk->h_content_length is not cleared when do_stream and restart in vcl_deliver ----------------------+--------------------- Reporter: martin | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Martin Blix Grydeland ): In [03d60dce9044d6dce650c7bb239e04e6089d2d77]: {{{ #!CommitTicketReference repository="" revision="03d60dce9044d6dce650c7bb239e04e6089d2d77" Be more thorough the testing streaming+restart Reset vfp when restarting in deliver, in case it has be set in cnt_fetchbody already. Fixes: #979 Conflicts: bin/varnishd/cache_center.c }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 12:23:58 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 12:23:58 -0000 Subject: [Varnish] #1338: varnishlog mangpage is out of date In-Reply-To: <041.23d893a15dc8f4dda9f4dd6568d0590b@varnish-cache.org> References: <041.23d893a15dc8f4dda9f4dd6568d0590b@varnish-cache.org> Message-ID: <056.e3f325be1c3bedb4ccf59e71f1acde27@varnish-cache.org> #1338: varnishlog mangpage is out of date ---------------------------+------------------------ Reporter: mha | Owner: martin Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: 3.0.4 Severity: normal | Resolution: duplicate Keywords: | ---------------------------+------------------------ Changes (by martin): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #1314. Merged fix from #1314 to 3.0 branch. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 12:24:12 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 12:24:12 -0000 Subject: [Varnish] #1314: varnishadm and pipe In-Reply-To: <047.4e26d1573a50888000f823ddf62bc65c@varnish-cache.org> References: <047.4e26d1573a50888000f823ddf62bc65c@varnish-cache.org> Message-ID: <062.f081daf7d9243483bc77f0e31bab64a2@varnish-cache.org> #1314: varnishadm and pipe -----------------------------+----------------------------------------- Reporter: johnnyrun | Owner: Tollef Fog Heen Type: defect | Status: closed Priority: normal | Milestone: After Varnish 2.1 Component: varnishadm | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishadm pipe | -----------------------------+----------------------------------------- Comment (by Martin Blix Grydeland ): In [7c3e40fe2dae02028cf3094f459834e1656978f4]: {{{ #!CommitTicketReference repository="" revision="7c3e40fe2dae02028cf3094f459834e1656978f4" Handle input from stdin properly in varnishadm readline doesn't really handle when input comes from a file or pipe, so only use readline if stdin is a tty. Thanks to johnnyrun for a patch which was used for inspiration here. Fixes #1314 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 12:26:20 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 12:26:20 -0000 Subject: [Varnish] #1348: varnishadm still loops on piped input In-Reply-To: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> References: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> Message-ID: <056.ed06bcc7667b35ba760bab77a4674ddc@varnish-cache.org> #1348: varnishadm still loops on piped input -----------------------------+------------------------ Reporter: ghp | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: duplicate Keywords: varnishadm pipe | -----------------------------+------------------------ Changes (by martin): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #1314. Merged fix from #1314 to 3.0 branch. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 13:26:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 13:26:29 -0000 Subject: [Varnish] #1348: varnishadm still loops on piped input In-Reply-To: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> References: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> Message-ID: <056.63f810b9442e22e96f4c0a8888328094@varnish-cache.org> #1348: varnishadm still loops on piped input -----------------------------+------------------------ Reporter: ghp | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: duplicate Keywords: varnishadm pipe | -----------------------------+------------------------ Comment (by ghp): Replying to [comment:2 martin]: > This is a duplicate of #1314. > > Merged fix from #1314 to 3.0 branch. > > Martin Hi Martin, can I try this fix? If so, how? Thanks, Gerard -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 13:29:33 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 13:29:33 -0000 Subject: [Varnish] #1348: varnishadm still loops on piped input In-Reply-To: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> References: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> Message-ID: <056.d30849fb6228136de12a14fd13e98f71@varnish-cache.org> #1348: varnishadm still loops on piped input -----------------------------+------------------------ Reporter: ghp | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: duplicate Keywords: varnishadm pipe | -----------------------------+------------------------ Comment (by martin): Fix is in the 3.0 branch, and will be part of the next 3.0 release (though no date has been set for this). If you need it now, you will need to compile Varnish from source by checkout out the 3.0 branch from our repositories. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 13:56:44 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 13:56:44 -0000 Subject: [Varnish] #1348: varnishadm still loops on piped input In-Reply-To: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> References: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> Message-ID: <056.016b3032cb8fd5d681c4ec986bd378cb@varnish-cache.org> #1348: varnishadm still loops on piped input -----------------------------+------------------------ Reporter: ghp | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: duplicate Keywords: varnishadm pipe | -----------------------------+------------------------ Comment (by ghp): Replying to [comment:4 martin]: > Fix is in the 3.0 branch, and will be part of the next 3.0 release (though no date has been set for this). If you need it now, you will need to compile Varnish from source by checkout out the 3.0 branch from our repositories. > > Martin If I download a daily snapshot tomorrow, it should contain the fix? Thanks, Gerard -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 14:46:05 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 14:46:05 -0000 Subject: [Varnish] #1353: [Varnish 3] Logging client source port in varnishncsa Message-ID: <047.93f4f1e53ab7eb8a5e6da9cc6549c7e9@varnish-cache.org> #1353: [Varnish 3] Logging client source port in varnishncsa -----------------------------+------------------------- Reporter: caiotedim | Type: task Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishncsa Version: 3.0.3 | Severity: normal Keywords: | -----------------------------+------------------------- Hi guys, I?m facing some problem to logging client source port in varnishncsa. Eg: httpd: %{remote}p nginx: $remote_port Tanks in advance!! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 15:14:44 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 15:14:44 -0000 Subject: [Varnish] #1348: varnishadm still loops on piped input In-Reply-To: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> References: <041.61299e9631a40ea2849cd0fac22e72d1@varnish-cache.org> Message-ID: <056.26b3fbc99b3e4db01c7821c8938dc365@varnish-cache.org> #1348: varnishadm still loops on piped input -----------------------------+------------------------ Reporter: ghp | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: duplicate Keywords: varnishadm pipe | -----------------------------+------------------------ Comment (by martin): We don't do daily snapshots for the 3.0 branch. Check out the branch from the git repository. Please use the varnish-misc mailing list or ask in the #varnish IRC channel if you need help with this. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 2 16:34:17 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Oct 2013 16:34:17 -0000 Subject: [Varnish] #1353: [Varnish 3] Logging client source port in varnishncsa In-Reply-To: <047.93f4f1e53ab7eb8a5e6da9cc6549c7e9@varnish-cache.org> References: <047.93f4f1e53ab7eb8a5e6da9cc6549c7e9@varnish-cache.org> Message-ID: <062.1d3087831a58a41cd021360a16b8acaf@varnish-cache.org> #1353: [Varnish 3] Logging client source port in varnishncsa -------------------------+------------------------------ Reporter: caiotedim | Owner: Type: task | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishncsa | Version: 3.0.3 Severity: normal | Resolution: invalid Keywords: | -------------------------+------------------------------ Changes (by daghf): * status: new => closed * resolution: => invalid Comment: This bug tracker is for bugs only. Please consult the varnish-misc mailing list or #varnish on IRC for these types of requests. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 10 10:41:24 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 10 Oct 2013 10:41:24 -0000 Subject: [Varnish] #1354: Segfault in libvgz.so Message-ID: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> #1354: Segfault in libvgz.so -------------------+-------------------- Reporter: ixos | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 3.0.4 | Severity: major Keywords: | -------------------+-------------------- Under high load and low free memory left (~200MB from 4GB) varnish crushes: kernel: varnishd[2240]: segfault at 7efad8f020e6 ip 00007f3cad7bd3b0 sp 00007efb2bec80c0 error 4 in libvgz.so[7f3cad7b1000+19000] Host with varnish is debian 64-bit (version 6.0.5).[[BR]] I'm using current stable varnish (3.0.4) for testing. vcl file is as simple as possible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 10 16:23:15 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 10 Oct 2013 16:23:15 -0000 Subject: [Varnish] #1355: ESI processing should also work when first character is a BOM Message-ID: <048.bf4ac5f518e41f91eab86d397f3a244f@varnish-cache.org> #1355: ESI processing should also work when first character is a BOM ------------------------+-------------------- Reporter: JohnMoylan | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.4 | Severity: normal Keywords: ESI, BOM | ------------------------+-------------------- ESI's are not firing on BOM'd content. If Varnish detects a Byte order Mark it should probably have an option to check if the next character a < instead of not processing it for ESI. This is going to be an issue with for environments with some or all content coming from a Microsoft workflow where not all BOM's might be easy to strip. 34 ObjHeader c Content-Type: text/html 34 ESI_xmlerror c No ESI processing, first char not '<' 34 Gzip c U F E 4066 16542 80 80 32463 34 Gzip c G F E 16542 4079 80 32552 32562 34 VCL_call c deliver 34 VCL_return c deliver 34 TxProtocol c HTTP/1.1 34 TxStatus c 200 34 TxResponse c OK 34 TxHeader c Cache-Control: max-age=180 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Oct 12 11:39:50 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 12 Oct 2013 11:39:50 -0000 Subject: [Varnish] #1356: cache/cache_http1_fsm.c:498: Wrong req_body_status in HTTP1_IterateReqBody() Message-ID: <046.a4489d13c48df5dd5c0f6b833c6abe03@varnish-cache.org> #1356: cache/cache_http1_fsm.c:498: Wrong req_body_status in HTTP1_IterateReqBody() ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Found an assert in current master. (a44b3a8) This is running on live traffic. Client is some sort of crawler/bot, the resource POSTed to is/would be 404. VCL is basic, filter google analytics cookies, run devicedetect.vcl, log via std.log(). No restarts. {{{ Last panic at: Thu, 10 Oct 2013 23:12:57 GMT Wrong turn at cache/cache_http1_fsm.c:498: Wrong req_body_status in HTTP1_IterateReqBody() errno = 32 (Broken pipe) thread = (cache-worker) ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4388e5: sess_close_2str+10f2 0x438bef: sess_close_2str+13fc 0x4326f3: HTTP1_IterateReqBody+1b7 0x4328f3: HTTP1_DiscardReqBody+48 0x43c3de: Pool_Init+150e 0x43e987: CNT_Request+4ef 0x4321cd: HTTP1_Session+427 0x441204: SES_Charge+752 0x44142c: SES_Charge+97a 0x441865: SES_pool_accept_task+201 req = 0x1dfd690 { sp = 0x1e6d2a0, vxid = 1074314613, step = R_STP_FETCH, req_body = R_BODY_FAIL, restarts = 0, esi_level = 0 sp = 0x1e6d2a0 { fd = 15, vxid = 572788, client = 188.44.39.75 51259, step = S_STP_WORKING, }, worker = 0x7f7dc42dec60 { ws = 0x7f7dc42dee58 { id = "wrk", {s,f,r,e} = {0x7f7dc42de440,0x7f7dc42de440,(nil),+2048}, }, VCL::method = 0x0, VCL::return = fetch, }, ws = 0x1dfd818 { id = "req", {s,f,r,e} = {0x1dfee70,+2648,(nil),+59424}, }, http[req] = { ws = 0x1dfd818[req] "POST", "/index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b", "HTTP/1.1", "Host: hyse.org", "User-Agent: BOT/0.1 (BOT for JCE)", "Content-Type: multipart/form-data; boundary=---------------------------41184676334", "Content-Length: 4567", "X-UA-Device: bot", "X-Forwarded-For: 188.44.39.75", }, vcl = { srcname = { "input", "Default", "/etc/varnish/varnish-devicedetect/devicedetect.vcl", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Oct 12 11:44:43 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 12 Oct 2013 11:44:43 -0000 Subject: [Varnish] #1357: VCL sub gives compiler warning in master/a44b3a8 Message-ID: <046.786e4ff8a7c500f1b2fee1d2090b8ef5@varnish-cache.org> #1357: VCL sub gives compiler warning in master/a44b3a8 ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: ----------------------+------------------- {{{ root at lb1:~# /opt/varnish/sbin/varnishd -P /var/run/varnishd.pid -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,3500m -p send_timeout=3600s Message from C-compiler: ./vcl.R82gfsuj.c: In function ?VGC_function_vcl_recv?: ./vcl.R82gfsuj.c:894:7: warning: passing argument 1 of ?VGC_function_devicedetect? discards ?const? qualifier from pointer target type [enabled by default] ./vcl.R82gfsuj.c:712:1: note: expected ?struct vrt_ctx *? but argument is of type ?const struct vrt_ctx *? ./vcl.R82gfsuj.c:896:7: warning: passing argument 1 of ?VGC_function_removeGA? discards ?const? qualifier from pointer target type [enabled by default] ./vcl.R82gfsuj.c:857:1: note: expected ?struct vrt_ctx *? but argument is of type ?const struct vrt_ctx *? root at lb1:~# }}} I belive this can be reproduced with this VCL: {{{ sub removeGA { if (req.http.Cookie) { # removes all cookies named __utm? (utma, utmb...) - tracking thing set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *__utm.=[^;]+;? *", "\1"); } if (req.http.Cookie == "") { unset req.http.Cookie; } } sub vcl_recv { call removeGA; } }}} (untested, but this seems pretty clear cut) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 14 11:07:51 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Oct 2013 11:07:51 -0000 Subject: [Varnish] #1345: varnishlog -d does not exit after dump is completed In-Reply-To: <046.42c68e867a537b9306aafc62a4483ad0@varnish-cache.org> References: <046.42c68e867a537b9306aafc62a4483ad0@varnish-cache.org> Message-ID: <061.589d7ccaa485e340e6a8dc82465e7053@varnish-cache.org> #1345: varnishlog -d does not exit after dump is completed ------------------------+---------------------- Reporter: lkarsten | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: unknown Severity: normal | Resolution: fixed Keywords: | ------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: Fixed by 047c517f210348d631eec949df9231c27ce7b759 Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 14 11:08:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Oct 2013 11:08:29 -0000 Subject: [Varnish] #1357: VCL sub gives compiler warning in master/a44b3a8 In-Reply-To: <046.786e4ff8a7c500f1b2fee1d2090b8ef5@varnish-cache.org> References: <046.786e4ff8a7c500f1b2fee1d2090b8ef5@varnish-cache.org> Message-ID: <061.9886ded3eb077c6f142a3e80e5fb7f98@varnish-cache.org> #1357: VCL sub gives compiler warning in master/a44b3a8 ----------------------+-------------------- Reporter: lkarsten | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 14 11:09:24 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Oct 2013 11:09:24 -0000 Subject: [Varnish] #1356: cache/cache_http1_fsm.c:498: Wrong req_body_status in HTTP1_IterateReqBody() In-Reply-To: <046.a4489d13c48df5dd5c0f6b833c6abe03@varnish-cache.org> References: <046.a4489d13c48df5dd5c0f6b833c6abe03@varnish-cache.org> Message-ID: <061.34628948368ca167c425dae9984622ba@varnish-cache.org> #1356: cache/cache_http1_fsm.c:498: Wrong req_body_status in HTTP1_IterateReqBody() ----------------------+-------------------- Reporter: lkarsten | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 14 11:34:13 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Oct 2013 11:34:13 -0000 Subject: [Varnish] #1355: ESI processing should also work when first character is a BOM In-Reply-To: <048.bf4ac5f518e41f91eab86d397f3a244f@varnish-cache.org> References: <048.bf4ac5f518e41f91eab86d397f3a244f@varnish-cache.org> Message-ID: <063.33988f168933de382aeb5e5d69e3ad2e@varnish-cache.org> #1355: ESI processing should also work when first character is a BOM ------------------------+-------------------- Reporter: JohnMoylan | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: Keywords: ESI, BOM | ------------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 14 12:00:55 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Oct 2013 12:00:55 -0000 Subject: [Varnish] #1354: Segfault in libvgz.so In-Reply-To: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> References: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> Message-ID: <057.1f1fc8c3c9d850b89ac6d10ffe1b55cb@varnish-cache.org> #1354: Segfault in libvgz.so --------------------+-------------------- Reporter: ixos | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 3.0.4 Severity: major | Resolution: Keywords: | --------------------+-------------------- Comment (by martin): Could you issue a 'varnishadm panic.show' on the server to see if there's a panic message to go with this? If there is please attach it to the ticket. Regards Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 16 07:11:22 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 16 Oct 2013 07:11:22 -0000 Subject: [Varnish] #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check In-Reply-To: <057.dbb04d60a18cae71789693faca361b5c@varnish-cache.org> References: <057.dbb04d60a18cae71789693faca361b5c@varnish-cache.org> Message-ID: <072.b49170c534255ffb23d53202e3dad96f@varnish-cache.org> #1220: Temporary gzip issue: Invalid Gzip data: incorrect header check -------------------------+--------------------- Reporter: jinjian.1@? | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: stream Gzip | -------------------------+--------------------- Comment (by miroslav.spousta): We also encountered this issue. It happens when: - backend server is using gzip + chunked encoding - streaming is allowed in VCL (set beresp.do_stream = true in vcl_fetch) The reason is that RES_StreamPoll() frees data before they are decoded by VGZ_Gunzip() in vfp_testgzip_bytes(). The attached patch fixes this by moving RES_StreamPoll() call just after VGZ buffer processing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 16 08:41:21 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 16 Oct 2013 08:41:21 -0000 Subject: [Varnish] #1354: Segfault in libvgz.so In-Reply-To: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> References: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> Message-ID: <057.72f236978e0b99b832fc79c06230e2d3@varnish-cache.org> #1354: Segfault in libvgz.so --------------------+-------------------- Reporter: ixos | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 3.0.4 Severity: major | Resolution: Keywords: | --------------------+-------------------- Comment (by ixos): Unfortunately panic doesn't occur with segfault -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 16 12:39:15 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 16 Oct 2013 12:39:15 -0000 Subject: [Varnish] #1338: varnishlog mangpage is out of date In-Reply-To: <041.23d893a15dc8f4dda9f4dd6568d0590b@varnish-cache.org> References: <041.23d893a15dc8f4dda9f4dd6568d0590b@varnish-cache.org> Message-ID: <056.74d671700c85efb72590af94b89d4a87@varnish-cache.org> #1338: varnishlog mangpage is out of date ---------------------------+--------------------- Reporter: mha | Owner: martin Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: In [1cd1d7a53ce4deae18bf4bacbf29cd1a7b54ec5c]: {{{ #!CommitTicketReference repository="" revision="1cd1d7a53ce4deae18bf4bacbf29cd1a7b54ec5c" Generate the VSL record tag documentation from the header tables. This patch generates an rst file containing the record tag documentation from the corresponding header tables. It also adds a man-page from the vsl.rst document and includes the tag descriptions. The old list of tags in varnishlog.rst is removed. Fixes: #1338 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 17 00:55:44 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Oct 2013 00:55:44 -0000 Subject: [Varnish] #1358: High n-expired objects Message-ID: <046.0690a67a5bf27ad6a98e6a439235cf1f@varnish-cache.org> #1358: High n-expired objects ----------------------+---------------------- Reporter: superjmt | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: normal Keywords: | ----------------------+---------------------- Hi My n_expired objects is growing a lot after a short time (a few minutes after varnish restarts), it seems that nearly every client_req leads to one n_expired objects in my default.vcl, the ttl is well define i don't understand why -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 17 01:41:32 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Oct 2013 01:41:32 -0000 Subject: [Varnish] #1358: High n-expired objects In-Reply-To: <046.0690a67a5bf27ad6a98e6a439235cf1f@varnish-cache.org> References: <046.0690a67a5bf27ad6a98e6a439235cf1f@varnish-cache.org> Message-ID: <061.3165fe359895bbd32492ed18288512be@varnish-cache.org> #1358: High n-expired objects ----------------------+-------------------- Reporter: superjmt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by superjmt): Debian Linux 6.0 Linux 3.2.0-0.bpo.4-amd64 sur x86_64 CPU Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz, 12 cores {{{ client_conn 16943 3.88 Client connections accepted client_drop 0 0.00 Connection dropped, no sess/wrk client_req 27990 6.41 Client requests received cache_hit 3127 0.72 Cache hits cache_hitpass 85 0.02 Cache hits for pass cache_miss 22210 5.09 Cache misses backend_conn 1705 0.39 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 23081 5.29 Backend conn. reuses backend_toolate 38 0.01 Backend conn. was closed backend_recycle 23125 5.30 Backend conn. recycles backend_retry 0 0.00 Backend conn. retry fetch_head 0 0.00 Fetch head fetch_length 23490 5.38 Fetch with Length fetch_chunked 1243 0.28 Fetch chunked fetch_eof 0 0.00 Fetch EOF fetch_bad 0 0.00 Fetch had bad headers fetch_close 2 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 fetch_1xx 0 0.00 Fetch no body (1xx) fetch_204 0 0.00 Fetch no body (204) fetch_304 1 0.00 Fetch no body (304) n_sess_mem 81 . N struct sess_mem n_sess 21 . N struct sess n_object 15968 . N struct object n_vampireobject 0 . N unresurrected objects n_objectcore 15970 . N struct objectcore n_objecthead 16311 . N struct objecthead n_waitinglist 52 . N struct waitinglist n_vbc 7 . N struct vbc n_wrk 15 . N worker threads n_wrk_create 28 0.01 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_lqueue 0 0.00 work request queue length n_wrk_queued 187 0.04 N queued work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 1 . N backends n_expired 6242 . N expired objects n_lru_nuked 0 . N LRU nuked objects n_lru_moved 2990 . N LRU moved objects losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 27783 6.36 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 16943 3.88 Total Sessions s_req 27990 6.41 Total Requests s_pipe 49 0.01 Total pipe s_pass 2526 0.58 Total pass s_fetch 24736 5.67 Total fetch s_hdrbytes 20855493 4777.89 Total header bytes s_bodybytes 503825251 115423.88 Total body bytes sess_closed 2877 0.66 Session Closed sess_pipeline 0 0.00 Session Pipeline sess_readahead 1 0.00 Session Read Ahead sess_linger 25342 5.81 Session Linger sess_herd 25922 5.94 Session herd shm_records 2523018 578.01 SHM records shm_writes 160370 36.74 SHM writes shm_flushes 0 0.00 SHM flushes due to overflow shm_cont 179 0.04 SHM MTX contention shm_cycles 1 0.00 SHM cycles through buffer sms_nreq 78 0.02 SMS allocator requests sms_nobj 0 . SMS outstanding allocations sms_nbytes 0 . SMS outstanding bytes sms_balloc 31044 . SMS bytes allocated sms_bfree 31044 . SMS bytes freed backend_req 24736 5.67 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_ban 1 . N total active bans n_ban_gone 1 . N total gone bans n_ban_add 1 0.00 N new bans added n_ban_retire 0 0.00 N old bans deleted n_ban_obj_test 0 0.00 N objects tested n_ban_re_test 0 0.00 N regexps tested against n_ban_dups 0 0.00 N duplicate bans removed hcb_nolock 25418 5.82 HCB Lookups without lock hcb_lock 22175 5.08 HCB Lookups with lock hcb_insert 22175 5.08 HCB Inserts esi_errors 0 0.00 ESI parse errors (unlock) esi_warnings 0 0.00 ESI parse warnings (unlock) accept_fail 0 0.00 Accept failures client_drop_late 0 0.00 Connection dropped late uptime 4365 1.00 Client uptime 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 vmods 0 . Loaded VMODs n_gzip 0 0.00 Gzip operations n_gunzip 24912 5.71 Gunzip operations LCK.sms.creat 1 0.00 Created locks LCK.sms.destroy 0 0.00 Destroyed locks LCK.sms.locks 234 0.05 Lock Operations LCK.sms.colls 0 0.00 Collisions LCK.smp.creat 0 0.00 Created locks LCK.smp.destroy 0 0.00 Destroyed locks LCK.smp.locks 0 0.00 Lock Operations LCK.smp.colls 0 0.00 Collisions LCK.sma.creat 2 0.00 Created locks LCK.sma.destroy 0 0.00 Destroyed locks LCK.sma.locks 92564 21.21 Lock Operations LCK.sma.colls 0 0.00 Collisions LCK.smf.creat 0 0.00 Created locks LCK.smf.destroy 0 0.00 Destroyed locks LCK.smf.locks 0 0.00 Lock Operations LCK.smf.colls 0 0.00 Collisions LCK.hsl.creat 0 0.00 Created locks LCK.hsl.destroy 0 0.00 Destroyed locks LCK.hsl.locks 0 0.00 Lock Operations LCK.hsl.colls 0 0.00 Collisions LCK.hcb.creat 1 0.00 Created locks LCK.hcb.destroy 0 0.00 Destroyed locks LCK.hcb.locks 28408 6.51 Lock Operations LCK.hcb.colls 0 0.00 Collisions LCK.hcl.creat 0 0.00 Created locks LCK.hcl.destroy 0 0.00 Destroyed locks LCK.hcl.locks 0 0.00 Lock Operations LCK.hcl.colls 0 0.00 Collisions LCK.vcl.creat 1 0.00 Created locks LCK.vcl.destroy 0 0.00 Destroyed locks LCK.vcl.locks 99 0.02 Lock Operations LCK.vcl.colls 0 0.00 Collisions LCK.stat.creat 1 0.00 Created locks LCK.stat.destroy 0 0.00 Destroyed locks LCK.stat.locks 17003 3.90 Lock Operations LCK.stat.colls 0 0.00 Collisions LCK.sessmem.creat 1 0.00 Created locks LCK.sessmem.destroy 0 0.00 Destroyed locks LCK.sessmem.locks 17338 3.97 Lock Operations LCK.sessmem.colls 0 0.00 Collisions LCK.wstat.creat 1 0.00 Created locks LCK.wstat.destroy 0 0.00 Destroyed locks LCK.wstat.locks 8807 2.02 Lock Operations LCK.wstat.colls 0 0.00 Collisions LCK.herder.creat 1 0.00 Created locks LCK.herder.destroy 0 0.00 Destroyed locks LCK.herder.locks 173 0.04 Lock Operations LCK.herder.colls 0 0.00 Collisions LCK.wq.creat 2 0.00 Created locks LCK.wq.destroy 0 0.00 Destroyed locks LCK.wq.locks 66393 15.21 Lock Operations LCK.wq.colls 0 0.00 Collisions LCK.objhdr.creat 22172 5.08 Created locks LCK.objhdr.destroy 5866 1.34 Destroyed locks LCK.objhdr.locks 114229 26.17 Lock Operations LCK.objhdr.colls 0 0.00 Collisions LCK.exp.creat 1 0.00 Created locks LCK.exp.destroy 0 0.00 Destroyed locks LCK.exp.locks 32817 7.52 Lock Operations LCK.exp.colls 0 0.00 Collisions LCK.lru.creat 2 0.00 Created locks LCK.lru.destroy 0 0.00 Destroyed locks LCK.lru.locks 22210 5.09 Lock Operations LCK.lru.colls 0 0.00 Collisions LCK.cli.creat 1 0.00 Created locks LCK.cli.destroy 0 0.00 Destroyed locks LCK.cli.locks 1468 0.34 Lock Operations LCK.cli.colls 0 0.00 Collisions LCK.ban.creat 1 0.00 Created locks LCK.ban.destroy 0 0.00 Destroyed locks LCK.ban.locks 32819 7.52 Lock Operations LCK.ban.colls 0 0.00 Collisions LCK.vbp.creat 1 0.00 Created locks LCK.vbp.destroy 0 0.00 Destroyed locks LCK.vbp.locks 0 0.00 Lock Operations LCK.vbp.colls 0 0.00 Collisions LCK.vbe.creat 1 0.00 Created locks LCK.vbe.destroy 0 0.00 Destroyed locks LCK.vbe.locks 3403 0.78 Lock Operations LCK.vbe.colls 0 0.00 Collisions LCK.backend.creat 1 0.00 Created locks LCK.backend.destroy 0 0.00 Destroyed locks LCK.backend.locks 51352 11.76 Lock Operations LCK.backend.colls 0 0.00 Collisions SMA.s0.c_req 44527 10.20 Allocator requests SMA.s0.c_fail 0 0.00 Allocator failures SMA.s0.c_bytes 2945463582 674791.20 Bytes allocated SMA.s0.c_freed 2733147683 626150.67 Bytes freed SMA.s0.g_alloc 31272 . Allocations outstanding SMA.s0.g_bytes 212315899 . Bytes outstanding SMA.s0.g_space 1935167749 . Bytes available SMA.Transient.c_req 5055 1.16 Allocator requests SMA.Transient.c_fail 0 0.00 Allocator failures SMA.Transient.c_bytes 329070995 75388.54 Bytes allocated SMA.Transient.c_freed 329070995 75388.54 Bytes freed SMA.Transient.g_alloc 0 . Allocations outstanding SMA.Transient.g_bytes 0 . Bytes outstanding SMA.Transient.g_space 0 . Bytes available VBE.prod(127.0.0.1,,8080).vcls 1 . VCL references VBE.prod(127.0.0.1,,8080).happy 0 . Happy health probes }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 17 02:58:23 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Oct 2013 02:58:23 -0000 Subject: [Varnish] #1358: High n-expired objects In-Reply-To: <046.0690a67a5bf27ad6a98e6a439235cf1f@varnish-cache.org> References: <046.0690a67a5bf27ad6a98e6a439235cf1f@varnish-cache.org> Message-ID: <061.7f32ec9aa12cf313db938156f7dfc4f2@varnish-cache.org> #1358: High n-expired objects ----------------------+-------------------- Reporter: superjmt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by superjmt): contenu de /etc/default/varnish {{{ DAEMON_OPTS="-a :80 \ -T localhost:6082 \ -f /etc/varnish/default.vcl \ -S /etc/varnish/secret \ -s malloc,2048m" }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 17 10:07:21 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Oct 2013 10:07:21 -0000 Subject: [Varnish] #1355: ESI processing should also work when first character is a BOM In-Reply-To: <048.bf4ac5f518e41f91eab86d397f3a244f@varnish-cache.org> References: <048.bf4ac5f518e41f91eab86d397f3a244f@varnish-cache.org> Message-ID: <063.840650d89f6c65179d10d6229b3657e4@varnish-cache.org> #1355: ESI processing should also work when first character is a BOM ------------------------+--------------------- Reporter: JohnMoylan | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: ESI, BOM | ------------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [5c03d65b8f63adccabce33d827203cf9d259bb6d]: {{{ #!CommitTicketReference repository="" revision="5c03d65b8f63adccabce33d827203cf9d259bb6d" Add a feature 'esi_remove_bom' which will make ESI ignore and remove UTF-8 BOM's at the start of an ESI-object. Notice that the removal only happens if the file is actually ESI processed on delivery, so to get BOM removal for non-XML files, you may have to disable the XML test and insert a dummy ESI directive such as BOMs Be Gone! or similar. Fixes #1355 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 17 10:14:50 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Oct 2013 10:14:50 -0000 Subject: [Varnish] #1357: VCL sub gives compiler warning in master/a44b3a8 In-Reply-To: <046.786e4ff8a7c500f1b2fee1d2090b8ef5@varnish-cache.org> References: <046.786e4ff8a7c500f1b2fee1d2090b8ef5@varnish-cache.org> Message-ID: <061.9ddf1e464f6775f85205ce145075004c@varnish-cache.org> #1357: VCL sub gives compiler warning in master/a44b3a8 ----------------------+--------------------- Reporter: lkarsten | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: minor | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [1cc4f78ba39735b763669dd1022ca6fb05fbd1fc]: {{{ #!CommitTicketReference repository="" revision="1cc4f78ba39735b763669dd1022ca6fb05fbd1fc" Fix prototype for user defined subroutines. Fixes #1357 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 17 13:47:09 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Oct 2013 13:47:09 -0000 Subject: [Varnish] #1359: std.ip is not documented Message-ID: <043.75be36d7ab66244002f24c7337373279@varnish-cache.org> #1359: std.ip is not documented -------------------+--------------------------- Reporter: fgsch | Type: documentation Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+--------------------------- When std.ip was merged into master vmod_std.rst was not updated. See https://www.varnish-cache.org/patchwork/patch/122/ for an example. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 21 10:07:48 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Oct 2013 10:07:48 -0000 Subject: [Varnish] #1359: std.ip is not documented In-Reply-To: <043.75be36d7ab66244002f24c7337373279@varnish-cache.org> References: <043.75be36d7ab66244002f24c7337373279@varnish-cache.org> Message-ID: <058.7ff2e11330ac6041a920d2623cbbbf60@varnish-cache.org> #1359: std.ip is not documented ---------------------------+-------------------- Reporter: fgsch | Owner: scoof Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Changes (by martin): * owner: => scoof -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 21 10:11:18 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Oct 2013 10:11:18 -0000 Subject: [Varnish] #1358: High n-expired objects In-Reply-To: <046.0690a67a5bf27ad6a98e6a439235cf1f@varnish-cache.org> References: <046.0690a67a5bf27ad6a98e6a439235cf1f@varnish-cache.org> Message-ID: <061.178db6af2f0a97ee6f05dce6b81fecda@varnish-cache.org> #1358: High n-expired objects ----------------------+-------------------- Reporter: superjmt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by martin): Please provide a varnishlog capture at the time this happens. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 21 10:13:14 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Oct 2013 10:13:14 -0000 Subject: [Varnish] #1354: Segfault in libvgz.so In-Reply-To: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> References: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> Message-ID: <057.52570527807115236bbd28a786c93363@varnish-cache.org> #1354: Segfault in libvgz.so --------------------+-------------------- Reporter: ixos | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 3.0.4 Severity: major | Resolution: Keywords: | --------------------+-------------------- Comment (by martin): Could you try to install the libvmod-sigsegv on the server please? To do this you first need to compile the vmod for the varnish you're running, and then reference the vmod in your vcl ('import sigsegv'). This should cause a panic to happen when a seg fault is generated. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 22 00:42:42 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Oct 2013 00:42:42 -0000 Subject: [Varnish] #1360: Director cannot have another director as backend Message-ID: <043.67f46b77e2f9eeb2b002712295f6e2fa@varnish-cache.org> #1360: Director cannot have another director as backend -----------------------------+---------------------- Reporter: kchiu | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishd Version: 3.0.4 | Severity: normal Keywords: | -----------------------------+---------------------- Config: backend varnish2 { .host = "varnish2.elance.com"; .port = "80"; .connect_timeout = 0.5s; } backend server1 { .host = "server1.elance.com"; .port = "80"; .connect_timeout = 0.5s; } director servers round-robin { { .backend = server1; } } director peer fallback { # peer takes precedence { .backend = varnish2; } { .backend = servers; } } Error message: Message from VCC-compiler: Reference to unknown backend 'servers' at ('input' Line 51 Pos 16) { .backend = servers; } ---------------#######--- In director specification starting at: ('input' Line 48 Pos 1) director peer fallback { ########---------------- Running VCC-compiler failed, exit 1 VCL compilation failed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 22 00:44:28 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Oct 2013 00:44:28 -0000 Subject: [Varnish] #1361: Varnish crash when "restart" is returned by vcl_miss Message-ID: <043.45a05b8fb1974c7e42ef80bf37ab5d0e@varnish-cache.org> #1361: Varnish crash when "restart" is returned by vcl_miss -----------------------------+---------------------- Reporter: kchiu | Type: defect Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: varnishd Version: 3.0.4 | Severity: normal Keywords: | -----------------------------+---------------------- It says fixed 7 months ago, but I still see the problem on 3.0.4: https://www.varnish-cache.org/trac/ticket/1263 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 22 09:15:12 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Oct 2013 09:15:12 -0000 Subject: [Varnish] #1354: Segfault in libvgz.so In-Reply-To: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> References: <042.7ab01804bb33216037a487adfec85430@varnish-cache.org> Message-ID: <057.eefe0a2e195a990edcafd1e21f037881@varnish-cache.org> #1354: Segfault in libvgz.so --------------------+-------------------- Reporter: ixos | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 3.0.4 Severity: major | Resolution: Keywords: | --------------------+-------------------- Comment (by ixos): {{{ Last panic at: Tue, 22 Oct 2013 06:38:05 GMT Assert error in vmod_ch_sighandler(), vmod_crashhandler.c line 13: Condition(You asked for it) not true. thread = (cache-worker) ident = Linux,3.10.9-xxxx-grs- ipv6-64,x86_64,-sfile,-sfile,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x439e6d: LCK_Init+1157 0x43a142: LCK_Init+142c 0x364fcc29230: _end+364fc592498 0x364fda4c344: _end+364fd3b55ac 0x364fda4ea11: _end+364fd3b7c79 0x42db5d: VGZ_Gunzip+12c 0x42f014: VGZ_Destroy+e0a 0x42b709: FetchError+2c9 0x42bef2: FetchStorage+4d8 0x42cc60: FetchBody+436 sp = 0x31237c3e008 { fd = 135, id = 135, xid = 1542650315, client = 0.0.0.0 60176, step = STP_STREAMBODY, handling = deliver, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 flags = do_stream do_close is_gzip bodystatus = 3 }}} One more thing worth mention: https://www.varnish-cache.org/trac/ticket/1292 I was suggested that it may be fault of 3rd part module. It isn't. I've tested it without any module and this panic occurs. Here are the panic in the same step STP_STREAMBODY/STP_STREAMDELIVER. It cannot be a coincident. Replying to [comment:3 martin]: > Could you try to install the libvmod-sigsegv on the server please? To do this you first need to compile the vmod for the varnish you're running, and then reference the vmod in your vcl ('import sigsegv'). This should cause a panic to happen when a seg fault is generated. > > Regards, > Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 22 14:28:10 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Oct 2013 14:28:10 -0000 Subject: [Varnish] #1362: varnishstat fails when hostname changes Message-ID: <049.9f2666e286b05da9d1075e035b4b18bc@varnish-cache.org> #1362: varnishstat fails when hostname changes -------------------------+-------------------- Reporter: raymondjiii | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------------+-------------------- In a cloud env a VM instance is brought up. It has one hostname assigned and then Varnish starts. At a later point during the VM being brought up the hostname changes (after all of the base packages are installed) when varnishstat runs it is now looking for /var/lib/(new hostname) instead of /var/lib/(original hostname) The only fix is to manually log into the machine and restart Varnish. Can varnishstat keep track of where the stats were first written when it first starts? And subsequently overwrite when Varnish is restarted rather then depending upon whatever 'hostname' returns at any point in time - which is not constant? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 22 20:45:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 22 Oct 2013 20:45:29 -0000 Subject: [Varnish] #1362: varnishstat fails when hostname changes In-Reply-To: <049.9f2666e286b05da9d1075e035b4b18bc@varnish-cache.org> References: <049.9f2666e286b05da9d1075e035b4b18bc@varnish-cache.org> Message-ID: <064.3a6a7659c0d5e285b9f674495a018e3d@varnish-cache.org> #1362: varnishstat fails when hostname changes -------------------------+---------------------- Reporter: raymondjiii | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Changes (by daghf): * status: new => closed * resolution: => invalid Comment: In an environment like this, please start varnishd using the -n command line parameter to specify an instance ID on startup. You can then use varnishstat and the other tools with that same -n argument. Please see https://www.varnish-cache.org/support for further advice. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 23 09:55:46 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 23 Oct 2013 09:55:46 -0000 Subject: [Varnish] #1363: Assert error in ObjIter(), cache/cache_obj.c line 111 Message-ID: <046.e635262a60559b07fed2a6ff0a1a7a1e@varnish-cache.org> #1363: Assert error in ObjIter(), cache/cache_obj.c line 111 ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Fryer found an assert in current master. (a3549d8) VCL is just a backend definition and vcl4.0 marker. {{{ Panic message: Assert error in ObjIter(), cache/cache_obj.c line 111: Condition(*l > 0) not true. thread = (cache-worker) ident = Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43818d: sess_close_2str+10f2 0x43849e: sess_close _2str+1403 0x436e8e: ObjIter+3a3 0x43f2a6: CNT_Request+13ae 0x43faf6: V1D_Deliver+7d3 0x43b27d: Pool_Init+9c3 0x43e421: CNT_Request+529 0 x431a0f: HTTP1_Session+427 0x440c6c: SES_Charge+752 0x440e94: SES_Charge+97a req = 0x7fe2b8030970 { sp = 0x7fe2bc002d00, vxid = 1078657293, step = R _STP_DELIVER, req_body = R_BODY_NONE, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 sp = 0x7fe2bc002d00 { fd = 72, vxid = 950273, client = 194.31.39.161 42101, step = S_STP_WORKING, }, worker = 0x7fe2da867c70 { ws = 0x7fe2da867e68 { id = "wrk",#01 2 {s,f,r,e} = {0x7fe2da867420,+80,+2048,+2048}, }, VCL::method = 0x0, VCL::return = deliver, }, ws = 0x7fe2b8030af8 { id = "req ", {s,f,r,e} = {0x7fe2b8032150,+360,(nil),+59424}, }, http[req] = { ws = 0x7fe2b8030af8[req] "GET", "/cacheabledata/set_image hosting1/0/image600.jpg", "HTTP/1.1", "Host: fryer1.varnish-software.com:6081", "Accept: */*", "User-Agent: Mozilla/5.0 (unknown-x8 6_64-linux-gnu) Siege/3.0.4", "Connection: keep-alive", "X-Forwarded-For: 194.31.39.161", "Accept-Encoding: gzip", }, http[resp] = { ws = 0x7fe2b8030af8[req] "HTTP/1.1", "200", "OK", "Server: Apache/2.2.22 (Ubuntu)", "Last-Modified: Mon, 26 Aug 2013 14:08:47 GMT", "ETag: "820dd0-423e8-4e4da4b84cdab"", "Content-Type: image/jpeg", "Date: Wed, 23 Oct 2013 09:16:46 GMT", "X-Varnish: 4915469", "Age: 1", [cut because of syslog] }}} {{{ 2013-10-23 11:27:18,268[fry] - INFO - run[fryer1]: /opt/varnish/sbin/varnishd -T localhost:6082 -a :6081 -f /opt/varnish/etc/testsuite.vcl -smalloc,0.7G -p default_ttl=86400 -p sigsegv_handler=on -p thread_pool_min=100 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 23 10:00:18 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 23 Oct 2013 10:00:18 -0000 Subject: [Varnish] #1364: Assert error in mgt_sigsegv_handler(), mgt/mgt_child.c line 328 Message-ID: <046.4236638300da782ed48b50e2dd732f94@varnish-cache.org> #1364: Assert error in mgt_sigsegv_handler(), mgt/mgt_child.c line 328 ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- After enabling the sigsegv handler chasing #1363 , I came across this assert. It may simply be a sideeffect of that bug, or the way the sigv handler works, but I'm reporting it to be sure. Same conditions and version as #1363. {{{ Panic message: Assert error in mgt_sigsegv_handler(), mgt/mgt_child.c line 328: Condition(Segmentation fault by instruction at 0x8) not true. thread = (cache-worker) ident = Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43818d: sess_close_2str+10f2 0x43849e: sess_close_2str+1403 0x45a13d: MGT_close_sockets+1fc 0x7f8adec96cb0: _end+7f8ade5f74c0 0x436dfe: ObjIter+313 0x43f2a6: CNT_Request+13ae 0x43faf6: V1D_Deliver+7d3 0x43b27d: Pool_Init+9c3 0x43e421: CNT_Request+529 0x431a0f: HTTP1_Session+427 req = 0x7f8a48000950 { sp = 0x7f8aa00a0ac0, vxid = 1076658266, step = R_STP_DELIVER, req_body = R_BODY_NONE, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 sp = 0x7f8aa00a0ac0 { fd = 78, vxid = 655361, client = 194.31.39.161 43536, step = S_STP_WORKING, }, worker = 0x7f8acd445c70 { ws = 0x7f8acd445e68 { id = "wrk", {s,f,r,e} = {0x7f8acd445420,+80,+2048,+2048}, }, VCL::method = 0x0, VCL::return = deliver, }, ws = 0x7f8a48000ad8 { id = "req", {s,f,r,e} = {0x7f8a48002130,+360,(nil),+59424}, }, http[req] = { ws = 0x7f8a48000ad8[req] "GET", "/cacheabledata/set_imagehosting1/3/image6283.jpg", "HTTP/1.1", "Host: fryer1.varnish-software.com:6081", "Accept: */*", "User-Agent: Mozilla/5.0 (unknown-x86_64-linux-gnu) Siege/3.0.4", "Connection: keep-alive", "X-Forwarded-For: 194.31.39.161", "Accept-Encoding: gzip", }, http[resp] = { ws = 0x7f8a48000ad8[req] "HTTP/1.1", "200", "OK", "Server: Apache/2.2.22 (Ubuntu)", "Last-Modified: Mon, 26 Aug 2013 14:09:57 GMT", "ETag: "822403-3e928-4e4da4fb21408"", "Content-Type: image/jpeg", "Date: Wed, 23 Oct 2013 09:29:57 GMT [syslog cutoff] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 23 16:02:57 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 23 Oct 2013 16:02:57 -0000 Subject: [Varnish] #1273: varnishncsa Extended variables. doesn't return Varnish:handling In-Reply-To: <042.85b4e36647f1fdf9a653f6a2a6f3cac6@varnish-cache.org> References: <042.85b4e36647f1fdf9a653f6a2a6f3cac6@varnish-cache.org> Message-ID: <057.8dac8a2dbac9a4ff61856cb04e0c90e0@varnish-cache.org> #1273: varnishncsa Extended variables. doesn't return Varnish:handling -------------------------------------------------+------------------------- Reporter: hugo | Owner: Type: defect | Status: closed Priority: low | Milestone: Component: varnishncsa | Version: 3.0.3 Severity: minor | Resolution: fixed Keywords: varnishncsa, Extended variables, | handling | -------------------------------------------------+------------------------- Comment (by quiver): This fix is not included in 3.0.4. When will this be merged into stable release? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 24 08:29:06 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 24 Oct 2013 08:29:06 -0000 Subject: [Varnish] #1363: Assert error in ObjIter(), cache/cache_obj.c line 111 In-Reply-To: <046.e635262a60559b07fed2a6ff0a1a7a1e@varnish-cache.org> References: <046.e635262a60559b07fed2a6ff0a1a7a1e@varnish-cache.org> Message-ID: <061.e1584e29f20fbefce3c36a3c8dce75a1@varnish-cache.org> #1363: Assert error in ObjIter(), cache/cache_obj.c line 111 ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [32cab6890b04a4f95a743f7c00228b33fd577e24]: {{{ #!CommitTicketReference repository="" revision="32cab6890b04a4f95a743f7c00228b33fd577e24" The assert that triggered in #1363 was to restrictive. Fixes #1363 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 24 08:31:57 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 24 Oct 2013 08:31:57 -0000 Subject: [Varnish] #1360: Director cannot have another director as backend In-Reply-To: <043.67f46b77e2f9eeb2b002712295f6e2fa@varnish-cache.org> References: <043.67f46b77e2f9eeb2b002712295f6e2fa@varnish-cache.org> Message-ID: <058.8014e689121516c83aa42558591e7c89@varnish-cache.org> #1360: Director cannot have another director as backend ----------------------+------------------------------ Reporter: kchiu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 3.0.4 Severity: normal | Resolution: wontfix Keywords: | ----------------------+------------------------------ Changes (by phk): * status: new => closed * resolution: => wontfix Comment: Correct, "stacking" directors is not supported until Varnish 4.x (Due to be released RSN) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 24 09:26:14 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 24 Oct 2013 09:26:14 -0000 Subject: [Varnish] #1263: Varnish Crash In-Reply-To: <043.4fecdbacf5db6c2385e7c0167e5aff67@varnish-cache.org> References: <043.4fecdbacf5db6c2385e7c0167e5aff67@varnish-cache.org> Message-ID: <058.41135d8a4500e54ae954b9a3eb84d335@varnish-cache.org> #1263: Varnish Crash ----------------------+----------------------- Reporter: comur | Owner: daghf Type: defect | Status: reopened Priority: high | Milestone: Component: varnishd | Version: 3.0.2 Severity: major | Resolution: Keywords: crash | ----------------------+----------------------- Changes (by lkarsten): * status: closed => reopened * resolution: fixed => -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 24 09:27:53 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 24 Oct 2013 09:27:53 -0000 Subject: [Varnish] #1263: Varnish Crash In-Reply-To: <043.4fecdbacf5db6c2385e7c0167e5aff67@varnish-cache.org> References: <043.4fecdbacf5db6c2385e7c0167e5aff67@varnish-cache.org> Message-ID: <058.2c1ae0058bf696831cfc5eb70701988f@varnish-cache.org> #1263: Varnish Crash ----------------------+---------------------- Reporter: comur | Owner: daghf Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.2 Severity: major | Resolution: wontfix Keywords: crash | ----------------------+---------------------- Changes (by lkarsten): * status: reopened => closed * resolution: => wontfix Comment: Seems that the end result of this ticked wasn't crystal clear, as seen in #1361. Reclosing with new status, nothing else has changed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 24 09:30:06 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 24 Oct 2013 09:30:06 -0000 Subject: [Varnish] #1361: Varnish crash when "restart" is returned by vcl_miss In-Reply-To: <043.45a05b8fb1974c7e42ef80bf37ab5d0e@varnish-cache.org> References: <043.45a05b8fb1974c7e42ef80bf37ab5d0e@varnish-cache.org> Message-ID: <058.f05e87b3e3262871ce833e1fedd6e342@varnish-cache.org> #1361: Varnish crash when "restart" is returned by vcl_miss ----------------------+------------------------------ Reporter: kchiu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 3.0 dev Component: varnishd | Version: 3.0.4 Severity: normal | Resolution: invalid Keywords: | ----------------------+------------------------------ Changes (by lkarsten): * status: new => closed * resolution: => invalid Comment: Please re-read the concluding comments in #1263. This is fixed in master/4.0, and won't be fixed in 3.0. The workaround is to jump into vcl_error and then restart. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 24 09:54:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 24 Oct 2013 09:54:29 -0000 Subject: [Varnish] #1356: cache/cache_http1_fsm.c:498: Wrong req_body_status in HTTP1_IterateReqBody() In-Reply-To: <046.a4489d13c48df5dd5c0f6b833c6abe03@varnish-cache.org> References: <046.a4489d13c48df5dd5c0f6b833c6abe03@varnish-cache.org> Message-ID: <061.6421018c7cc99cf62ffec11ff19cbc20@varnish-cache.org> #1356: cache/cache_http1_fsm.c:498: Wrong req_body_status in HTTP1_IterateReqBody() ----------------------+--------------------- Reporter: lkarsten | 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 [6f0e274716b8eac91936fab63b98cb798dd56e72]: {{{ #!CommitTicketReference repository="" revision="6f0e274716b8eac91936fab63b98cb798dd56e72" Inspired by #1356: Make handling of req.body much more robust and RFC-compliant. Fixes #1356 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 24 09:56:32 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 24 Oct 2013 09:56:32 -0000 Subject: [Varnish] #1341: Assert error in VBO_waitlen(), cache/cache_busyobj.c In-Reply-To: <046.744aeb614ae2d3396c09a0492d773d2d@varnish-cache.org> References: <046.744aeb614ae2d3396c09a0492d773d2d@varnish-cache.org> Message-ID: <061.4298c375b648d48cd80754243c1c4ba8@varnish-cache.org> #1341: Assert error in VBO_waitlen(), cache/cache_busyobj.c ----------------------+------------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I belive this got fixed as part of 39c049726ffc11332a8dcd50058b40801e93b2e7 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Oct 25 14:39:14 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 25 Oct 2013 14:39:14 -0000 Subject: [Varnish] #1365: AIX, configure, readline, libedit, python, C99 compatible build questions/issues Message-ID: <049.41434828da49a3ac122c1c8c7d6f60fe@varnish-cache.org> #1365: AIX, configure, readline, libedit, python, C99 compatible build questions/issues -------------------------+-------------------- Reporter: MichaelFelt | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | -------------------------+-------------------- Hi. I am trying to package varnish-3.0.4 and never having done this before I have a few questions about what is needed for packaging versus what is needed for runtime. A) when I had phython and a standard AIX rpm (readline) installed, configure completed successfully - but make complained of duplicate symbols (.bcopy and .memove) in libc.a and libreadline.so. The make did not finish because I was/am missing . 1) As the duplicate symbol problem was not a varnish issue, but libraries I removed the rpm version of readline and installed a new one - self- packaged. 2) to remove the readline rpm I also needed to remove python - configure succeeds, but make fails because phython is missing (so config is not testing for phython - if it is really needed for packaging (or runtime?) 3) is readline (libreadline) enough, or is libread (found in google and here in other tickets) enough, or are both required. In any case, with only readline installed, configure ... completes successfully. B) normally I am using the IBM compiler (vac/xlc) and because of frequent clashes with C++ comments I supply the CFLAG -qlanglvl=extc99 as a default. During configure the test for a C99 capable compiler passes - without change - only to fail in the next (or secnd following) test - saying the compiler is not C99 compatible. : ./configure ... returned an error configure:5149: checking dependency style of cc configure:5260: result: xlc configure:5279: checking for cc option to accept ISO C99 configure:5428: cc -c -I/opt/aixtools/include -O2 -qlanglvl=extc99 -I/opt/include conftest.c >&5 configure:5428: $? = 0 configure:5441: result: none needed configure:5549: checking for cc option to accept ISO Standard C configure:5560: result: none needed configure:5602: error: Could not find a C99 compatible compiler configure: exit 1 when I remove that additional CFLAG preset, configure finds a C99 compatible compiler. regards, Michael -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 28 12:29:51 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Oct 2013 12:29:51 -0000 Subject: [Varnish] #1364: Assert error in mgt_sigsegv_handler(), mgt/mgt_child.c line 328 In-Reply-To: <046.4236638300da782ed48b50e2dd732f94@varnish-cache.org> References: <046.4236638300da782ed48b50e2dd732f94@varnish-cache.org> Message-ID: <061.0b63077bd515ff414a93990871a09440@varnish-cache.org> #1364: Assert error in mgt_sigsegv_handler(), mgt/mgt_child.c line 328 ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): Here is another one of these from last night's run. Looks similar: {{{ Panic message: Assert error in mgt_sigsegv_handler(), mgt/mgt_child.c line 329: Condition(Segmentation fault by instruction at 0x7fd0a00af1cf) not true. thread = (c ache-worker) ident = Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43845c: sess_close_2str+1109 0x43876d: sess_close_2str+141a 0x45a389: MGT_close_sockets+1fc 0x7fd0d6 ecbcb0: _end+7fd0d682c4c0 0x7fd0d6c0fb22: _end+7fd0d6570332 0x7fd0d7e62067: _end+7fd0d77c2877 0x448e1e: VRT_IP_string+d4 0x7fd0cc5ac69c: _end+7fd0cbf0ceac 0x446625: VCL_Poll+8ef 0x4467b4: VCL_re cv_method+122 req = 0x7fd0a0090a90 { sp = 0x7fd0a4001c00, vxid = 1073741826, step = R_STP_RECV, req_body = R_BODY_NONE, restarts = 0, esi_level = 0 sp = 0x7fd0a4001c00 { fd = 12, vxid = 1, client = 194.31.39.161 47799, step = S_STP_WORKING, }, worker = 0x7fd0bc54bc60 { ws = 0x7fd0bc54be60 { id = "wrk", {s,f,r,e} = {0x7fd0bc54b410,0x7fd0bc54b410,(nil),+2048}, }, VCL::method = RECV, VCL::return = abandon, }, ws = 0x7fd0a0090c10 { id = "req", {s,f,r,e} = {0x7fd0a0092268,+232,+59432,+59432}, }, http[req] = { ws = 0x7fd0a0090c10[req] "GET", "/cacheabledata/set_imagehosting1/8/image12088.jpg", "HTTP/1.1", "Host: fryer1.varnish-software.com:6081", "Accept: */*", "Accept-Encoding: gzip", "User-Agent: Mozilla/5.0 (unknown-x86_64-linux-gnu) Siege/3.0.4", "Connection: keep-alive", }, vcl = { srcname = { "input", "Default", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 28 12:33:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Oct 2013 12:33:29 -0000 Subject: [Varnish] #1366: persistence panic: vca_tcp_opt_set(), cache/cache_acceptor.c line 222: Message-ID: <046.4f5b81be0598ee1826ee59e3c9b23187@varnish-cache.org> #1366: persistence panic: vca_tcp_opt_set(), cache/cache_acceptor.c line 222: ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Seen when running the persistence testset in fryer last night: gitref e5cbbedd2d9342595817c1b66b22d1c90e8c60fc {{{ Panic message: Assert error in vca_tcp_opt_set(), cache/cache_acceptor.c line 222: Condition(VTCP_Check(setsockopt(sock, to->level, to->optname, to->ptr, to->sz))) not true. errno = 9 (Bad file descriptor) thread = (cache-acceptor) ident = Linux,3.2.0-51-generic,x86_64,-spersistent,-smalloc,-hcritbit,epoll Backtrace: 0x43845c: sess_close_2str+1109 0x43876d: sess_close_2str+141a 0x40d4c1: _start+a21 0x40dd73: VCA_SetupSess+3e5 0x7f4dfe945e9a: _end+7f4dfe2a66aa 0x7f4dfe672ccd: _end+7f4dfdfd34dd }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Oct 28 14:57:37 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 28 Oct 2013 14:57:37 -0000 Subject: [Varnish] #1364: Assert error in mgt_sigsegv_handler(), mgt/mgt_child.c line 328 In-Reply-To: <046.4236638300da782ed48b50e2dd732f94@varnish-cache.org> References: <046.4236638300da782ed48b50e2dd732f94@varnish-cache.org> Message-ID: <061.568f9baeebd1e9f0acc0089bc68830ef@varnish-cache.org> #1364: Assert error in mgt_sigsegv_handler(), mgt/mgt_child.c line 328 ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): {{{ Oct 28 15:54:34 fryer1 varnishd[23188]: Platform: Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit Oct 28 15:54:35 fryer1 varnishd[23188]: child (23189) Started Oct 28 15:54:36 fryer1 varnishd[23188]: Child (23189) said Child starts Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said *** glibc detected *** /opt/varnish/sbin/varnishd: free(): invalid next size (fast): 0x00007f4bb8020d20 *** Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said ======= Backtrace: ========= Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /lib/x86_64 -linux-gnu/libc.so.6(+0x7eb96)[0x7f4c93e1ab96] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd(ObjIterEnd+0x104)[0x4372aa] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd[0x43f64d] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd(V1D_Deliver+0x7d3)[0x43fe27] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd[0x43b58c] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd(CNT_Request+0x529)[0x43e752] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said *** glibc detected *** /opt/varnish/sbin/varnishd: free(): invalid next size (fast): 0x00007f4be0020c40 *** Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd(HTTP1_Session+0x427)[0x431ca9] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd[0x440f2a] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd[0x441152] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd(SES_pool_accept_task+0x1f9)[0x4416f2] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd(Pool_Work_Thread+0x3cc)[0x43a03a] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd[0x45364c] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /opt/varnish/sbin/varnishd(WRK_thread+0x27)[0x4537a4] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /lib/x86_64 -linux-gnu/libpthread.so.0(+0x7e9a)[0x7f4c94162e9a] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said /lib/x86_64 -linux-gnu/libc.so.6(clone+0x6d)[0x7f4c93e8fccd] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said ======= Memory map: ======== Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 00400000-0049c000 r-xp 00000000 08:01 22282346 /opt/varnish/sbin/varnishd Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 0069b000-0069c000 r--p 0009b000 08:01 22282346 /opt/varnish/sbin/varnishd Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 0069c000-0069f000 rw-p 0009c000 08:01 22282346 /opt/varnish/sbin/varnishd Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 0069f000-006a0000 rw-p 00000000 00:00 0 Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 020fe000-0211f000 rw-p 00000000 00:00 0 [heap] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 0211f000-02176000 rw-p 00000000 00:00 0 [heap] Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 7f4b54000000-7f4b54021000 rw-p 00000000 00:00 0 Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 7f4b54021000-7f4b58000000 ---p 00000000 00:00 0 Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 7f4b58000000-7f4b58031000 rw-p 00000000 00:00 0 Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 7f4b58031000-7f4b5c000000 ---p 00000000 00:00 0 Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 7f4b5c000000-7f4b5c021000 rw-p 00000000 00:00 0 Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 7f4b5c021000-7f4b60000000 ---p 00000000 00:00 0 Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 7f4b60000000-7f4b60032000 rw-p 00000000 00:00 0 Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 7f4b60032000-7f4b64000000 ---p 00000000 00:00 0 Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 7f4b64000000-7f4b64021000 rw-p 00000000 00:00 0 Oct 28 15:54:37 fryer1 varnishd[23188]: Child (23189) said 7f4b64021000-7f4b68000000 ---p 00000000 00:00 0 Oct 28 15:54:38 fryer1 varnishd[23188]: Child (23189) died signal=6 Oct 28 15:54:38 fryer1 varnishd[23188]: Child (23189) Panic message: Assert error in mgt_sigsegv_handler(), mgt/mgt_child.c line 329:#012 Condition(Segmentation fault by instruction at 0x7f4c5c0af1d7) not true.#012thread = (cache-worker)#012ident = Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x438499: sess_close_2str+1106#012 0x4387aa: sess_close_2str+1417#012 0x45a355: MGT_close_sockets+1fc#012 0x7f4c9416acb0: _end+7f4c93acb4c0#012 0x7f4c93eaeb22: _end+7f4c9380f332#012 0x7f4c95101047: _end+7f4c94a61857#012 0x7f4c95101183: _end+7f4c94a61993#012 0x448f2f: VRT_IP_string+c5#012 0x7f4c73dc069c: _end+7f4c73720eac#012 0x446745: VCL_Poll+8ef#012req = 0x7f4c5c090a90 {#012 sp = 0x7f4c58001540, vxid = 1073741826, step = R_STP_RECV,#012 req_body = R_BODY_NONE,#012 restarts = 0, esi_level = 0#012 sp = 0x7f4c58001540 {#012 fd = 19, vxid = 1,#012 client = 194.31.39.161 57166,#012 step = S_STP_WORKING,#012 },#012 worker = 0x7f4c79a4ec60 {#012 ws = 0x7f4c79a4ee60 { #012 id = "wrk",#012 {s,f,r,e} = {0x7f4c79a4e410,0x7f4c79a4e410,(nil),+2048},#012 },#012 VCL::method = RECV,#012 VCL::return = abandon,#012 },#012 ws = 0x7f4c5c090c10 { #012 id = "req",#012 {s,f,r,e} = {0x7f4c5c092268,+224,+59432,+59432},#012 },#012 http[req] = {#012 ws = 0x7f4c5c090c10[req]#012 "GET",#012 "/cacheabledata/set_imagehosting1/8/image5228.jpg",#012 "HTTP/1.1",#012 "Host: fryer1.varnish-software.com:6081",#012 "Accept: */*",#012 "Accept-Encoding: gzip",#012 "User-Agent: Mozilla/5.0 (unknown-x86_64-linux-gnu) Siege/3.0.4",#012 "Connection: close",#012 },#012 vcl = {#012 srcname = {#012 "input",#012 "Default",#012 },#012 },#012},#012 Oct 28 15:54:38 fryer1 varnishd[23188]: Child cleanup complete Oct 28 15:54:38 fryer1 varnishd[23188]: child (23406) Started }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 29 14:41:27 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 29 Oct 2013 14:41:27 -0000 Subject: [Varnish] #1367: Varnish crashes if GET consists from whitespaces only Message-ID: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> #1367: Varnish crashes if GET consists from whitespaces only --------------------+-------------------- Reporter: elurin | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.4 | Severity: normal Keywords: | --------------------+-------------------- Description: If GET parameter consists only from whitespaces a varnish child crashes. Unfortunately, sometimes we have bad queries from clients with whitespaces. Steps to reproduce: 1. Create simple http request with several whitespaces after GET. {{{ vec01g:/etc/varnish# telnet localhost 80 Trying ::1... Connected to localhost.localdomain. Escape character is '^]'. GET Host: example.com Connection closed by foreign host. }}} 2. Varnish crashes with trace: {{{ Oct 29 17:43:23 vec01g Condition((t.b) != 0) not true. Oct 29 17:43:23 vec01g thread = (cache-worker) Oct 29 17:43:23 vec01g ident = Linux,3.8.0-11-na,x86_64,-smalloc,-smalloc,-hcritbit,epoll Oct 29 17:43:23 vec01g Backtrace: Oct 29 17:43:23 vec01g 0x430c28: /usr/sbin/varnishd() [0x430c28] Oct 29 17:43:23 vec01g 0x42d555: /usr/sbin/varnishd() [0x42d555] Oct 29 17:43:23 vec01g 0x42dd79: /usr/sbin/varnishd(http_FilterHeader+0x89) [0x42dd79] Oct 29 17:43:23 vec01g 0x41a755: /usr/sbin/varnishd(CNT_Session+0x7f5) [0x41a755] Oct 29 17:43:23 vec01g 0x432971: /usr/sbin/varnishd() [0x432971] Oct 29 17:43:23 vec01g 0x7fd813a349ca: /lib/libpthread.so.0(+0x69ca) [0x7fd813a349ca] Oct 29 17:43:23 vec01g 0x7fd81379170d: /lib/libc.so.6(clone+0x6d) [0x7fd81379170d] Oct 29 17:43:23 vec01g sp = 0x7fd740489008 { Oct 29 17:43:23 vec01g fd = 3, id = 3, xid = 1901155339, Oct 29 17:43:23 vec01g client = ::1 49391, Oct 29 17:43:23 vec01g step = STP_PIPE, Oct 29 17:43:23 vec01g handling = hash, Oct 29 17:43:23 vec01g err_code = 413, err_reason = (null), Oct 29 17:43:23 vec01g restarts = 1, esi_level = 0 Oct 29 17:43:23 vec01g flags =. Oct 29 17:43:23 vec01g bodystatus = 4 Oct 29 17:43:23 vec01g ws = 0x7fd740489080 {. Oct 29 17:43:23 vec01g id = "sess", Oct 29 17:43:23 vec01g {s,f,r,e} = {0x7fd740489c78,+408,(nil),+262144}, Oct 29 17:43:23 vec01g }, Oct 29 17:43:23 vec01g http[req] = { Oct 29 17:43:23 vec01g ws = 0x7fd740489080[sess] Oct 29 17:43:23 vec01g "GET", Oct 29 17:43:23 vec01g " Oct 29 17:43:23 vec01g Host: example.com Oct 29 17:43:23 vec01g host: example-internal.com", Oct 29 17:43:23 vec01g "host: example-internal.com", Oct 29 17:43:23 vec01g }, Oct 29 17:43:23 vec01g worker = 0x7fd74116da90 { Oct 29 17:43:23 vec01g ws = 0x7fd74116dcc8 {. Oct 29 17:43:23 vec01g id = "wrk", Oct 29 17:43:23 vec01g {s,f,r,e} = {0x7fd741155a20,0x7fd741155a20,(nil),+65536}, Oct 29 17:43:23 vec01g }, Oct 29 17:43:23 vec01g http[bereq] = { Oct 29 17:43:23 vec01g ws = 0x7fd74116dcc8[wrk] Oct 29 17:43:23 vec01g "GET", Oct 29 17:43:23 vec01g " Oct 29 17:43:23 vec01g Host: example.com Oct 29 17:43:23 vec01g host: example-internal.com", Oct 29 17:43:23 vec01g }, Oct 29 17:43:23 vec01g }, Oct 29 17:43:23 vec01g vcl = { Oct 29 17:43:23 vec01g srcname = { Oct 29 17:43:23 vec01g "input", Oct 29 17:43:23 vec01g "Default", Oct 29 17:43:23 vec01g "/etc/varnish/ban.list", Oct 29 17:43:23 vec01g "/etc/varnish/backends-load.vcl", Oct 29 17:43:23 vec01g }, Oct 29 17:43:23 vec01g }, Oct 29 17:43:23 vec01g }, Oct 29 13:43:23 vec01g varnishd[4942]: Child cleanup complete }}} Varnish version: 3.0.4 Ident: ident = Linux,3.8.0-11-na,x86_64,-smalloc,-smalloc,-hcritbit,epoll Of course, we can normalize queries in the vec_recv section with "if (req.url !~ "^/") {error 400;}" match,but this is a wooden leg. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 29 15:19:27 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 29 Oct 2013 15:19:27 -0000 Subject: [Varnish] #1367: Varnish crashes if GET consists from whitespaces only In-Reply-To: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> References: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> Message-ID: <059.50ae72735f3bcb6adcb8678e56237f13@varnish-cache.org> #1367: Varnish crashes if GET consists from whitespaces only --------------------+-------------------- Reporter: elurin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by lkarsten): I'm not able to reproduce this on my system with stock 3.0.4. Can you please provide your VCL? (either here or to security at varnish- cache.org) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 29 15:41:24 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 29 Oct 2013 15:41:24 -0000 Subject: [Varnish] #1367: Varnish crashes if GET consists from whitespaces only In-Reply-To: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> References: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> Message-ID: <059.144710f376a0e99374c60286a390a593@varnish-cache.org> #1367: Varnish crashes if GET consists from whitespaces only --------------------+-------------------- Reporter: elurin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by elurin): I've reproduced this problem with your build 3.0.4-1~lucid for Ubuntu 10.04 (lucid) from your official repository. Also, I've sent vcl to your email. Thank you! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 29 15:51:52 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 29 Oct 2013 15:51:52 -0000 Subject: [Varnish] #1367: Varnish crashes if GET consists from whitespaces only In-Reply-To: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> References: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> Message-ID: <059.4b3fd9c35b91d928f2665290cfc80b42@varnish-cache.org> #1367: Varnish crashes if GET consists from whitespaces only --------------------+-------------------- Reporter: elurin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by lkarsten): Short term workaround to avoid a panic: {{{ sub vcl_error { if (obj.status >= 400 && obj.status < 500) { return(deliver); } } }}} append this before any other vcl_error code is run. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 29 15:57:46 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 29 Oct 2013 15:57:46 -0000 Subject: [Varnish] #1367: Varnish crashes if GET consists from whitespaces only In-Reply-To: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> References: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> Message-ID: <059.3b703e08de919b9656d5c4e738872540@varnish-cache.org> #1367: Varnish crashes if GET consists from whitespaces only --------------------+-------------------- Reporter: elurin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by elurin): Thank you, it works: {{{ vec01g.load:/var/log# telnet localhost 80 Trying ::1... Connected to localhost.localdomain. Escape character is '^]'. GET Host: example.com HTTP/1.1 413 Request Entity Too Large Accept-Ranges: bytes Date: Tue, 29 Oct 2013 15:57:14 GMT Connection: close Connection closed by foreign host. vec01g.load:/var/log# }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Oct 29 16:12:13 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 29 Oct 2013 16:12:13 -0000 Subject: [Varnish] #1367: Varnish crashes if GET consists from whitespaces only In-Reply-To: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> References: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> Message-ID: <059.bb9075c9fe4904a3d50f9d51d79ba784@varnish-cache.org> #1367: Varnish crashes if GET consists from whitespaces only --------------------+-------------------- Reporter: elurin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by martin): Attached diff seems to fix the code issue. I can't see any reason to not do the 400 return which causes Varnish to hang up when the URL is missing. Test case still missing though. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 30 10:26:28 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Oct 2013 10:26:28 -0000 Subject: [Varnish] #1367: Varnish crashes if GET consists from whitespaces only In-Reply-To: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> References: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> Message-ID: <059.97c21c41761a99c02d42f6dd7b9c4f49@varnish-cache.org> #1367: Varnish crashes if GET consists from whitespaces only --------------------+---------------------------------------- Reporter: elurin | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [9c9a9904bdb56b62017f338baf9c8e906b88dcac]: {{{ #!CommitTicketReference repository="" revision="9c9a9904bdb56b62017f338baf9c8e906b88dcac" Make up our mind: Any req.* we receive from the client with fundamental trouble gets failed back without VCL involvement. Fixes #1367 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Oct 30 12:53:11 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 30 Oct 2013 12:53:11 -0000 Subject: [Varnish] #1367: Varnish crashes if GET consists from whitespaces only In-Reply-To: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> References: <044.8af54b63fa525d70fddb34bedbe17471@varnish-cache.org> Message-ID: <059.7a0dd140760965b23f388d15abdfc44f@varnish-cache.org> #1367: Varnish crashes if GET consists from whitespaces only --------------------+---------------------------------------- Reporter: elurin | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Comment (by Martin Blix Grydeland ): In [4bd5b7991bf602a6c46dd0d65fc04d4b8d9667a6]: {{{ #!CommitTicketReference repository="" revision="4bd5b7991bf602a6c46dd0d65fc04d4b8d9667a6" Make up our mind: Any req.* we receive from the client with fundamental trouble gets failed back without VCL involvement. Fixes #1367 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Oct 31 13:51:58 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 31 Oct 2013 13:51:58 -0000 Subject: [Varnish] #1368: Assert error in object_cmp(), cache/cache_expire.c line 540 Message-ID: <046.3b0f279a2d861e83c5c8d5b0b9ae54b5@varnish-cache.org> #1368: Assert error in object_cmp(), cache/cache_expire.c line 540 ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- In an attempt at reproducing the VBO_waitlen() panic reported by "jw" on #varnish-hacking yesterday, fryer found another panic in master. gitref 645c1ca. vcl is default, only a backend definition. startup args: /opt/varnish/sbin/varnishd -T localhost:6082 -a :6081 -f /opt/varnish/etc/testsuite.vcl -smalloc,1M -p default_ttl=86400 -p thread_pool_min=100 note the tiny malloc. {{{ Panic message: Assert error in object_cmp(), cache/cache_expire.c line 540: Condition(((aa))->magic == (0x4d301302)) not true. thread = (cache-timeout) ident = Linux,3.2.0-51-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x438655: sess_close_2str+1106 0x438966: sess_close_2str+1417 0x421c72: EXP_NukeOne+fd7 0x7f14209fa52d: _end+7f1420359d3d 0x7f14209fad9b: _end+7f142035a5ab 0x421420: EXP_NukeOne+785 0x422012: EXP_NukeOne+1377 0x453571: WRK_TrySumStat+15f 0x7f141fa60e9a: _end+7f141f3c06aa 0x7f141f78d3fd: _end+7f141f0ecc0d }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator