From varnish-bugs at varnish-cache.org Mon Sep 1 07:08:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 07:08:24 -0000 Subject: [Varnish] #1581: Duplicate SLT_Begin log records In-Reply-To: <043.8743f789155e60115173c7fa6383b726@varnish-cache.org> References: <043.8743f789155e60115173c7fa6383b726@varnish-cache.org> Message-ID: <058.ed452a7d37725a2f4d7caec7e3745c76@varnish-cache.org> #1581: Duplicate SLT_Begin log records ----------------------+------------------------- Reporter: daghf | 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: This is actually varnish working as it should. We assume that a request is going to happen instantly on TCP connection accept and allocate a working thread right away. If more than timeout_linger time elapses without traffic, we release the working thread and hand the connection to the waiter thread. By default timeout_linger is 50 msec, because it is also how long a working thread lingers on the session after sending a response, just in case another request is incoming. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 07:18:15 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 07:18:15 -0000 Subject: [Varnish] #1520: m00011.vtc fails on x86_64 In-Reply-To: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> References: <046.929f5151093fa67f4bf5581f3f019af2@varnish-cache.org> Message-ID: <061.96db7a874e16e6cddb4986213113d64c@varnish-cache.org> #1520: m00011.vtc fails on x86_64 -------------------------+----------------------- Reporter: yoloseem | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishtest | Version: 4.0.0 Severity: normal | Resolution: Keywords: | -------------------------+----------------------- Comment (by phk): I have changed the test-case slighty, hoping that we can find out what's going on here. Can you try with -trunk again and see if it still fails ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 07:35:41 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 07:35:41 -0000 Subject: [Varnish] #1466: struct req memory leak In-Reply-To: <044.405f83ccd9aea5f6bdeca16bd684d5a1@varnish-cache.org> References: <044.405f83ccd9aea5f6bdeca16bd684d5a1@varnish-cache.org> Message-ID: <059.5fc25729cc4a695b33de90625e669902@varnish-cache.org> #1466: struct req memory leak ----------------------+---------------------------------------- Reporter: martin | 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 [9dd5d273b6b5aa44705778033701ff04be79bcf9]: {{{ #!CommitTicketReference repository="" revision="9dd5d273b6b5aa44705778033701ff04be79bcf9" Don't leak struct req if we cannot restart it from a waiting list. Fixes: #1466 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 08:10:31 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 08:10:31 -0000 Subject: [Varnish] #1414: r01391.vtc is unstable In-Reply-To: <046.d5a045f162e52112b625f28f45c5fb5b@varnish-cache.org> References: <046.d5a045f162e52112b625f28f45c5fb5b@varnish-cache.org> Message-ID: <061.9930d0498fbab6e0de2588d064db2711@varnish-cache.org> #1414: r01391.vtc is unstable -------------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [69425d5ec6b0c7870e0e967aa3b3c56cd4724c1c]: {{{ #!CommitTicketReference repository="" revision="69425d5ec6b0c7870e0e967aa3b3c56cd4724c1c" Reinstate this testcase, but make the servers failure to deliver non-fatal. Fixes: #1414 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 09:13:01 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 09:13:01 -0000 Subject: [Varnish] #1586: Can still loose headers when running out of workspace in set xxx.http Message-ID: <043.4d2be4d8abd2b08850fd215fc93be98e@varnish-cache.org> #1586: Can still loose headers when running out of workspace in set xxx.http ----------------------+------------------- Reporter: slink | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- headers can still get silently lost (with LostHeader logging) when using set xxx.http see attached vtc -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:03:40 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:03:40 -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.c049e0ef4cc931e7875bf8950f5a1c73@varnish-cache.org> #1358: High n-expired objects ----------------------+------------------------- Reporter: superjmt | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by martin): * status: new => closed * resolution: => worksforme Comment: Not heard anything from reporter. Closing. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:07:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:07:50 -0000 Subject: [Varnish] #1369: Spinning thread while esi+gzip fetch In-Reply-To: <046.a959baf0eee18a6849c8587f6527406f@varnish-cache.org> References: <046.a959baf0eee18a6849c8587f6527406f@varnish-cache.org> Message-ID: <061.2b38eaa68da7a536b83ae09ebf16a35a@varnish-cache.org> #1369: Spinning thread while esi+gzip fetch ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.4 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): I believe this is fixed in 3.0-git. Keep this ticket around until we've released 3.0.6. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:09:02 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:09:02 -0000 Subject: [Varnish] #1406: Setting a header to a falsy value than getting it returns true In-Reply-To: <053.67b679cfde5eb48e50df6e81d4e36d86@varnish-cache.org> References: <053.67b679cfde5eb48e50df6e81d4e36d86@varnish-cache.org> Message-ID: <068.5d9c079bb30b8249b52dccb01c85d8cb@varnish-cache.org> #1406: Setting a header to a falsy value than getting it returns true -----------------------------+-------------------- Reporter: brandonwamboldt | Owner: slink Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 3.0.4 Severity: normal | Resolution: Keywords: | -----------------------------+-------------------- Changes (by slink): * owner: => slink -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:14:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:14:21 -0000 Subject: [Varnish] #1406: Setting a header to a falsy value than getting it returns true In-Reply-To: <053.67b679cfde5eb48e50df6e81d4e36d86@varnish-cache.org> References: <053.67b679cfde5eb48e50df6e81d4e36d86@varnish-cache.org> Message-ID: <068.39db561596478c0da208731392a2af2d@varnish-cache.org> #1406: Setting a header to a falsy value than getting it returns true -----------------------------+----------------------- Reporter: brandonwamboldt | Owner: lkarsten Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 3.0.4 Severity: normal | Resolution: Keywords: | -----------------------------+----------------------- Changes (by slink): * owner: slink => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:23:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:23:04 -0000 Subject: [Varnish] #1407: Varnishd loses the ability to write to shared memory if you try to start it twice In-Reply-To: <053.90c213397c3b87bfe5b4975288bb67b4@varnish-cache.org> References: <053.90c213397c3b87bfe5b4975288bb67b4@varnish-cache.org> Message-ID: <068.d5e386f4c17a0e66e86d4d00a5ce863f@varnish-cache.org> #1407: Varnishd loses the ability to write to shared memory if you try to start it twice -----------------------------+-------------------- Reporter: brandonwamboldt | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -----------------------------+-------------------- Changes (by phk): * owner: lkarsten => phk Comment: discussed today: solution will be to build VSM under temp name and only rename after successful startup. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:25:14 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:25:14 -0000 Subject: [Varnish] #1420: Ban/Fetch race In-Reply-To: <041.b95ccb65dcdc701e3d0812123d5cc95f@varnish-cache.org> References: <041.b95ccb65dcdc701e3d0812123d5cc95f@varnish-cache.org> Message-ID: <056.c41952b1259263d45a6d779595c6969f@varnish-cache.org> #1420: Ban/Fetch race ----------------------+------------------------- Reporter: phk | Owner: phk 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: After lots of thinking and brief discussion, we have decided to not do anything about this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:32:19 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:32:19 -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.a86d10cfb4d0729fad79525215e63b73@varnish-cache.org> #1364: Assert error in mgt_sigsegv_handler(), mgt/mgt_child.c line 328 ----------------------+--------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: Error handler works as expected, and this particular error we haven't seen for a long while. Most likely fixed in unrelated work. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:38:15 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:38:15 -0000 Subject: [Varnish] #1449: Assert error in ban_check_object(), cache/cache_ban.c line 915 In-Reply-To: <046.7113ebd1ce10ac27acc0986067f77f64@varnish-cache.org> References: <046.7113ebd1ce10ac27acc0986067f77f64@varnish-cache.org> Message-ID: <061.140ba0afb37d2d2b3c43ca0d659bdcc8@varnish-cache.org> #1449: Assert error in ban_check_object(), cache/cache_ban.c line 915 ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: reopened Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------------- Comment (by lkarsten): Discussed on bugwash today. I'll rerun this on fryer on the new test servers. If not reproduceable, close it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:38:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:38:27 -0000 Subject: [Varnish] #1449: Assert error in ban_check_object(), cache/cache_ban.c line 915 In-Reply-To: <046.7113ebd1ce10ac27acc0986067f77f64@varnish-cache.org> References: <046.7113ebd1ce10ac27acc0986067f77f64@varnish-cache.org> Message-ID: <061.7f788f3b0100249e4e76fdf27ca30689@varnish-cache.org> #1449: Assert error in ban_check_object(), cache/cache_ban.c line 915 ----------------------+---------------------------------- Reporter: lkarsten | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Changes (by lkarsten): * status: reopened => new * owner: Poul-Henning Kamp => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:42:46 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:42:46 -0000 Subject: [Varnish] #1458: Assert error in VBF_Fetch(), cache/cache_fetch.c line 863 In-Reply-To: <046.25afbe3c30abacc2e1fc42ff5cfc5956@varnish-cache.org> References: <046.25afbe3c30abacc2e1fc42ff5cfc5956@varnish-cache.org> Message-ID: <061.3abaad1332170794a748f1fc2ddd9dd4@varnish-cache.org> #1458: Assert error in VBF_Fetch(), cache/cache_fetch.c line 863 ----------------------+---------------------------------- Reporter: lkarsten | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: worksforme Keywords: | ----------------------+---------------------------------- Changes (by martin): * status: reopened => closed * resolution: => worksforme Comment: Closing believed to have been fixed. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:43:17 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:43:17 -0000 Subject: [Varnish] #1453: Assert error in exp_inbox(), cache/cache_expire.c line 430 In-Reply-To: <046.9b9a21329f678cd8f9078c0c57250b30@varnish-cache.org> References: <046.9b9a21329f678cd8f9078c0c57250b30@varnish-cache.org> Message-ID: <061.4b0fead10866acdad3812b095608672f@varnish-cache.org> #1453: Assert error in exp_inbox(), cache/cache_expire.c line 430 ----------------------+------------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by martin): * status: new => closed * resolution: => worksforme Comment: Closing believed to have been fixed. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:54:56 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:54:56 -0000 Subject: [Varnish] #1465: Empty chunked response on storage failure In-Reply-To: <046.2a16722930c8a8f8903e2d31a85fb9eb@varnish-cache.org> References: <046.2a16722930c8a8f8903e2d31a85fb9eb@varnish-cache.org> Message-ID: <061.bfaefcca86d606f839d1d0f5986d5f2a@varnish-cache.org> #1465: Empty chunked response on storage failure ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by slink): I think this might relate to #1506 with respect to the question of how we should close a client connection when we determine that we have a fatal error while streaming (here: no memory - #1506: backend sent less than announced via C-L) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 10:55:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 10:55:50 -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.c5dc92dbf7d2689620e1c6a4b5905034@varnish-cache.org> #1354: Segfault in libvgz.so --------------------+------------------------- Reporter: ixos | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 3.0.4 Severity: major | Resolution: worksforme Keywords: | --------------------+------------------------- Changes (by fgsch): * status: new => closed * resolution: => worksforme Comment: No answer in 3 months and cannot reproduce it. Closing. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 11:17:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 11:17:57 -0000 Subject: [Varnish] #1587: Can't compile VCL Message-ID: <050.0c31d23875513eae9b182858483f72f3@varnish-cache.org> #1587: Can't compile VCL --------------------------+---------------------- Reporter: antonbabenko | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.0 | Severity: normal Keywords: vcl, compile | --------------------------+---------------------- This is the minumum vcl_recv function which I can't get compile on Mac 10.9 with Varnish installed via homebrew. varnishd (varnish-4.0.0 revision 2acedeb) --- vcl 4.0; sub vcl_recv { if (req.http.Authenticate || req.http.Authorization) { ????return (pass); ??} } --- The error message is: Running VCC-compiler failed, exit 1 VCL compilation failed Message from VCC-compiler: Not running as root, no priv-sep Syntax error at ('input' Line 23 Pos 1) ????return (pass); All other parts on that VCL works as they should. Varnish bug or specific to homebrew ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 11:19:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 11:19:57 -0000 Subject: [Varnish] #1588: Timestamp records are recorded before SLT_Begin on pipelining requests Message-ID: <044.1aadb42d75ceac75a638d12038720fae@varnish-cache.org> #1588: Timestamp records are recorded before SLT_Begin on pipelining requests ----------------------+------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Timestamp records are recorded before SLT_Begin on pipelining requests. This causes the batch records to be recorded as all belonging to VXID 0 instead of the VXID that the request will get once the it is assigned. The log API will then skip that entire batch of records, hiding these log requests on anything except -g raw. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 12:53:06 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 12:53:06 -0000 Subject: [Varnish] #1465: Empty chunked response on storage failure In-Reply-To: <046.2a16722930c8a8f8903e2d31a85fb9eb@varnish-cache.org> References: <046.2a16722930c8a8f8903e2d31a85fb9eb@varnish-cache.org> Message-ID: <061.201ab2a85d1a6176b5081d042e2d94b7@varnish-cache.org> #1465: Empty chunked response on storage failure ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by martin): I was tasked during todays bugwash with writing a test case to make sure we don't close it with a 0 chunked frame leaving no indication whatsoever to the client. I found that c00062.vtc already tests this specific case and seems to work as intended. The question of whether we should try to RST the connection as well remains though. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 13:02:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 13:02:11 -0000 Subject: [Varnish] #1589: Implements For Preventing Injuries While Muscle Building GMAX Supplement Critics Message-ID: <044.d6de33757139f93c13011161fd32fa49@varnish-cache.org> #1589: Implements For Preventing Injuries While Muscle Building GMAX Supplement Critics --------------------+------------------------- Reporter: jani11 | Type: enhancement Status: new | Priority: low Milestone: | Component: build Version: 1.0 | Severity: trivial Keywords: GMAX | --------------------+------------------------- Sports hernia can hit sports athletes from all walks of life, but it is still poorly understood condition. Alicia Filley sorted fact from fiction and to provide training to strengthen the pelvic area and keep the "bulge" in the distance. Hernia is poaching of organs or tissue from the abdomen through a weakened area in the abdominal wall '''[http://gmaxreclameaqui.com/ GMAX muscles]''' or broken. Herniation can be caused by anything that increases intra-abdominal pressure such as coughing or heavy work. Sports hernia, however, is more difficult to determine. Athlete hernia also known as athletic pubalgia, Gilmore groin or hernia early is "universal" phrase for undiagnosed chronic groin pain in athletes. Athletes may complain of pain in the groin for a few months, without mentioning a specific mechanism of injury. The pain usually goes away with rest, but resumed immediately with a return to the sport. Conservative treatment does not solve the pain management. Physical examination shows, however, as a rule, is not a real hernia because there is a consensus among researchers and practitioners who actually sportsman hernia! anatomy Stomach area where the leg meets the trunk. This area is supported by a skeleton of the pelvis and hips, where the transfer of power from above while sporting activities that require strong Starts, stops, and feet, such as football and hockey. Pool consists of two bones, together with the holy bones form a ring below the torso. In front hip bones connected to the pubic symphysis joint (Figure 1). Trunk abdominal muscles attach to bones pubian.Abdominis upper rectus in the central abdominal muscles comes as a wide, flat, and considerably narrows his introduction to the pubis, causing the concentration of forces near the pubic symphysis joint. Hip adductor muscles attached to the lower part of the pubic bone. The largest of these muscles, adductor longus, rectus abdominis immediately below. These two muscle aponeurosis separated or fibrous cap that connects muscle to each other and resulting bone pubian.Longus right abdominal muscles antagonistic opposing force vectors generated by each. This opposition, especially significant during sports that require strong and starts kicking on and off, producing a constant voltage at the symphysis. anatomy of the inguinal Another anatomical feature is the presence of a significant groin groin. It runs between the layers of the anterior abdominal wall (internal and external oblique muscles) and the posterior abdominal wall (consisting of fascia and tendon conjugate - the internal oblique muscle and tendon runs total) .Cordonul sperm pass through the groin in males and the round ligament in women. Theory of sports hernia Theory number 1 - Athletic pubalgia literally "a pain in the pubic area" is that some researchers and practitioners prefer to call chronic pain in the groin. The idea is that the pain comes from the rectus abdominis muscle tears or long leads tendons or fascia jointly shared by both. Since these muscles are working in opposite directions and have a common fiber coating, even micro-tears in one of them will affect the other. As a result of the instability of the pelvis at the point where shear forces more and more of the other weakened area. (Note the vicinity of the inguinal canal lateral line of the border.) Trying to standardize the diagnosis of sports pubalgia, a group of radiologists in health centers and universities around the world to determine the radiographic parameters found on magnetic resonance imaging (MRI) in patients with athletic pubalgia. Recent advances in MRI allows visualization of injury to the lateral border of the rectum is not mentioned above (1). Doctors noticed a tear in one degree or another in patients at minimal muscle tears to complete tears in both the rectus and adductor longus muscles. MRI showed herniation rarely true in these patients. These practitioners believe that the symptoms of a hernia that occur near the rectum groin. They also suggest that, as soon as the weakening of the rectus abdominis or adductor long or endanger the stability of the pelvis, the strain can also occur in other muscles, trying to ensure the stability of the compensation. Because in reality there are many other syndromes that manifest as pain in the groin, screening MRI is recommended to rule out other problems. If nothing appears, doctors recommend a thorough MRI symphysis. Theory number 2 - Department of Surgery at Drexel University in Philadelphia, Pennsylvania, doctors examined two decades of the patient's history of sports hernia and noted the progress as the diagnosis and treatment. They report that at the present time to see ten times the number of patients in the clinic for sports hernias than they did 20 years ago (2). They also agree that the sports hernia is a misnomer; they perform some actual hernia in patients with chronic pain groin. This practice has been found that chronic groin pain comes from the destruction of many complex pubic muscles. In 2006, they examined MRIs of 100 patients with athletic pubalgia (3). The results are shown rectus abdominis not only defects and adductor longus muscles, but also in the general pubic other adductor muscles of the foot and the right thigh (see Table 1). Theory # 3 - Theory 1 and 2 centers around the defects resulting pubis and foot muscles. Nevertheless, from the University of Insubria in Italy, a researcher sites of various origins of chronic pain groin faced by many athletes. Campanelli postulates that because the adductors are usually stronger than the muscles of the abdomen, pelvis, crossing the shear forces in the sport because football in violation of or weakening of the muscles and fascia to the posterior abdominal wall (4). The surgeon prefers to be called chronic pain in the groin pubic groin pain. '''http://gmaxreclameaqui.com/''' -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 1 14:47:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 01 Sep 2014 14:47:08 -0000 Subject: [Varnish] #1407: Varnishd loses the ability to write to shared memory if you try to start it twice In-Reply-To: <053.90c213397c3b87bfe5b4975288bb67b4@varnish-cache.org> References: <053.90c213397c3b87bfe5b4975288bb67b4@varnish-cache.org> Message-ID: <068.a35a5d374563d707088f2e80dfd7e7a0@varnish-cache.org> #1407: Varnishd loses the ability to write to shared memory if you try to start it twice -----------------------------+--------------------- Reporter: brandonwamboldt | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | -----------------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [39805b604e842b15059f31d56b71277cd8a4b7fb]: {{{ #!CommitTicketReference repository="" revision="39805b604e842b15059f31d56b71277cd8a4b7fb" Don't rename the VSM file into place until we have started the child process during startup. Fixes #1407 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 2 10:42:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Sep 2014 10:42:08 -0000 Subject: [Varnish] #1584: varnishncsa: format_requestline missing whitespace In-Reply-To: <043.005d215214c91003c1a275be2fd711ca@varnish-cache.org> References: <043.005d215214c91003c1a275be2fd711ca@varnish-cache.org> Message-ID: <058.129ddd38b2edf09df3595ad2cc5da508@varnish-cache.org> #1584: varnishncsa: format_requestline missing whitespace -------------------------+-------------------------------------------- Reporter: stone | Owner: Lasse Karstensen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------- Changes (by Lasse Karstensen ): * status: new => closed * owner: => Lasse Karstensen * resolution: => fixed Comment: In [39f6f3622fd4b880c4149c576b44ce4ed475d6ba]: {{{ #!CommitTicketReference repository="" revision="39f6f3622fd4b880c4149c576b44ce4ed475d6ba" Do not log garbage requests. Requests that end up in the hard "400 Bad Request" handling used to be logged with incomplete data. (no method, maybe no path, possibly no proto, and no response status) Port scans or anything sending a byte and a linefeed would be logged. Since this is used for logging access to a web site, it makes more sense to skip these garbage requests. Fixes: #1584 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 2 15:34:47 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Sep 2014 15:34:47 -0000 Subject: [Varnish] #1576: varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.ca9efa3de7330fee507c94527ed02113@varnish-cache.org> #1576: varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+----------------------- Reporter: abdi | Owner: fgsch Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Changes (by fgsch): * status: needinfo => assigned Comment: Testcase attached. Cannot reproduce with 3.0 or pcre alone (so far). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 2 15:44:14 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Sep 2014 15:44:14 -0000 Subject: [Varnish] #1587: Can't compile VCL In-Reply-To: <050.0c31d23875513eae9b182858483f72f3@varnish-cache.org> References: <050.0c31d23875513eae9b182858483f72f3@varnish-cache.org> Message-ID: <065.be62cbf781a78affd113ee41e7793b0e@varnish-cache.org> #1587: Can't compile VCL --------------------------+----------------------- Reporter: antonbabenko | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: Keywords: vcl, compile | --------------------------+----------------------- Changes (by fgsch): * status: new => needinfo Comment: Can you upload the failing VCL as it is (no copy-paste)? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 2 16:43:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Sep 2014 16:43:53 -0000 Subject: [Varnish] #1576: varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.c5f3f95ba27986f7ac754e780a80b0b4@varnish-cache.org> #1576: varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+----------------------- Reporter: abdi | Owner: fgsch Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by fgsch): This is actually related to the thread_pool_stack size. Bumping the value to 49k make the test work. Lowering pcre_match_limit makes the match fail without crashing. Should we reduce the pcre_match_limit to something more sensible? 10000 seems like a rather large value. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 2 19:13:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Sep 2014 19:13:29 -0000 Subject: [Varnish] #1587: Can't compile VCL In-Reply-To: <050.0c31d23875513eae9b182858483f72f3@varnish-cache.org> References: <050.0c31d23875513eae9b182858483f72f3@varnish-cache.org> Message-ID: <065.be43d50e853fe673cc7cae86a278c9c3@varnish-cache.org> #1587: Can't compile VCL --------------------------+----------------------- Reporter: antonbabenko | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: Keywords: vcl, compile | --------------------------+----------------------- Comment (by antonbabenko): Magic. Reboot helped. Probably it was something wrong with permission of compiler. Can't reproduce anymore. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 2 19:43:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Sep 2014 19:43:59 -0000 Subject: [Varnish] #1587: Can't compile VCL In-Reply-To: <050.0c31d23875513eae9b182858483f72f3@varnish-cache.org> References: <050.0c31d23875513eae9b182858483f72f3@varnish-cache.org> Message-ID: <065.578aff41f154d5d6f07fc066edc94bf2@varnish-cache.org> #1587: Can't compile VCL --------------------------+---------------------- Reporter: antonbabenko | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.0 Severity: normal | Resolution: invalid Keywords: vcl, compile | --------------------------+---------------------- Changes (by slink): * status: needinfo => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 2 19:45:47 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 02 Sep 2014 19:45:47 -0000 Subject: [Varnish] #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 (was: varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1) In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.6809b47a248a46947f9234b6caed1b85@varnish-cache.org> #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+----------------------- Reporter: abdi | Owner: fgsch Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+----------------------- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 3 16:00:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 03 Sep 2014 16:00:27 -0000 Subject: [Varnish] #1590: ESI does not handle C-L 0 and C-E gzip Message-ID: <043.caca5a4c3e722f0f36772cbca141b8fd@varnish-cache.org> #1590: ESI does not handle C-L 0 and C-E gzip --------------------+--------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Keywords: --------------------+--------------------- This case is handled in the non-esi path but not in ESI. Patch attached. This also converts some checks into asserts as the VFP code won't be pushed in those situations. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 4 10:30:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Sep 2014 10:30:21 -0000 Subject: [Varnish] #1591: varnishtop contains duplicate entries Message-ID: <041.63b5bb01c6c5c9f16226141d9ddcb037@varnish-cache.org> #1591: varnishtop contains duplicate entries -------------------+-------------------- Reporter: kwy | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.1 | Severity: normal Keywords: | -------------------+-------------------- The aggregation in varnishtop doesn't seem to work 100%. for instance, running the classic varnishtop -i BerespURL results in a number of lines with the same URL and different counts. Some requests aren't aggregated correctly so that you get multiple lines per entry. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 4 18:20:51 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Sep 2014 18:20:51 -0000 Subject: [Varnish] #1538: vcc_ParseImport still requires exact VMOD_ABI_Version match In-Reply-To: <046.4c2cb40392bce428250c0ea1ab787adc@varnish-cache.org> References: <046.4c2cb40392bce428250c0ea1ab787adc@varnish-cache.org> Message-ID: <061.ad48a1b9a8bf21b5d82c9eac68b63a16@varnish-cache.org> #1538: vcc_ParseImport still requires exact VMOD_ABI_Version match ----------------------+--------------------------------------------- Reporter: askalski | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * status: new => closed * owner: => Federico G. Schwindt * resolution: => fixed Comment: In [e10d234cfea61acbdbc8a56e8ed6450850dd051c]: {{{ #!CommitTicketReference repository="" revision="e10d234cfea61acbdbc8a56e8ed6450850dd051c" Relax the vmod abi check if we are not in master For master we retain the more strict check in case we forget to bump the API version as discussed on irc. Implementation idea from scoof. Fixes #1538 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 4 22:43:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 04 Sep 2014 22:43:54 -0000 Subject: [Varnish] #1590: ESI does not handle C-L 0 and C-E gzip In-Reply-To: <043.caca5a4c3e722f0f36772cbca141b8fd@varnish-cache.org> References: <043.caca5a4c3e722f0f36772cbca141b8fd@varnish-cache.org> Message-ID: <058.e941afa87200674c45b0172ff4955ae9@varnish-cache.org> #1590: ESI does not handle C-L 0 and C-E gzip --------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+-------------------- Changes (by fgsch): * version: unknown => trunk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 5 13:50:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 05 Sep 2014 13:50:23 -0000 Subject: [Varnish] #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: Message-ID: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: -------------------+--------------------- Reporter: olli | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.0.1 | Severity: blocker Keywords: | -------------------+--------------------- Hi, I want to switch from varnish 3.0.4 to varnish-4.0.1 but I get the following errors in 4.0.1: @400000005409907619329984 Child (7530) died signal=6 @40000000540990761933417c Child (7530) Panic message: @40000000540990761933417c Assert error in WS_Release(), cache/cache_ws.c line 225: @400000005409907619334564 Condition(bytes <= ws->e - ws->f) not true. @40000000540990761933494c thread = (cache-worker) @40000000540990761933494c ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll @400000005409907619334d34 Backtrace: @400000005409907619334d34 0x433fe5: pan_ic+0xc5 @400000005409907619334d34 0x44b573: WS_Release+0xb3 @40000000540990761933511c 0x442e28: VRT_IP_string+0x68 @400000005409907619336c74 0x7f182a0d328e: ./vcl.0aGwBrPz.so(VGC_function_vcl_deliver+0xae) [0x7f182a0d328e] @40000000540990761933705c 0x440817: vcl_call_method+0x187 @40000000540990761933705c 0x441728: VCL_deliver_method+0x48 @400000005409907619337444 0x437e2e: cnt_deliver+0x1ce @400000005409907619337444 0x438531: CNT_Request+0x111 @40000000540990761933782c 0x41a510: ESI_Deliver+0x7d0 @40000000540990761933782c 0x43b2a8: V1D_Deliver+0x368 @40000000540990761933ddbc req = 0x7f181fc9a020 { @40000000540990761933e1a4 sp = 0x7f181ec1b520, vxid = 1073872940, step = R_STP_DELIVER, @40000000540990761933e58c req_body = R_BODY_NONE, @40000000540990761933e58c err_code = 503, err_reason = (null), @40000000540990761933e58c restarts = 0, esi_level = 1 @40000000540990761933e974 sp = 0x7f181ec1b520 { @40000000540990761933e974 fd = 29, vxid = 131085, @40000000540990761933ed5c client = 193.27.50.88 36722, @40000000540990761933ed5c step = S_STP_WORKING, @4000000054099076193400e4 }, @4000000054099076193400e4 worker = 0x7f1823d1ec50 { @4000000054099076193404cc ws = 0x7f1823d1ee68 { @4000000054099076193404cc id = "wrk", @4000000054099076193404cc {s,f,r,e} = {0x7f1823d1e450,0x7f1823d1e450,(nil),+2048}, @400000005409907619342024 }, @400000005409907619342024 VCL::method = DELIVER, @40000000540990761934240c VCL::return = abandon, @40000000540990761934240c }, @40000000540990761934240c ws = 0x7f181fc9a1b8 { @4000000054099076193427f4 id = "req", @4000000054099076193427f4 {s,f,r,e} = {0x7f181fc9c010,+56,(nil),+57360}, @400000005409907619342bdc }, @400000005409907619342bdc http[req] = { @400000005409907619342bdc ws = 0x7f181fc671b8[req] @400000005409907619343f64 "GET", @400000005409907619343f64 "/esi/topflop.htn?esiPermId=252&typ=mostclickedSearch&ajax=10&limit=10&divId=USFMostClickedSearch&seite=zertifikate", @40000000540990761934434c "HTTP/1.1", @400000005409907619344734 "Accept: */*", @400000005409907619344734 "Accept-Language: de-DE", @400000005409907619344b1c "Pragma: no-cache", @400000005409907619344b1c "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB7.4; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E)", @400000005409907619346e44 "Via: 1.1 komsrv:3128 (KEN!), 1.1 idssquid17.services.datevnet.de (squid)", @40000000540990761934722c "Cache-Control: no-cache", @40000000540990761934722c "Connection: keep-alive", @400000005409907619347614 "Host: www.finanztreff.de", @400000005409907619347de4 "X-USF-clientip: 193.27.50.88", @400000005409907619347de4 "X-Forwarded-For: 193.27.50.88, 193.27.50.88", @4000000054099076193481cc "X-USF-ESI-Level: 1", @4000000054099076193481cc "Accept-Encoding: gzip", @4000000054099076193481cc }, @4000000054099076193485b4 http[resp] = { @4000000054099076193485b4 ws = 0x7f181fc9a1b8[req] @40000000540990761934993c "HTTP/1.1", @40000000540990761934993c "503", @400000005409907619349d24 "Backend fetch failed", @400000005409907619349d24 "Date: Fri, 05 Sep 2014 10:28:59 GMT", @400000005409907619349d24 "Server: Varnish", @40000000540990761934a10c "Content-Type: text/html; charset=utf-8", @40000000540990761934a10c "Retry-After: 5", @40000000540990761934a10c "X-Varnish: 131116", @40000000540990761934a4f4 "Age: 0", @40000000540990761934acc4 "Via: 1.1 varnish-v4", @40000000540990761934b0ac "X-USF-Cache: MISS", @40000000540990761934b0ac }, @40000000540990761934b0ac vcl = { @40000000540990761934b0ac srcname = { @40000000540990761934b494 "input", @40000000540990761934b494 "Builtin", @40000000540990761934b494 "/usr/local/opt/varnish/etc/cookie.inc", @40000000540990761934b494 "/usr/local/opt/varnish/etc/pool- push-a.inc", @40000000540990761934b87c "/usr/local/opt/varnish/etc/push.inc", @40000000540990761934c04c }, @40000000540990761934c434 }, @40000000540990761934c434 obj (REQ) = 0x7f182283cf80 { @40000000540990761934c434 vxid = 2147614765, @40000000540990761934c434 http[obj] = { @40000000540990761934c434 ws = 0x7f18200ab268[] @40000000540990761934c81c "HTTP/1.1", @40000000540990761934c81c "503", @40000000540990761934c81c "Backend fetch failed", @40000000540990761934cc04 "Date: Fri, 05 Sep 2014 10:28:59 GMT", @40000000540990761934e374 "Server: Varnish", @40000000540990761934e374 "Content-Type: text/html; charset=utf-8", @40000000540990761934e75c "Retry-After: 5", @40000000540990761934e75c }, @40000000540990761934e75c len = 418, @40000000540990761934e75c store = { @40000000540990761934eb44 418 { @40000000540990761934eb44 0a 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 |.. Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Sep 7 09:58:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 07 Sep 2014 09:58:23 -0000 Subject: [Varnish] #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: In-Reply-To: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> References: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> Message-ID: <057.59a4f3b009c37d08440ebe854eb65cfa@varnish-cache.org> #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: ---------------------+-------------------- Reporter: olli | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: blocker | Resolution: Keywords: | ---------------------+-------------------- Description changed by fgsch: Old description: > Hi, > > I want to switch from varnish 3.0.4 to varnish-4.0.1 but I get the > following errors in 4.0.1: > > @400000005409907619329984 Child (7530) died signal=6 > @40000000540990761933417c Child (7530) Panic message: > @40000000540990761933417c Assert error in WS_Release(), cache/cache_ws.c > line 225: > @400000005409907619334564 Condition(bytes <= ws->e - ws->f) not true. > @40000000540990761933494c thread = (cache-worker) > @40000000540990761933494c ident = > Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll > @400000005409907619334d34 Backtrace: > @400000005409907619334d34 0x433fe5: pan_ic+0xc5 > @400000005409907619334d34 0x44b573: WS_Release+0xb3 > @40000000540990761933511c 0x442e28: VRT_IP_string+0x68 > @400000005409907619336c74 0x7f182a0d328e: > ./vcl.0aGwBrPz.so(VGC_function_vcl_deliver+0xae) [0x7f182a0d328e] > @40000000540990761933705c 0x440817: vcl_call_method+0x187 > @40000000540990761933705c 0x441728: VCL_deliver_method+0x48 > @400000005409907619337444 0x437e2e: cnt_deliver+0x1ce > @400000005409907619337444 0x438531: CNT_Request+0x111 > @40000000540990761933782c 0x41a510: ESI_Deliver+0x7d0 > @40000000540990761933782c 0x43b2a8: V1D_Deliver+0x368 > @40000000540990761933ddbc req = 0x7f181fc9a020 { > @40000000540990761933e1a4 sp = 0x7f181ec1b520, vxid = 1073872940, step > = R_STP_DELIVER, > @40000000540990761933e58c req_body = R_BODY_NONE, > @40000000540990761933e58c err_code = 503, err_reason = (null), > @40000000540990761933e58c restarts = 0, esi_level = 1 > @40000000540990761933e974 sp = 0x7f181ec1b520 { > @40000000540990761933e974 fd = 29, vxid = 131085, > @40000000540990761933ed5c client = 193.27.50.88 36722, > @40000000540990761933ed5c step = S_STP_WORKING, > @4000000054099076193400e4 }, > @4000000054099076193400e4 worker = 0x7f1823d1ec50 { > @4000000054099076193404cc ws = 0x7f1823d1ee68 { > @4000000054099076193404cc id = "wrk", > @4000000054099076193404cc {s,f,r,e} = > {0x7f1823d1e450,0x7f1823d1e450,(nil),+2048}, > @400000005409907619342024 }, > @400000005409907619342024 VCL::method = DELIVER, > @40000000540990761934240c VCL::return = abandon, > @40000000540990761934240c }, > @40000000540990761934240c ws = 0x7f181fc9a1b8 { > @4000000054099076193427f4 id = "req", > @4000000054099076193427f4 {s,f,r,e} = > {0x7f181fc9c010,+56,(nil),+57360}, > @400000005409907619342bdc }, > @400000005409907619342bdc http[req] = { > @400000005409907619342bdc ws = 0x7f181fc671b8[req] > @400000005409907619343f64 "GET", > @400000005409907619343f64 > "/esi/topflop.htn?esiPermId=252&typ=mostclickedSearch&ajax=10&limit=10&divId=USFMostClickedSearch&seite=zertifikate", > @40000000540990761934434c "HTTP/1.1", > @400000005409907619344734 "Accept: */*", > @400000005409907619344734 "Accept-Language: de-DE", > @400000005409907619344b1c "Pragma: no-cache", > @400000005409907619344b1c "User-Agent: Mozilla/4.0 (compatible; > MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB7.4; SLCC2; .NET CLR > 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; > .NET CLR 1.1.4322; .NET4.0C; .NET4.0E)", > @400000005409907619346e44 "Via: 1.1 komsrv:3128 (KEN!), 1.1 > idssquid17.services.datevnet.de (squid)", > @40000000540990761934722c "Cache-Control: no-cache", > @40000000540990761934722c "Connection: keep-alive", > @400000005409907619347614 "Host: www.finanztreff.de", > @400000005409907619347de4 "X-USF-clientip: 193.27.50.88", > @400000005409907619347de4 "X-Forwarded-For: 193.27.50.88, > 193.27.50.88", > @4000000054099076193481cc "X-USF-ESI-Level: 1", > @4000000054099076193481cc "Accept-Encoding: gzip", > @4000000054099076193481cc }, > @4000000054099076193485b4 http[resp] = { > @4000000054099076193485b4 ws = 0x7f181fc9a1b8[req] > @40000000540990761934993c "HTTP/1.1", > @40000000540990761934993c "503", > @400000005409907619349d24 "Backend fetch failed", > @400000005409907619349d24 "Date: Fri, 05 Sep 2014 10:28:59 GMT", > @400000005409907619349d24 "Server: Varnish", > @40000000540990761934a10c "Content-Type: text/html; charset=utf-8", > @40000000540990761934a10c "Retry-After: 5", > @40000000540990761934a10c "X-Varnish: 131116", > @40000000540990761934a4f4 "Age: 0", > @40000000540990761934acc4 "Via: 1.1 varnish-v4", > @40000000540990761934b0ac "X-USF-Cache: MISS", > @40000000540990761934b0ac }, > @40000000540990761934b0ac vcl = { > @40000000540990761934b0ac srcname = { > @40000000540990761934b494 "input", > @40000000540990761934b494 "Builtin", > @40000000540990761934b494 "/usr/local/opt/varnish/etc/cookie.inc", > @40000000540990761934b494 "/usr/local/opt/varnish/etc/pool- > push-a.inc", > @40000000540990761934b87c "/usr/local/opt/varnish/etc/push.inc", > @40000000540990761934c04c }, > @40000000540990761934c434 }, > @40000000540990761934c434 obj (REQ) = 0x7f182283cf80 { > @40000000540990761934c434 vxid = 2147614765, > @40000000540990761934c434 http[obj] = { > @40000000540990761934c434 ws = 0x7f18200ab268[] > @40000000540990761934c81c "HTTP/1.1", > @40000000540990761934c81c "503", > @40000000540990761934c81c "Backend fetch failed", > @40000000540990761934cc04 "Date: Fri, 05 Sep 2014 10:28:59 GMT", > @40000000540990761934e374 "Server: Varnish", > @40000000540990761934e374 "Content-Type: text/html; > charset=utf-8", > @40000000540990761934e75c "Retry-After: 5", > @40000000540990761934e75c }, > @40000000540990761934e75c len = 418, > @40000000540990761934e75c store = { > @40000000540990761934eb44 418 { > @40000000540990761934eb44 0a 3c 3f 78 6d 6c 20 76 65 72 73 69 6f > 6e 3d 22 |. @40000000540990761934eb44 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 > 3d 22 75 |1.0" encoding="u| > @40000000540990761934fecc 74 66 2d 38 22 3f 3e 0a 3c 21 44 4f 43 > 54 59 50 |tf-8"?>. @4000000054099076193502b4 45 20 68 74 6d 6c 20 50 55 42 4c 49 43 > 20 22 2d |E html PUBLIC "-| > @4000000054099076193502b4 [354 more] > @4000000054099076193502b4 }, > @40000000540990761935069c }, > @40000000540990761935069c }, > @40000000540990761935069c }, > > I can not reproduce bei myself. We make extensive use of ESI. New description: Hi, I want to switch from varnish 3.0.4 to varnish-4.0.1 but I get the following errors in 4.0.1: {{{ @400000005409907619329984 Child (7530) died signal=6 @40000000540990761933417c Child (7530) Panic message: @40000000540990761933417c Assert error in WS_Release(), cache/cache_ws.c line 225: @400000005409907619334564 Condition(bytes <= ws->e - ws->f) not true. @40000000540990761933494c thread = (cache-worker) @40000000540990761933494c ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll @400000005409907619334d34 Backtrace: @400000005409907619334d34 0x433fe5: pan_ic+0xc5 @400000005409907619334d34 0x44b573: WS_Release+0xb3 @40000000540990761933511c 0x442e28: VRT_IP_string+0x68 @400000005409907619336c74 0x7f182a0d328e: ./vcl.0aGwBrPz.so(VGC_function_vcl_deliver+0xae) [0x7f182a0d328e] @40000000540990761933705c 0x440817: vcl_call_method+0x187 @40000000540990761933705c 0x441728: VCL_deliver_method+0x48 @400000005409907619337444 0x437e2e: cnt_deliver+0x1ce @400000005409907619337444 0x438531: CNT_Request+0x111 @40000000540990761933782c 0x41a510: ESI_Deliver+0x7d0 @40000000540990761933782c 0x43b2a8: V1D_Deliver+0x368 @40000000540990761933ddbc req = 0x7f181fc9a020 { @40000000540990761933e1a4 sp = 0x7f181ec1b520, vxid = 1073872940, step = R_STP_DELIVER, @40000000540990761933e58c req_body = R_BODY_NONE, @40000000540990761933e58c err_code = 503, err_reason = (null), @40000000540990761933e58c restarts = 0, esi_level = 1 @40000000540990761933e974 sp = 0x7f181ec1b520 { @40000000540990761933e974 fd = 29, vxid = 131085, @40000000540990761933ed5c client = 193.27.50.88 36722, @40000000540990761933ed5c step = S_STP_WORKING, @4000000054099076193400e4 }, @4000000054099076193400e4 worker = 0x7f1823d1ec50 { @4000000054099076193404cc ws = 0x7f1823d1ee68 { @4000000054099076193404cc id = "wrk", @4000000054099076193404cc {s,f,r,e} = {0x7f1823d1e450,0x7f1823d1e450,(nil),+2048}, @400000005409907619342024 }, @400000005409907619342024 VCL::method = DELIVER, @40000000540990761934240c VCL::return = abandon, @40000000540990761934240c }, @40000000540990761934240c ws = 0x7f181fc9a1b8 { @4000000054099076193427f4 id = "req", @4000000054099076193427f4 {s,f,r,e} = {0x7f181fc9c010,+56,(nil),+57360}, @400000005409907619342bdc }, @400000005409907619342bdc http[req] = { @400000005409907619342bdc ws = 0x7f181fc671b8[req] @400000005409907619343f64 "GET", @400000005409907619343f64 "/esi/topflop.htn?esiPermId=252&typ=mostclickedSearch&ajax=10&limit=10&divId=USFMostClickedSearch&seite=zertifikate", @40000000540990761934434c "HTTP/1.1", @400000005409907619344734 "Accept: */*", @400000005409907619344734 "Accept-Language: de-DE", @400000005409907619344b1c "Pragma: no-cache", @400000005409907619344b1c "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB7.4; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E)", @400000005409907619346e44 "Via: 1.1 komsrv:3128 (KEN!), 1.1 idssquid17.services.datevnet.de (squid)", @40000000540990761934722c "Cache-Control: no-cache", @40000000540990761934722c "Connection: keep-alive", @400000005409907619347614 "Host: www.finanztreff.de", @400000005409907619347de4 "X-USF-clientip: 193.27.50.88", @400000005409907619347de4 "X-Forwarded-For: 193.27.50.88, 193.27.50.88", @4000000054099076193481cc "X-USF-ESI-Level: 1", @4000000054099076193481cc "Accept-Encoding: gzip", @4000000054099076193481cc }, @4000000054099076193485b4 http[resp] = { @4000000054099076193485b4 ws = 0x7f181fc9a1b8[req] @40000000540990761934993c "HTTP/1.1", @40000000540990761934993c "503", @400000005409907619349d24 "Backend fetch failed", @400000005409907619349d24 "Date: Fri, 05 Sep 2014 10:28:59 GMT", @400000005409907619349d24 "Server: Varnish", @40000000540990761934a10c "Content-Type: text/html; charset=utf-8", @40000000540990761934a10c "Retry-After: 5", @40000000540990761934a10c "X-Varnish: 131116", @40000000540990761934a4f4 "Age: 0", @40000000540990761934acc4 "Via: 1.1 varnish-v4", @40000000540990761934b0ac "X-USF-Cache: MISS", @40000000540990761934b0ac }, @40000000540990761934b0ac vcl = { @40000000540990761934b0ac srcname = { @40000000540990761934b494 "input", @40000000540990761934b494 "Builtin", @40000000540990761934b494 "/usr/local/opt/varnish/etc/cookie.inc", @40000000540990761934b494 "/usr/local/opt/varnish/etc/pool- push-a.inc", @40000000540990761934b87c "/usr/local/opt/varnish/etc/push.inc", @40000000540990761934c04c }, @40000000540990761934c434 }, @40000000540990761934c434 obj (REQ) = 0x7f182283cf80 { @40000000540990761934c434 vxid = 2147614765, @40000000540990761934c434 http[obj] = { @40000000540990761934c434 ws = 0x7f18200ab268[] @40000000540990761934c81c "HTTP/1.1", @40000000540990761934c81c "503", @40000000540990761934c81c "Backend fetch failed", @40000000540990761934cc04 "Date: Fri, 05 Sep 2014 10:28:59 GMT", @40000000540990761934e374 "Server: Varnish", @40000000540990761934e374 "Content-Type: text/html; charset=utf-8", @40000000540990761934e75c "Retry-After: 5", @40000000540990761934e75c }, @40000000540990761934e75c len = 418, @40000000540990761934e75c store = { @40000000540990761934eb44 418 { @40000000540990761934eb44 0a 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 |.. Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 8 12:57:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 08 Sep 2014 12:57:53 -0000 Subject: [Varnish] #1593: addition of checkconfig in init scripts Message-ID: <041.5a1f245c3cb06544d523420137c3de93@varnish-cache.org> #1593: addition of checkconfig in init scripts ---------------------------------+------------------------- Reporter: Tin | Type: enhancement Status: new | Priority: low Milestone: Varnish 4.0 release | Component: packaging Version: unknown | Severity: minor Keywords: | ---------------------------------+------------------------- It would be a nice addition if something like checkconfig() { if [ -f "$CONF" ]; then start-stop-daemon \ --start --quiet --pidfile ${PIDFILE} --exec ${DAEMON} -- \ -P ${PIDFILE} ${DAEMON_OPTS} -p vcc_err_unref=off -C \ -n /tmp > /dev/null && echo "Syntax ok (warnings can be ignored)" else echo "$CONF is unset or does not point to a file" fi would be added to the init scripts (instead of having to add it with each new release again manually). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 9 09:37:14 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Sep 2014 09:37:14 -0000 Subject: [Varnish] #1594: Make server.* vars available everywhere Message-ID: <046.81961a1d4c266fdcc302a327adc3ade0@varnish-cache.org> #1594: Make server.* vars available everywhere --------------------------------------+------------------------- Reporter: tmagnien | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 4.0.1 | Severity: normal Keywords: server vars availability | --------------------------------------+------------------------- Hi, I did not find any good reason for server.* vars not being available in all VCL functions anymore, so here is the associated patch. Regards, Thierry -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 9 12:00:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Sep 2014 12:00:03 -0000 Subject: [Varnish] #1575: Health in random-director does not work In-Reply-To: <042.ba6e81edab67dee0d2d688995d3c45f5@varnish-cache.org> References: <042.ba6e81edab67dee0d2d688995d3c45f5@varnish-cache.org> Message-ID: <057.12adf0c52080b60d8eeff4f7102a23e5@varnish-cache.org> #1575: Health in random-director does not work --------------------+--------------------- Reporter: olli | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: In [71cd323b23c221afa65ad20ac3f772b823a98ac7]: {{{ #!CommitTicketReference repository="" revision="71cd323b23c221afa65ad20ac3f772b823a98ac7" Make random/hash director exhaust the backend list when looking for healthy backend. Fixes: #1575 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 9 12:29:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Sep 2014 12:29:16 -0000 Subject: [Varnish] #1588: Timestamp records are recorded before SLT_Begin on pipelining requests In-Reply-To: <044.1aadb42d75ceac75a638d12038720fae@varnish-cache.org> References: <044.1aadb42d75ceac75a638d12038720fae@varnish-cache.org> Message-ID: <059.206674a8be72f36760402250e502cc6e@varnish-cache.org> #1588: Timestamp records are recorded before SLT_Begin on pipelining requests ----------------------+----------------------------------------------- Reporter: martin | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * owner: => Martin Blix Grydeland * resolution: => fixed Comment: In [51e13a4a5e3940c29730ed65aa0b7b482ba21e61]: {{{ #!CommitTicketReference repository="" revision="51e13a4a5e3940c29730ed65aa0b7b482ba21e61" Allocate request VXID only when it's needed and delay all logging until it's been allocated. This patch delays the VXID allocation until the time we know that we will actually be logging anything for this request (not completely all whitespace noise). This keeps the code in one place only (plus the ESI mock request handling), instead of separated between the linger wait, cache acceptor and pipelining code paths. Coincidentally fixes the logging of timestamps problem in #1588. Test case by daghf. Fixes: #1581 #1588 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 9 12:29:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Sep 2014 12:29:16 -0000 Subject: [Varnish] #1581: Duplicate SLT_Begin log records In-Reply-To: <043.8743f789155e60115173c7fa6383b726@varnish-cache.org> References: <043.8743f789155e60115173c7fa6383b726@varnish-cache.org> Message-ID: <058.b1b2d1a37642385eb134e8160964880a@varnish-cache.org> #1581: Duplicate SLT_Begin log records ----------------------+----------------------------------------------- Reporter: daghf | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * resolution: worksforme => fixed Comment: In [51e13a4a5e3940c29730ed65aa0b7b482ba21e61]: {{{ #!CommitTicketReference repository="" revision="51e13a4a5e3940c29730ed65aa0b7b482ba21e61" Allocate request VXID only when it's needed and delay all logging until it's been allocated. This patch delays the VXID allocation until the time we know that we will actually be logging anything for this request (not completely all whitespace noise). This keeps the code in one place only (plus the ESI mock request handling), instead of separated between the linger wait, cache acceptor and pipelining code paths. Coincidentally fixes the logging of timestamps problem in #1588. Test case by daghf. Fixes: #1581 #1588 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 9 12:30:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Sep 2014 12:30:08 -0000 Subject: [Varnish] #1595: Make hash director nice enough not to reshuffle clients Message-ID: <046.b8b5495c9ae7262c83191e401922a992@varnish-cache.org> #1595: Make hash director nice enough not to reshuffle clients ----------------------+------------------------- Reporter: zviratko | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | ----------------------+------------------------- I am re-implementing BigIP LTM logic and found a problem with how session stickiness can be implemented in varnish. When a previously unhealthy node goes up again, all clients previously reshuffled end on a different node, thus users are logged out again (first when it goes down, then when it goes up again). This is made worse if the node is flapping. I would love to see some possibility to do what F5 does 1) a cookie is handed to the client, identifiyng the node in a pool that was chosen by the director logic 2) when the node indicated in this cookie is sick, another one is chosen and the cookie is updated 3) when the node goes up, all clients with cookie pointing to it end up here (those that didn't try to access it when it was down), while all clients that got reshuffled stay on their new nodes with no disruption Currently, I don't see a way to do this with VCL logic, at least not easily. I could copy backend_name to a cookie, but using it during request for backend selection would require a quite extensive array of IFs or a possibility to copy the string value to backend_hint, which is a different type. This would solve two things 1) really sticky sessions when the node goes up again 2) pool size changes consistency - new member will begin empty with only new sessions assigned to it. This might require temporarily increasing weight of the new node to accelerate it's population, though What I think can be actually done 1) a new type of director which would handle the cookie-setting itself automatically or at least 2) possibility to set the backend from a cookie name, thus making it easy to implement in VCL like so: fresh client arrives -> node is chosen by director -> bereq is made -> beresp.http.Set-Cookie is added with value of beresp.backend.name old client with cookie arrives ->set req.backend_hint = req.http.Cookie (part of it with the backend name of course)->bereq is made (and if backend is sick, we delete the cookie and retry on a different one). I beg you to please make it at least possible to implement the workaround in 2), it would make it possible to match the true stickiness achieved with F5. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 9 12:54:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Sep 2014 12:54:34 -0000 Subject: [Varnish] #1581: Duplicate SLT_Begin log records In-Reply-To: <043.8743f789155e60115173c7fa6383b726@varnish-cache.org> References: <043.8743f789155e60115173c7fa6383b726@varnish-cache.org> Message-ID: <058.1759f9d5af6bacb767096d046970820f@varnish-cache.org> #1581: Duplicate SLT_Begin log records ----------------------+----------------------------------------------- Reporter: daghf | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Comment (by Martin Blix Grydeland ): In [f94106987fcdd958c1daf4cec6186da980c8ac82]: {{{ #!CommitTicketReference repository="" revision="f94106987fcdd958c1daf4cec6186da980c8ac82" Allocate request VXID only when it's needed and delay all logging until it's been allocated. This patch delays the VXID allocation until the time we know that we will actually be logging anything for this request (not completely all whitespace noise). This keeps the code in one place only (plus the ESI mock request handling), instead of separated between the linger wait, cache acceptor and pipelining code paths. Coincidentally fixes the logging of timestamps problem in #1588. Test case by daghf. Fixes: #1581 #1588 Conflicts: bin/varnishd/cache/cache_esi_deliver.c bin/varnishd/cache/cache_fetch.c bin/varnishd/cache/cache_http1_fsm.c bin/varnishd/cache/cache_session.c }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 9 12:54:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Sep 2014 12:54:34 -0000 Subject: [Varnish] #1588: Timestamp records are recorded before SLT_Begin on pipelining requests In-Reply-To: <044.1aadb42d75ceac75a638d12038720fae@varnish-cache.org> References: <044.1aadb42d75ceac75a638d12038720fae@varnish-cache.org> Message-ID: <059.d64b2fc11a73dec53dce7157c9f3004f@varnish-cache.org> #1588: Timestamp records are recorded before SLT_Begin on pipelining requests ----------------------+----------------------------------------------- Reporter: martin | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Comment (by Martin Blix Grydeland ): In [f94106987fcdd958c1daf4cec6186da980c8ac82]: {{{ #!CommitTicketReference repository="" revision="f94106987fcdd958c1daf4cec6186da980c8ac82" Allocate request VXID only when it's needed and delay all logging until it's been allocated. This patch delays the VXID allocation until the time we know that we will actually be logging anything for this request (not completely all whitespace noise). This keeps the code in one place only (plus the ESI mock request handling), instead of separated between the linger wait, cache acceptor and pipelining code paths. Coincidentally fixes the logging of timestamps problem in #1588. Test case by daghf. Fixes: #1581 #1588 Conflicts: bin/varnishd/cache/cache_esi_deliver.c bin/varnishd/cache/cache_fetch.c bin/varnishd/cache/cache_http1_fsm.c bin/varnishd/cache/cache_session.c }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 9 12:54:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 09 Sep 2014 12:54:34 -0000 Subject: [Varnish] #1575: Health in random-director does not work In-Reply-To: <042.ba6e81edab67dee0d2d688995d3c45f5@varnish-cache.org> References: <042.ba6e81edab67dee0d2d688995d3c45f5@varnish-cache.org> Message-ID: <057.db3993468e2154165a23b6fbaaf9cf86@varnish-cache.org> #1575: Health in random-director does not work --------------------+--------------------- Reporter: olli | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------- Comment (by Martin Blix Grydeland ): In [d85dde647a93e0d585b74910eeed121942f73ee7]: {{{ #!CommitTicketReference repository="" revision="d85dde647a93e0d585b74910eeed121942f73ee7" Make random/hash director exhaust the backend list when looking for healthy backend. Fixes: #1575 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 11 10:54:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 11 Sep 2014 10:54:38 -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.add1536d2099ae1624ed95d9a5264262@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 fgsch): For anyone experiencing this, could you supply a network (pcap) and a varnishlog capture in raw format? I've been trying to reproduce this for some time without success. At this point I'm more inclined to believe the issue is somewhere else. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 10:44:52 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 10:44:52 -0000 Subject: [Varnish] #1596: Panic message:#012Assert error in vbf_fetch_thread() Message-ID: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org> #1596: Panic message:#012Assert error in vbf_fetch_thread() ---------------------------------+-------------------- Reporter: webi | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: build Version: 4.0.1 | Severity: normal Keywords: | ---------------------------------+-------------------- I get several times at irregular intervals fogende error message: {{{#!comment Sep 12 10:27:55 svweb01 varnishd[26392]: Child (26411) died signal=6 Sep 12 10:27:55 svweb01 varnishd[26392]: Child (26411) Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = (cache-worker)#012ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj = 0x7f6244521020 {#012 ws = 0x7f62445210e0 {#012 id = "bo",#012 {s,f,r,e} = {0x7f6244523000,+968,(nil),+57376},#012 },#012 refcnt = 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 is_do_pass#012 is_uncacheable#012 is_abandon#012 is_is_gunzip#012 is_should_close#012 bodystatus = 3 (length),#012 },#012 ws = 0x7f6244521268 {#012 id = "obj",#012 {s,f,r,e} = {0x7f62536bf2d0,+280,(nil),+280},#012 },#012 objcore (FETCH) = 0x7f62577c3400 {#012 refcnt = 1#012 flags = 0x104#012 objhead = 0x7f6289015390#012 }#012 obj (FETCH) = 0x7f62536bf100 {#012 vxid = 2168849705,#012 http[obj] = {#012 ws = 0x7f6244521268[obj]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 Sep 2014 08:27:54 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 "Last-Modified: Sun, 15 Dec 2013 13:12:46 GMT",#012 "ETag: "2dad5-178-4ed927385cf80"",#012 "Accept-Ranges: bytes",#012 "Content-Length: 376",#012 "Vary: User-Agent",#012 "Content- Type: image/png",#012 },#012 len = 376,#012 store = {#012 },#012 },#012 }#012 Sep 12 10:27:55 svweb01 varnishd[26392]: Child cleanup complete Sep 12 10:27:55 svweb01 varnishd[26392]: child (29662) Started Sep 12 10:27:55 svweb01 varnishd[26392]: Child (29662) said Child starts Sep 12 10:29:42 svweb01 varnishd[26392]: Child (29662) died signal=6 Sep 12 10:29:42 svweb01 varnishd[26392]: Child (29662) Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = (cache-worker)#012ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj = 0x7f6263309020 {#012 ws = 0x7f62633090e0 {#012 id = "bo",#012 {s,f,r,e} = {0x7f626330b000,+12528,(nil),+57376},#012 },#012 refcnt = 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 is_do_pass#012 is_uncacheable#012 is_abandon#012 is_is_gzip#012 is_should_close#012 bodystatus = 3 (length),#012 },#012 ws = 0x7f6263309268 {#012 id = "obj",#012 {s,f,r,e} = {0x7f625f52fee8,+328,(nil),+328},#012 },#012 objcore (FETCH) = 0x7f626ab7d080 {#012 refcnt = 1#012 flags = 0x104#012 objhead = 0x7f6289015400#012 }#012 obj (FETCH) = 0x7f625f52fd00 {#012 vxid = 2158985234,#012 http[obj] = {#012 ws = 0x7f6263309268[obj]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 Sep 2014 08:29:41 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 "Last-Modified: Wed, 10 Sep 2014 04:52:00 GMT",#012 "Accept-Ranges: bytes",#012 "Vary: Accept-Encoding,User-Agent",#012 "Content-Encoding: gzip",#012 "Content-Length: 11847",#012 "Content-Type: text/css",#012 "ETag: W/"29b5f- 108f0-502aecffd4c5f"",#012 },#012 len = 11859,#012 store = {#012 },#012 },#012 }#012 Sep 12 10:29:42 svweb01 varnishd[26392]: Child cleanup complete Sep 12 10:29:42 svweb01 varnishd[26392]: child (30322) Started Sep 12 10:29:42 svweb01 varnishd[26392]: Child (30322) said Child starts Sep 12 11:09:18 svweb01 varnishd[26392]: Child (29662) died signal=6 Sep 12 11:09:18 svweb01 varnishd[26392]: Child (30322) Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = (cache-worker)#012ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj = 0x7f6219847020 {#012 ws = 0x7f62198470e0 {#012 id = "bo",#012 {s,f,r,e} = {0x7f6219849000,+6616,(nil),+57376},#012 },#012 refcnt = 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 is_do_pass#012 is_uncacheable#012 is_abandon#012 is_is_gunzip#012 bodystatus = 3 (length),#012 },#012 ws = 0x7f6219847268 {#012 id = "obj",#012 {s,f,r,e} = {0x7f6258aa0bd0,+288,(nil),+288},#012 },#012 objcore (FETCH) = 0x7f62373d4200 {#012 refcnt = 1#012 flags = 0x104#012 objhead = 0x7f6289015470#012 }#012 obj (FETCH) = 0x7f6258aa0a00 {#012 vxid = 2169965050,#012 http[obj] = {#012 ws = 0x7f6219847268[obj]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 Sep 2014 09:09:17 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 "Last-Modified: Tue, 08 Oct 2013 20:21:03 GMT",#012 "ETag: "2adbb-1797-4e84081f969c0"",#012 "Accept-Ranges: bytes",#012 "Content-Length: 6039",#012 "Vary: User-Agent",#012 "Content-Type: image/png",#012 },#012 len = 6039,#012 store = {#012 },#012 },#012 }#012 Sep 12 11:09:18 svweb01 varnishd[26392]: Child cleanup complete Sep 12 11:09:18 svweb01 varnishd[26392]: child (2527) Started Sep 12 11:09:18 svweb01 varnishd[26392]: Child (2527) said Child starts }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 10:50:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 10:50:38 -0000 Subject: [Varnish] #1596: Panic message:#012Assert error in vbf_fetch_thread() In-Reply-To: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org> References: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org> Message-ID: <057.289f14cb5449f6e1d332d1933039cdd2@varnish-cache.org> #1596: Panic message:#012Assert error in vbf_fetch_thread() --------------------+---------------------------------- Reporter: webi | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: 4.0.1 Severity: normal | Resolution: Keywords: | --------------------+---------------------------------- Comment (by webi): {{{ Sep 12 10:27:55 svweb01 varnishd[26392]: Child (26411) died signal=6 Sep 12 10:27:55 svweb01 varnishd[26392]: Child (26411) Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = (cache-worker)#012ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj = 0x7f6244521020 {#012 ws = 0x7f62445210e0 {#012 id = "bo",#012 {s,f,r,e} = {0x7f6244523000,+968,(nil),+57376},#012 },#012 refcnt = 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 is_do_pass#012 is_uncacheable#012 is_abandon#012 is_is_gunzip#012 is_should_close#012 bodystatus = 3 (length),#012 },#012 ws = 0x7f6244521268 {#012 id = "obj",#012 {s,f,r,e} = {0x7f62536bf2d0,+280,(nil),+280},#012 },#012 objcore (FETCH) = 0x7f62577c3400 {#012 refcnt = 1#012 flags = 0x104#012 objhead = 0x7f6289015390#012 }#012 obj (FETCH) = 0x7f62536bf100 {#012 vxid = 2168849705,#012 http[obj] = {#012 ws = 0x7f6244521268[obj]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 Sep 2014 08:27:54 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 "Last-Modified: Sun, 15 Dec 2013 13:12:46 GMT",#012 "ETag: "2dad5-178-4ed927385cf80"",#012 "Accept-Ranges: bytes",#012 "Content-Length: 376",#012 "Vary: User-Agent",#012 "Content- Type: image/png",#012 },#012 len = 376,#012 store = {#012 },#012 },#012 }#012 Sep 12 10:27:55 svweb01 varnishd[26392]: Child cleanup complete Sep 12 10:27:55 svweb01 varnishd[26392]: child (29662) Started Sep 12 10:27:55 svweb01 varnishd[26392]: Child (29662) said Child starts Sep 12 10:29:42 svweb01 varnishd[26392]: Child (29662) died signal=6 Sep 12 10:29:42 svweb01 varnishd[26392]: Child (29662) Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = (cache-worker)#012ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj = 0x7f6263309020 {#012 ws = 0x7f62633090e0 {#012 id = "bo",#012 {s,f,r,e} = {0x7f626330b000,+12528,(nil),+57376},#012 },#012 refcnt = 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 is_do_pass#012 is_uncacheable#012 is_abandon#012 is_is_gzip#012 is_should_close#012 bodystatus = 3 (length),#012 },#012 ws = 0x7f6263309268 {#012 id = "obj",#012 {s,f,r,e} = {0x7f625f52fee8,+328,(nil),+328},#012 },#012 objcore (FETCH) = 0x7f626ab7d080 {#012 refcnt = 1#012 flags = 0x104#012 objhead = 0x7f6289015400#012 }#012 obj (FETCH) = 0x7f625f52fd00 {#012 vxid = 2158985234,#012 http[obj] = {#012 ws = 0x7f6263309268[obj]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 Sep 2014 08:29:41 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 "Last-Modified: Wed, 10 Sep 2014 04:52:00 GMT",#012 "Accept-Ranges: bytes",#012 "Vary: Accept-Encoding,User-Agent",#012 "Content-Encoding: gzip",#012 "Content-Length: 11847",#012 "Content-Type: text/css",#012 "ETag: W/"29b5f- 108f0-502aecffd4c5f"",#012 },#012 len = 11859,#012 store = {#012 },#012 },#012 }#012 Sep 12 10:29:42 svweb01 varnishd[26392]: Child cleanup complete Sep 12 10:29:42 svweb01 varnishd[26392]: child (30322) Started Sep 12 10:29:42 svweb01 varnishd[26392]: Child (30322) said Child starts Sep 12 11:09:18 svweb01 varnishd[26392]: Child (29662) died signal=6 Sep 12 11:09:18 svweb01 varnishd[26392]: Child (30322) Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = (cache-worker)#012ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj = 0x7f6219847020 {#012 ws = 0x7f62198470e0 {#012 id = "bo",#012 {s,f,r,e} = {0x7f6219849000,+6616,(nil),+57376},#012 },#012 refcnt = 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 is_do_pass#012 is_uncacheable#012 is_abandon#012 is_is_gunzip#012 bodystatus = 3 (length),#012 },#012 ws = 0x7f6219847268 {#012 id = "obj",#012 {s,f,r,e} = {0x7f6258aa0bd0,+288,(nil),+288},#012 },#012 objcore (FETCH) = 0x7f62373d4200 {#012 refcnt = 1#012 flags = 0x104#012 objhead = 0x7f6289015470#012 }#012 obj (FETCH) = 0x7f6258aa0a00 {#012 vxid = 2169965050,#012 http[obj] = {#012 ws = 0x7f6219847268[obj]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 Sep 2014 09:09:17 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 "Last-Modified: Tue, 08 Oct 2013 20:21:03 GMT",#012 "ETag: "2adbb-1797-4e84081f969c0"",#012 "Accept-Ranges: bytes",#012 "Content-Length: 6039",#012 "Vary: User-Agent",#012 "Content-Type: image/png",#012 },#012 len = 6039,#012 store = {#012 },#012 },#012 }#012 Sep 12 11:09:18 svweb01 varnishd[26392]: Child cleanup complete Sep 12 11:09:18 svweb01 varnishd[26392]: child (2527) Started Sep 12 11:09:18 svweb01 varnishd[26392]: Child (2527) said Child starts }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 13:46:01 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 13:46:01 -0000 Subject: [Varnish] #410: Varnish uses up all system RAM on OpenVZ VPS In-Reply-To: <044.54e4b936c83111d0d70d8551f3728fbc@varnish-cache.org> References: <044.54e4b936c83111d0d70d8551f3728fbc@varnish-cache.org> Message-ID: <059.224afd929657a9eb5d922d96fab3b9cf@varnish-cache.org> #410: Varnish uses up all system RAM on OpenVZ VPS ---------------------+---------------------- Reporter: eugaia | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: blocker | Resolution: invalid Keywords: | ---------------------+---------------------- Comment (by Coffres): Il est certain que pour de s?curit? une alarme et un coffre fort permettent de s?curiser efficacement les donn?es et les documents important. Un coffre fort ignifuge permettra en plus de se couvrir contre le risque de feu et un [http://www.infosafe.fr/CoffresSecurite/coffre-fort-securite- sg160.htm coffre agr?? par les assurance] sera pris en compte par votre assureur en cas de cambriolage r?ussi. Les armoires fortes quant ? elles sont indispensables pour le stockage des armes longues comme les fusils de chasse par exemple. Un coffre est un investissement rentable sur le long terme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 13:47:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 13:47:54 -0000 Subject: [Varnish] #411: restart not available in vcl_deliver In-Reply-To: <044.000275f99724589f0575cf6f03b071df@varnish-cache.org> References: <044.000275f99724589f0575cf6f03b071df@varnish-cache.org> Message-ID: <059.733a275305c44d813520f67ad0cc74fb@varnish-cache.org> #411: restart not available in vcl_deliver ----------------------+--------------------- Reporter: hajile | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Coffres): Il est certain que pour de s?curit? une alarme et un coffre fort permettent de s?curiser efficacement les donn?es et les documents important. Un coffre fort ignifuge permettra en plus de se couvrir contre le risque de feu et un [http://www.infosafe.fr/Coffre/CoffresMT/Coffre-fort-ABC.htm coffre ignifuge A2P] sera pris en compte par votre assureur en cas de cambriolage r?ussi. Les [http://www.infosafe.fr/Armoirefortedin/Armoirefortedin.htm armoires fortes classe c] quant ? elles sont indispensables pour le stockage des armes longues comme les fusils de chasse par exemple. Un coffre est un investissement rentable sur le long terme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 13:49:00 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 13:49:00 -0000 Subject: [Varnish] #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit In-Reply-To: <044.bf6d38564bf38c37c953fb50e59a9368@varnish-cache.org> References: <044.bf6d38564bf38c37c953fb50e59a9368@varnish-cache.org> Message-ID: <059.e9c896ec99405b0ac595225e383789b5@varnish-cache.org> #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit -------------------------+------------------------- Reporter: hajile | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Comment (by Coffres): == Les coffres forts sont la cl? == Il est certain que pour de s?curit? une alarme et un coffre fort permettent de s?curiser efficacement les donn?es et les documents important. Un coffre fort ignifuge permettra en plus de se couvrir contre le risque de feu et un [http://www.infosafe.fr coffre ignifuge agr?? A2P] sera pris en compte par votre assurance en cas de cambriolage avec violence. Les [http://www.infosafe.fr/Armoirefortedin/Armoirefortedin.htm armoires fortes blind?es] quant ? elles sont indispensables pour le stockage des armes longues comme les fusils de chasse par exemple. Un coffre est un investissement rentable sur le long terme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 14:00:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 14:00:16 -0000 Subject: [Varnish] #413: Incorect handling of escape in esi:include src attribute In-Reply-To: <049.94ba255ebe091d0c144bb8f59edef430@varnish-cache.org> References: <049.94ba255ebe091d0c144bb8f59edef430@varnish-cache.org> Message-ID: <064.ebecb34aac469e333c30732a372afece@varnish-cache.org> #413: Incorect handling of escape in esi:include src attribute -------------------------+--------------------- Reporter: andrewmcnnz | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: esi escape | -------------------------+--------------------- Comment (by Coffres): Cette fois, c?est le bureau de Poste qui a ?t? pris pour cible. Des individus cagoul?s sont repartis avec un coffre de 90 kg contenant plus de 7 000 ?, apr?s avoir bris? la vitre blind?e qui se trouvait ? droite de l?entr?e de l?agence. Les individus ont ensuite pris la fuite ? bord de deux v?hicules vol?s. Une enqu?te a ?t? ouverte par la gendarmerie locale, mais il est clair qu'une telle somme aurait due ?tre s?curis?e dans un coffre fort agr?? plus massif et plus lourd. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 14:01:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 14:01:23 -0000 Subject: [Varnish] #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit In-Reply-To: <044.bf6d38564bf38c37c953fb50e59a9368@varnish-cache.org> References: <044.bf6d38564bf38c37c953fb50e59a9368@varnish-cache.org> Message-ID: <059.bf149248eb1e32546ee7fcb3f269e782@varnish-cache.org> #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit -------------------------+------------------------- Reporter: hajile | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Comment (by Coffres): == Les coffres forts sont la cl? == Il est certain que pour de s?curit? une alarme et un coffre fort permettent de s?curiser efficacement les donn?es et les documents important. Un coffre fort ignifuge permettra en plus de se couvrir contre le risque de feu et un [http://www.infosafe.fr coffre ignifuge agr?? A2P] sera pris en compte par votre assurance en cas de cambriolage avec violence. Les [http://www.infosafe.fr/Armoirefortedin/Armoirefortedin.htm armoires fortes blind?es] quant ? elles sont indispensables pour le stockage des armes longues comme les fusils de chasse par exemple. Un coffre est un investissement rentable sur le long terme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 14:01:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 14:01:49 -0000 Subject: [Varnish] #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit In-Reply-To: <044.bf6d38564bf38c37c953fb50e59a9368@varnish-cache.org> References: <044.bf6d38564bf38c37c953fb50e59a9368@varnish-cache.org> Message-ID: <059.bf54dc1608991e88be3dfba5d2fd1a58@varnish-cache.org> #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit -------------------------+------------------------- Reporter: hajile | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Comment (by Coffres): Cette fois, c?est le bureau de Poste qui a ?t? pris pour cible. Des individus cagoul?s sont repartis avec un coffre de 90 kg contenant plus de 7 000 ?, apr?s avoir bris? la vitre blind?e qui se trouvait ? droite de l?entr?e de l?agence. Les individus ont ensuite pris la fuite ? bord de deux v?hicules vol?s. Une enqu?te a ?t? ouverte par la gendarmerie locale, mais il est clair qu'une telle somme aurait due ?tre s?curis?e dans un coffre fort agr?? plus massif et plus lourd. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 14:04:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 14:04:54 -0000 Subject: [Varnish] #419: param esi syntax not documented In-Reply-To: <043.28bcac20deec15d880cb92fce8c4c792@varnish-cache.org> References: <043.28bcac20deec15d880cb92fce8c4c792@varnish-cache.org> Message-ID: <058.9e3b3cd820d21ecf6cfe59a6239c1415@varnish-cache.org> #419: param esi syntax not documented ---------------------------+--------------------- Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------- Comment (by Coffres): Les coffres forts agr??s vraiment efficaces Il est certain que pour de s?curit? une alarme et un coffre fort permettent de s?curiser efficacement les donn?es et les documents important. Un coffre fort ignifuge permettra en plus de se couvrir contre le risque de feu et un [http://www.infosafe.fr/CoffresSecurite/coffre-fort-securite- sg160.htm coffre-fort agr?? A2P] sera pris en compte par votre assurance en cas de cambriolage avec violence. Les [http://www.infosafe.fr/CoffresSecurite/coffre-fort-securite-sg160.htm armoires fortes blind?es] quant ? elles sont indispensables pour le stockage des armes longues comme les fusils de chasse par exemple. Un coffre est un investissement rentable sur le long terme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 14:05:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 14:05:13 -0000 Subject: [Varnish] #419: param esi syntax not documented In-Reply-To: <043.28bcac20deec15d880cb92fce8c4c792@varnish-cache.org> References: <043.28bcac20deec15d880cb92fce8c4c792@varnish-cache.org> Message-ID: <058.a309958729324cadd2b3609c101e9e9b@varnish-cache.org> #419: param esi syntax not documented ---------------------------+--------------------- Reporter: perbu | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------- Comment (by Coffres): Cette fois, c?est le bureau de Poste qui a ?t? pris pour cible. Des individus cagoul?s sont repartis avec un coffre de 90 kg contenant plus de 8 000 ?, apr?s avoir bris? la vitre blind?e qui se trouvait ? droite de l?entr?e de l?agence. Les individus ont ensuite pris la fuite ? bord de deux v?hicules vol?s. Une enqu?te a ?t? ouverte par la gendarmerie locale, mais il est clair qu'une telle somme aurait due ?tre s?curis?e dans un coffre fort agr?? plus massif et plus lourd. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 12 14:10:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 12 Sep 2014 14:10:44 -0000 Subject: [Varnish] #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit In-Reply-To: <044.bf6d38564bf38c37c953fb50e59a9368@varnish-cache.org> References: <044.bf6d38564bf38c37c953fb50e59a9368@varnish-cache.org> Message-ID: <059.175226776ac6a959cd7f24c8f2c2d1d3@varnish-cache.org> #412: make caching still possible in case of 'restart' from vcl_fetch and implement 'restart' from vcl_hit -------------------------+------------------------- Reporter: hajile | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Comment (by Coffres): Cette fois, c?est le bureau de Poste qui a ?t? pris pour cible. Des individus cagoul?s sont repartis avec un coffre de 90 kg contenant plus de 7 000 ?, apr?s avoir bris? la vitre blind?e qui se trouvait ? droite de l?entr?e de l?agence. Les individus ont ensuite pris la fuite ? bord de deux v?hicules vol?s. Une enqu?te a ?t? ouverte par la gendarmerie locale, mais il est clair qu'une telle somme aurait due ?tre s?curis?e dans un coffre fort agr?? plus massif et plus lourd. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 15 10:06:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Sep 2014 10:06:42 -0000 Subject: [Varnish] #1596: Panic message:#012Assert error in vbf_fetch_thread() In-Reply-To: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org> References: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org> Message-ID: <057.7196192decd2aaf7fc885e6f78efc924@varnish-cache.org> #1596: Panic message:#012Assert error in vbf_fetch_thread() --------------------+---------------------------------- Reporter: webi | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: 4.0.1 Severity: normal | Resolution: Keywords: | --------------------+---------------------------------- Description changed by lkarsten: Old description: > I get several times at irregular intervals fogende error message: > > {{{#!comment > Sep 12 10:27:55 svweb01 varnishd[26392]: Child (26411) died signal=6 > Sep 12 10:27:55 svweb01 varnishd[26392]: Child (26411) Panic > message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line > 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = > (cache-worker)#012ident = > Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: > /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: > /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: > /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- > gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: > /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj > = 0x7f6244521020 {#012 ws = 0x7f62445210e0 {#012 id = "bo",#012 > {s,f,r,e} = {0x7f6244523000,+968,(nil),+57376},#012 },#012 refcnt = > 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 > is_do_pass#012 is_uncacheable#012 is_abandon#012 > is_is_gunzip#012 is_should_close#012 bodystatus = 3 (length),#012 > },#012 ws = 0x7f6244521268 {#012 id = "obj",#012 {s,f,r,e} = > {0x7f62536bf2d0,+280,(nil),+280},#012 },#012 objcore (FETCH) = > 0x7f62577c3400 {#012 refcnt = 1#012 flags = 0x104#012 objhead = > 0x7f6289015390#012 }#012 obj (FETCH) = 0x7f62536bf100 {#012 vxid = > 2168849705,#012 http[obj] = {#012 ws = 0x7f6244521268[obj]#012 > "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 > Sep 2014 08:27:54 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 > "Last-Modified: Sun, 15 Dec 2013 13:12:46 GMT",#012 "ETag: > "2dad5-178-4ed927385cf80"",#012 "Accept-Ranges: bytes",#012 > "Content-Length: 376",#012 "Vary: User-Agent",#012 > "Content-Type: image/png",#012 },#012 len = 376,#012 store = > {#012 },#012 },#012 }#012 > Sep 12 10:27:55 svweb01 varnishd[26392]: Child cleanup complete > Sep 12 10:27:55 svweb01 varnishd[26392]: child (29662) Started > Sep 12 10:27:55 svweb01 varnishd[26392]: Child (29662) said Child starts > > Sep 12 10:29:42 svweb01 varnishd[26392]: Child (29662) died signal=6 > Sep 12 10:29:42 svweb01 varnishd[26392]: Child (29662) Panic > message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line > 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = > (cache-worker)#012ident = > Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: > /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: > /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: > /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- > gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: > /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj > = 0x7f6263309020 {#012 ws = 0x7f62633090e0 {#012 id = "bo",#012 > {s,f,r,e} = {0x7f626330b000,+12528,(nil),+57376},#012 },#012 refcnt = > 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 > is_do_pass#012 is_uncacheable#012 is_abandon#012 is_is_gzip#012 > is_should_close#012 bodystatus = 3 (length),#012 },#012 ws = > 0x7f6263309268 {#012 id = "obj",#012 {s,f,r,e} = > {0x7f625f52fee8,+328,(nil),+328},#012 },#012 objcore (FETCH) = > 0x7f626ab7d080 {#012 refcnt = 1#012 flags = 0x104#012 objhead = > 0x7f6289015400#012 }#012 obj (FETCH) = 0x7f625f52fd00 {#012 vxid = > 2158985234,#012 http[obj] = {#012 ws = 0x7f6263309268[obj]#012 > "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 > Sep 2014 08:29:41 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 > "Last-Modified: Wed, 10 Sep 2014 04:52:00 GMT",#012 "Accept- > Ranges: bytes",#012 "Vary: Accept-Encoding,User-Agent",#012 > "Content-Encoding: gzip",#012 "Content-Length: 11847",#012 > "Content-Type: text/css",#012 "ETag: W/"29b5f- > 108f0-502aecffd4c5f"",#012 },#012 len = 11859,#012 store = {#012 > },#012 },#012 }#012 > Sep 12 10:29:42 svweb01 varnishd[26392]: Child cleanup complete > Sep 12 10:29:42 svweb01 varnishd[26392]: child (30322) Started > Sep 12 10:29:42 svweb01 varnishd[26392]: Child (30322) said Child starts > > Sep 12 11:09:18 svweb01 varnishd[26392]: Child (29662) died signal=6 > Sep 12 11:09:18 svweb01 varnishd[26392]: Child (30322) Panic > message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line > 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = > (cache-worker)#012ident = > Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: > /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: > /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: > /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- > gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: > /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj > = 0x7f6219847020 {#012 ws = 0x7f62198470e0 {#012 id = "bo",#012 > {s,f,r,e} = {0x7f6219849000,+6616,(nil),+57376},#012 },#012 refcnt = > 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 > is_do_pass#012 is_uncacheable#012 is_abandon#012 > is_is_gunzip#012 bodystatus = 3 (length),#012 },#012 ws = > 0x7f6219847268 {#012 id = "obj",#012 {s,f,r,e} = > {0x7f6258aa0bd0,+288,(nil),+288},#012 },#012 objcore (FETCH) = > 0x7f62373d4200 {#012 refcnt = 1#012 flags = 0x104#012 objhead = > 0x7f6289015470#012 }#012 obj (FETCH) = 0x7f6258aa0a00 {#012 vxid = > 2169965050,#012 http[obj] = {#012 ws = 0x7f6219847268[obj]#012 > "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 > Sep 2014 09:09:17 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 > "Last-Modified: Tue, 08 Oct 2013 20:21:03 GMT",#012 "ETag: > "2adbb-1797-4e84081f969c0"",#012 "Accept-Ranges: bytes",#012 > "Content-Length: 6039",#012 "Vary: User-Agent",#012 > "Content-Type: image/png",#012 },#012 len = 6039,#012 store = > {#012 },#012 },#012 }#012 > Sep 12 11:09:18 svweb01 varnishd[26392]: Child cleanup complete > Sep 12 11:09:18 svweb01 varnishd[26392]: child (2527) Started > Sep 12 11:09:18 svweb01 varnishd[26392]: Child (2527) said Child starts > }}} New description: I get several times at irregular intervals fogende error message: {{{ Panic message: Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838: Condition(uu == bo->fetch_obj->len) not true. thread = (cache-worker) ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433fd5: /usr/sbin/varnishd() [0x433fd5] 0x421ff6: /usr/sbin/varnishd() [0x421ff6] 0x436e90: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90] 0x4498ae: /usr/sbin/varnishd() [0x4498ae] 0x7f628a027b50: /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50] 0x7f6289d71e6d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d] busyobj = 0x7f6219847020 { ws = 0x7f62198470e0 { id = "bo", {s,f,r,e} = {0x7f6219849000,+6616,(nil),+57376}, }, refcnt = 1 retries = 0 failed = 0 state = 3 is_do_esi is_do_pass is_uncacheable is_abandon is_is_gunzip bodystatus = 3 (length), }, ws = 0x7f6219847268 { id = "obj", {s,f,r,e} = {0x7f6258aa0bd0,+288,(nil),+288}, }, objcore (FETCH) = 0x7f62373d4200 { refcnt = 1 flags = 0x104 objhead = 0x7f6289015470 } obj (FETCH) = 0x7f6258aa0a00 { vxid = 2169965050, http[obj] = { ws = 0x7f6219847268[obj] "HTTP/1.1", "200", "OK", "Date: Fri, 12 Sep 2014 09:09:17 GMT", "Server: Apache/2.2.22 (Debian)", "Last-Modified: Tue, 08 Oct 2013 20:21:03 GMT", "ETag: "2adbb-1797-4e84081f969c0"", "Accept-Ranges: bytes", "Content-Length: 6039", "Vary: User-Agent", "Content-Type: image/png", }, len = 6039, store = { }, }, } }}} {{{#!comment Sep 12 10:27:55 svweb01 varnishd[26392]: Child (26411) died signal=6 Sep 12 10:27:55 svweb01 varnishd[26392]: Child (26411) Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = (cache-worker)#012ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj = 0x7f6244521020 {#012 ws = 0x7f62445210e0 {#012 id = "bo",#012 {s,f,r,e} = {0x7f6244523000,+968,(nil),+57376},#012 },#012 refcnt = 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 is_do_pass#012 is_uncacheable#012 is_abandon#012 is_is_gunzip#012 is_should_close#012 bodystatus = 3 (length),#012 },#012 ws = 0x7f6244521268 {#012 id = "obj",#012 {s,f,r,e} = {0x7f62536bf2d0,+280,(nil),+280},#012 },#012 objcore (FETCH) = 0x7f62577c3400 {#012 refcnt = 1#012 flags = 0x104#012 objhead = 0x7f6289015390#012 }#012 obj (FETCH) = 0x7f62536bf100 {#012 vxid = 2168849705,#012 http[obj] = {#012 ws = 0x7f6244521268[obj]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 Sep 2014 08:27:54 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 "Last-Modified: Sun, 15 Dec 2013 13:12:46 GMT",#012 "ETag: "2dad5-178-4ed927385cf80"",#012 "Accept-Ranges: bytes",#012 "Content-Length: 376",#012 "Vary: User-Agent",#012 "Content- Type: image/png",#012 },#012 len = 376,#012 store = {#012 },#012 },#012 }#012 Sep 12 10:27:55 svweb01 varnishd[26392]: Child cleanup complete Sep 12 10:27:55 svweb01 varnishd[26392]: child (29662) Started Sep 12 10:27:55 svweb01 varnishd[26392]: Child (29662) said Child starts Sep 12 10:29:42 svweb01 varnishd[26392]: Child (29662) died signal=6 Sep 12 10:29:42 svweb01 varnishd[26392]: Child (29662) Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = (cache-worker)#012ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj = 0x7f6263309020 {#012 ws = 0x7f62633090e0 {#012 id = "bo",#012 {s,f,r,e} = {0x7f626330b000,+12528,(nil),+57376},#012 },#012 refcnt = 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 is_do_pass#012 is_uncacheable#012 is_abandon#012 is_is_gzip#012 is_should_close#012 bodystatus = 3 (length),#012 },#012 ws = 0x7f6263309268 {#012 id = "obj",#012 {s,f,r,e} = {0x7f625f52fee8,+328,(nil),+328},#012 },#012 objcore (FETCH) = 0x7f626ab7d080 {#012 refcnt = 1#012 flags = 0x104#012 objhead = 0x7f6289015400#012 }#012 obj (FETCH) = 0x7f625f52fd00 {#012 vxid = 2158985234,#012 http[obj] = {#012 ws = 0x7f6263309268[obj]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 Sep 2014 08:29:41 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 "Last-Modified: Wed, 10 Sep 2014 04:52:00 GMT",#012 "Accept-Ranges: bytes",#012 "Vary: Accept-Encoding,User-Agent",#012 "Content-Encoding: gzip",#012 "Content-Length: 11847",#012 "Content-Type: text/css",#012 "ETag: W/"29b5f- 108f0-502aecffd4c5f"",#012 },#012 len = 11859,#012 store = {#012 },#012 },#012 }#012 Sep 12 10:29:42 svweb01 varnishd[26392]: Child cleanup complete Sep 12 10:29:42 svweb01 varnishd[26392]: child (30322) Started Sep 12 10:29:42 svweb01 varnishd[26392]: Child (30322) said Child starts Sep 12 11:09:18 svweb01 varnishd[26392]: Child (29662) died signal=6 Sep 12 11:09:18 svweb01 varnishd[26392]: Child (30322) Panic message:#012Assert error in vbf_fetch_thread(), cache/cache_fetch.c line 838:#012 Condition(uu == bo->fetch_obj->len) not true.#012thread = (cache-worker)#012ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x433fd5: /usr/sbin/varnishd() [0x433fd5]#012 0x421ff6: /usr/sbin/varnishd() [0x421ff6]#012 0x436e90: /usr/sbin/varnishd(Pool_Work_Thread+0x370) [0x436e90]#012 0x4498ae: /usr/sbin/varnishd() [0x4498ae]#012 0x7f628a027b50: /lib/x86_64-linux- gnu/libpthread.so.0(+0x6b50) [0x7f628a027b50]#012 0x7f6289d71e6d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f6289d71e6d]#012 busyobj = 0x7f6219847020 {#012 ws = 0x7f62198470e0 {#012 id = "bo",#012 {s,f,r,e} = {0x7f6219849000,+6616,(nil),+57376},#012 },#012 refcnt = 1#012 retries = 0#012 failed = 0#012 state = 3#012 is_do_esi#012 is_do_pass#012 is_uncacheable#012 is_abandon#012 is_is_gunzip#012 bodystatus = 3 (length),#012 },#012 ws = 0x7f6219847268 {#012 id = "obj",#012 {s,f,r,e} = {0x7f6258aa0bd0,+288,(nil),+288},#012 },#012 objcore (FETCH) = 0x7f62373d4200 {#012 refcnt = 1#012 flags = 0x104#012 objhead = 0x7f6289015470#012 }#012 obj (FETCH) = 0x7f6258aa0a00 {#012 vxid = 2169965050,#012 http[obj] = {#012 ws = 0x7f6219847268[obj]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Date: Fri, 12 Sep 2014 09:09:17 GMT",#012 "Server: Apache/2.2.22 (Debian)",#012 "Last-Modified: Tue, 08 Oct 2013 20:21:03 GMT",#012 "ETag: "2adbb-1797-4e84081f969c0"",#012 "Accept-Ranges: bytes",#012 "Content-Length: 6039",#012 "Vary: User-Agent",#012 "Content-Type: image/png",#012 },#012 len = 6039,#012 store = {#012 },#012 },#012 }#012 Sep 12 11:09:18 svweb01 varnishd[26392]: Child cleanup complete Sep 12 11:09:18 svweb01 varnishd[26392]: child (2527) Started Sep 12 11:09:18 svweb01 varnishd[26392]: Child (2527) said Child starts }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 15 10:23:37 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Sep 2014 10:23:37 -0000 Subject: [Varnish] #1594: Make server.* vars available everywhere In-Reply-To: <046.81961a1d4c266fdcc302a327adc3ade0@varnish-cache.org> References: <046.81961a1d4c266fdcc302a327adc3ade0@varnish-cache.org> Message-ID: <061.33c0ccdc0c6f47f7b6bd48c4b419a58b@varnish-cache.org> #1594: Make server.* vars available everywhere --------------------------------------+---------------------- Reporter: tmagnien | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: invalid Keywords: server vars availability | --------------------------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: That is not safe. For instance we lack a struct req in a background fetch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 15 10:24:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Sep 2014 10:24:25 -0000 Subject: [Varnish] #1593: addition of checkconfig in init scripts In-Reply-To: <041.5a1f245c3cb06544d523420137c3de93@varnish-cache.org> References: <041.5a1f245c3cb06544d523420137c3de93@varnish-cache.org> Message-ID: <056.a0579a2530f8b38a30d44e2f585d3b12@varnish-cache.org> #1593: addition of checkconfig in init scripts -------------------------+---------------------------------- Reporter: Tin | Owner: lkarsten Type: enhancement | Status: new Priority: low | Milestone: Varnish 4.0 release Component: packaging | Version: unknown Severity: minor | Resolution: Keywords: | -------------------------+---------------------------------- Changes (by lkarsten): * owner: => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 15 10:44:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Sep 2014 10:44:11 -0000 Subject: [Varnish] #1591: varnishtop contains duplicate entries In-Reply-To: <041.63b5bb01c6c5c9f16226141d9ddcb037@varnish-cache.org> References: <041.63b5bb01c6c5c9f16226141d9ddcb037@varnish-cache.org> Message-ID: <056.b4b3cd57faf0207b2bfddf46dd522c76@varnish-cache.org> #1591: varnishtop contains duplicate entries --------------------+-------------------- Reporter: kwy | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by lkarsten): I was able to reproduce this on 4.0.1. Steps: Start a fresh varnishd and varnishtop. Run a few requests for the same URL. Run some other requests for a different URL, then the original again. See that the URLs are not grouped together as they should. Example output from varnishtop: {{{ 0.91 BereqURL /foo/ 0.72 BereqURL /foo/ 0.69 BereqURL /foo/?fadsf 0.68 BereqURL /foo/?fadsf 0.67 BereqURL /foo/?fadsf 0.67 BereqURL /foo/?fadsf 0.65 BereqURL /foo/?fadsf 0.64 BereqURL /foo/?fadsf 0.64 BereqURL /foo/?fadsf }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 15 11:59:31 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Sep 2014 11:59:31 -0000 Subject: [Varnish] #1596: Panic message:#012Assert error in vbf_fetch_thread() In-Reply-To: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org> References: <042.d9350527a7cf3785712b05b2dacec0cd@varnish-cache.org> Message-ID: <057.c65c9bbb5445888971a2bb105f3b5210@varnish-cache.org> #1596: Panic message:#012Assert error in vbf_fetch_thread() --------------------+---------------------------------- Reporter: webi | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: 4.0.1 Severity: normal | Resolution: Keywords: | --------------------+---------------------------------- Comment (by martin): Hi, Is this something that you are able to easily reproduce? We have failed to be able to reproduce this behavior... I have attached a patch to this ticket that adds some debugging log lines in order to better understand what is happening. Would you be able to apply this patch to your Varnish and rerun the tests? Our wishlist :) {{{ 1) Apply the patch to the Varnish 2) Set syncvsl debug flag (-p debug=+syncvsl) 3) Capture varnishlog (varnishlog -g raw -O /tmp/varnish.log) 4) Reproduce the bug 5) Capture the panic report (varnishadm panic.show) 6) Send log and panic message to the ticket. }}} Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 15 13:50:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Sep 2014 13:50:54 -0000 Subject: [Varnish] #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: In-Reply-To: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> References: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> Message-ID: <057.2370a6baa4f78e6c8ad5707bcb526e97@varnish-cache.org> #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: ---------------------+-------------------- Reporter: olli | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: blocker | Resolution: Keywords: | ---------------------+-------------------- Comment (by martin): This is caused by workspace exhaustion probably due to very large headers in use. You should increase the workspace size. Though this also triggered an assertion on the workspace release due to missing space for NULL termination of the string. This problem will be patched by making VRT_IP_string return empty string on no workspace. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 15 13:52:51 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Sep 2014 13:52:51 -0000 Subject: [Varnish] #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: In-Reply-To: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> References: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> Message-ID: <057.6d18b8a4e6b666edf4ff9ac61142e3d2@varnish-cache.org> #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: ---------------------+----------------------------------------------- Reporter: olli | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: blocker | Resolution: fixed Keywords: | ---------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * owner: => Martin Blix Grydeland * resolution: => fixed Comment: In [6382a1e67d7f2fc4131a80bb453e7f839a83659d]: {{{ #!CommitTicketReference repository="" revision="6382a1e67d7f2fc4131a80bb453e7f839a83659d" Bail out on workspace exhaustion in VRT_IP_string Fixes: #1592 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 15 14:50:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 15 Sep 2014 14:50:33 -0000 Subject: [Varnish] #1591: varnishtop contains duplicate entries In-Reply-To: <041.63b5bb01c6c5c9f16226141d9ddcb037@varnish-cache.org> References: <041.63b5bb01c6c5c9f16226141d9ddcb037@varnish-cache.org> Message-ID: <056.c496a0a23e9cb83f21bf2ca0a9f7ffc6@varnish-cache.org> #1591: varnishtop contains duplicate entries --------------------+----------------------------------------------- Reporter: kwy | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | --------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [1161711e1cb090e37c33d9f26d7682d2a97acf25]: {{{ #!CommitTicketReference repository="" revision="1161711e1cb090e37c33d9f26d7682d2a97acf25" Keep two trees in varnishtop, one for order and one for uniqueness. Fixes: #1591 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 16 07:31:55 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 16 Sep 2014 07:31:55 -0000 Subject: [Varnish] #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: In-Reply-To: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> References: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> Message-ID: <057.0c22102e0a895e5db6d91d77e4550842@varnish-cache.org> #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: ---------------------+----------------------------------------------- Reporter: olli | Owner: Martin Blix Grydeland Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: blocker | Resolution: Keywords: | ---------------------+----------------------------------------------- Changes (by olli): * status: closed => reopened * resolution: fixed => Comment: Hi, I raised the workspace-values, but sometimes I still get the error. Is it still not high enough?: workspace_backend 0.50M [bytes] workspace_client 0.50M [bytes] workspace_session 32k [bytes] workspace_thread 2k [bytes] (default) The Headers doesn't seem to be very big: {{{ 2014-09-16 09:25:21.279703500 Child (12609) died signal=6 2014-09-16 09:25:21.279746500 Child (12609) Panic message: 2014-09-16 09:25:21.279747500 Assert error in WS_Release(), cache/cache_ws.c line 225: 2014-09-16 09:25:21.279748500 Condition(bytes <= ws->e - ws->f) not true. 2014-09-16 09:25:21.279748500 thread = (cache-worker) 2014-09-16 09:25:21.279749500 ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll 2014-09-16 09:25:21.279749500 Backtrace: 2014-09-16 09:25:21.279750500 0x433fe5: pan_ic+0xc5 2014-09-16 09:25:21.279750500 0x44b573: WS_Release+0xb3 2014-09-16 09:25:21.279750500 0x442e28: VRT_IP_string+0x68 2014-09-16 09:25:21.279757500 0x7fdb8b0d312e: ./vcl.TTze9X0S.so(VGC_function_vcl_deliver+0xae) [0x7fdb8b0d312e] 2014-09-16 09:25:21.279758500 0x440817: vcl_call_method+0x187 2014-09-16 09:25:21.279759500 0x441728: VCL_deliver_method+0x48 2014-09-16 09:25:21.279759500 0x437e2e: cnt_deliver+0x1ce 2014-09-16 09:25:21.279759500 0x438531: CNT_Request+0x111 2014-09-16 09:25:21.279760500 0x41a510: ESI_Deliver+0x7d0 2014-09-16 09:25:21.279760500 0x43b2a8: V1D_Deliver+0x368 2014-09-16 09:25:21.279766500 req = 0x7fdb72cf2020 { 2014-09-16 09:25:21.279767500 sp = 0x7fdb6ecf4020, vxid = 1073840773, step = R_STP_DELIVER, 2014-09-16 09:25:21.279767500 req_body = R_BODY_NONE, 2014-09-16 09:25:21.279768500 restarts = 0, esi_level = 1 2014-09-16 09:25:21.279768500 sp = 0x7fdb6ecf4020 { 2014-09-16 09:25:21.279769500 fd = 219, vxid = 98917, 2014-09-16 09:25:21.279769500 client = 84.187.114.119 50037, 2014-09-16 09:25:21.279770500 step = S_STP_WORKING, 2014-09-16 09:25:21.279770500 }, 2014-09-16 09:25:21.279770500 worker = 0x7fdb86e49c50 { 2014-09-16 09:25:21.279820500 ws = 0x7fdb86e49e68 { 2014-09-16 09:25:21.279820500 id = "wrk", 2014-09-16 09:25:21.279820500 {s,f,r,e} = {0x7fdb86e49450,0x7fdb86e49450,(nil),+2048}, 2014-09-16 09:25:21.279821500 }, 2014-09-16 09:25:21.279821500 VCL::method = DELIVER, 2014-09-16 09:25:21.279821500 VCL::return = abandon, 2014-09-16 09:25:21.279826500 }, 2014-09-16 09:25:21.279826500 ws = 0x7fdb72cf21b8 { 2014-09-16 09:25:21.279826500 id = "req", 2014-09-16 09:25:21.279827500 {s,f,r,e} = {0x7fdb72cf4010,+56,(nil),+516112}, 2014-09-16 09:25:21.279827500 }, 2014-09-16 09:25:21.279827500 http[req] = { 2014-09-16 09:25:21.279827500 ws = 0x7fdb762951b8[req] 2014-09-16 09:25:21.279828500 "GET", 2014-09-16 09:25:21.279828500 "/esi/news.htn?esiPermId=90&headline=Nachrichten%20unserer%20Partner&limit=10&sektion=getEmittentenNewsBox&seite=CERT", 2014-09-16 09:25:21.279831500 "HTTP/1.1", 2014-09-16 09:25:21.279831500 "Accept: text/html, application/xhtml+xml, */*", 2014-09-16 09:25:21.279832500 "Accept-Language: de-DE", 2014-09-16 09:25:21.279832500 "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko", 2014-09-16 09:25:21.279832500 "DNT: 1", 2014-09-16 09:25:21.279833500 "Connection: Keep-Alive", 2014-09-16 09:25:21.279835500 "Host: www.finanztreff.de", 2014-09-16 09:25:21.279835500 "X-USF-clientip: 84.187.114.119", 2014-09-16 09:25:21.279836500 "X-Forwarded-For: 84.187.114.119, 84.187.114.119", 2014-09-16 09:25:21.279836500 "X-USF-ESI-Level: 1", 2014-09-16 09:25:21.279837500 }, 2014-09-16 09:25:21.279837500 http[resp] = { 2014-09-16 09:25:21.279837500 ws = 0x7fdb72cf21b8[req] 2014-09-16 09:25:21.279837500 "HTTP/1.1", 2014-09-16 09:25:21.279837500 "200", 2014-09-16 09:25:21.279840500 "OK", 2014-09-16 09:25:21.279840500 "Date: Tue, 16 Sep 2014 07:25:13 GMT", 2014-09-16 09:25:21.279840500 "Server: Apache", 2014-09-16 09:25:21.279841500 "X-USF-ESI-Include: 1", 2014-09-16 09:25:21.279841500 "Cache-Control: max-age=10", 2014-09-16 09:25:21.279841500 "Last-Modified: Tue, 16 Sep 2014 07:25:13 GMT", 2014-09-16 09:25:21.279842500 "Vary: Accept-Encoding,X-USF-Cookie", 2014-09-16 09:25:21.279846500 "Content-Encoding: gzip", 2014-09-16 09:25:21.279846500 "X-Powered-By: USF-10/80/048/32", 2014-09-16 09:25:21.279846500 "Expires: Tue, 16 Sep 2014 07:25:23 GMT", 2014-09-16 09:25:21.279847500 "Content-Type: text/html; charset=UTF-8", 2014-09-16 09:25:21.279847500 "X-Varnish: 98949 98859", 2014-09-16 09:25:21.279847500 "Age: 7", 2014-09-16 09:25:21.279848500 "Via: 1.1 varnish-v4", 2014-09-16 09:25:21.279848500 "X-USF-Cache: HIT", 2014-09-16 09:25:21.279851500 }, 2014-09-16 09:25:21.279851500 vcl = { 2014-09-16 09:25:21.279851500 srcname = { 2014-09-16 09:25:21.279852500 "input", 2014-09-16 09:25:21.279852500 "Builtin", 2014-09-16 09:25:21.279852500 "/usr/local/opt/varnish/etc/cookie.inc", 2014-09-16 09:25:21.279852500 "/usr/local/opt/varnish/etc/pool- push-a.inc", 2014-09-16 09:25:21.279853500 "/usr/local/opt/varnish/etc/push.inc", 2014-09-16 09:25:21.279853500 }, 2014-09-16 09:25:21.279853500 }, 2014-09-16 09:25:21.279856500 obj (REQ) = 0x7fdb7e508400 { 2014-09-16 09:25:21.279856500 vxid = 2147582507, 2014-09-16 09:25:21.279856500 http[obj] = { 2014-09-16 09:25:21.279857500 ws = 0x7fdb70508268[] 2014-09-16 09:25:21.279857500 "HTTP/1.1", 2014-09-16 09:25:21.279857500 "200", 2014-09-16 09:25:21.279857500 "OK", 2014-09-16 09:25:21.279858500 "Date: Tue, 16 Sep 2014 07:25:13 GMT", 2014-09-16 09:25:21.279858500 "Server: Apache", 2014-09-16 09:25:21.279858500 "X-USF-ESI-Include: 1", 2014-09-16 09:25:21.279861500 "Cache-Control: max-age=10", 2014-09-16 09:25:21.279861500 "Last-Modified: Tue, 16 Sep 2014 07:25:13 GMT", 2014-09-16 09:25:21.279862500 "Vary: Accept-Encoding,X-USF- Cookie", 2014-09-16 09:25:21.279862500 "Content-Encoding: gzip", 2014-09-16 09:25:21.279862500 "X-Powered-By: USF-10/80/048/32", 2014-09-16 09:25:21.279863500 "Expires: Tue, 16 Sep 2014 07:25:23 GMT", 2014-09-16 09:25:21.279863500 "Content-Type: text/html; charset=UTF-8", 2014-09-16 09:25:21.279876500 }, 2014-09-16 09:25:21.279876500 len = 997, 2014-09-16 09:25:21.279877500 store = { 2014-09-16 09:25:21.279877500 997 { 2014-09-16 09:25:21.279877500 1f 8b 08 00 00 00 00 00 00 ff e5 99 dd 72 da 3a |.............r.:| 2014-09-16 09:25:21.279878500 10 c7 ef fb 14 3b 9e 39 5c 15 cc 47 d2 10 6a c8 |.....;.9\..G..j.| 2014-09-16 09:25:21.279878500 40 6c da 4c 09 65 02 99 f6 2e 23 63 81 35 18 99 |@l.L.e....#c.5..| 2014-09-16 09:25:21.279881500 4a 72 69 b8 3e cf 70 9e a0 d7 7d 88 e6 c5 ce ca |Jri.>.p...}.....| 2014-09-16 09:25:21.279881500 [933 more] 2014-09-16 09:25:21.279882500 }, 2014-09-16 09:25:21.279882500 }, 2014-09-16 09:25:21.279882500 }, 2014-09-16 09:25:21.279882500 }, 2014-09-16 09:25:21.279882500 2014-09-16 09:25:21.279883500 2014-09-16 09:25:21.398696500 Child cleanup complete 2014-09-16 09:25:21.399361500 child (12848) Started 2014-09-16 09:25:21.440260500 Child (12848) said Child starts }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 13:41:56 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 13:41:56 -0000 Subject: [Varnish] #1415: [PATCH]: Debian init script - Verify the VCL before restart In-Reply-To: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> References: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> Message-ID: <058.4632ab8612b710fdc363738f72743a22@varnish-cache.org> #1415: [PATCH]: Debian init script - Verify the VCL before restart -----------------------+---------------------- Reporter: idl0r | Owner: ssm Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+---------------------- Changes (by slink): * owner: => ssm -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 13:42:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 13:42:49 -0000 Subject: [Varnish] #1415: [PATCH]: Debian init script - Verify the VCL before restart In-Reply-To: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> References: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> Message-ID: <058.e3c02da83eb1f102366b5a25f740eaf2@varnish-cache.org> #1415: [PATCH]: Debian init script - Verify the VCL before restart -----------------------+---------------------- Reporter: idl0r | Owner: ssm Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+---------------------- Comment (by lkarsten): Stig says that this in place in the Debian init scripts. We need to put it into the v-c.o packages as well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 13:45:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 13:45:28 -0000 Subject: [Varnish] #1192: RHEL6: Init-script not giving correct startup In-Reply-To: <044.184ff331e3ed28f8eba95a1c3e7eeaf7@varnish-cache.org> References: <044.184ff331e3ed28f8eba95a1c3e7eeaf7@varnish-cache.org> Message-ID: <059.ee5510a2029c6892e2692dd6700637c3@varnish-cache.org> #1192: RHEL6: Init-script not giving correct startup ----------------------+----------------------- Reporter: Ueland | Owner: tfheen Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by slink): phk @ VDD14Q3: The underlying issue has been solved. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 13:48:40 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 13:48:40 -0000 Subject: [Varnish] #1479: Building man pages fails when building outside of the source tree. In-Reply-To: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> References: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> Message-ID: <078.3287e57b3807006a47a01a6144c590c8@varnish-cache.org> #1479: Building man pages fails when building outside of the source tree. ----------------------+-------------------- Reporter: basile@? | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by slink): * owner: scoof => slink * status: needinfo => new -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 13:48:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 13:48:54 -0000 Subject: [Varnish] #1192: RHEL6: Init-script not giving correct startup In-Reply-To: <044.184ff331e3ed28f8eba95a1c3e7eeaf7@varnish-cache.org> References: <044.184ff331e3ed28f8eba95a1c3e7eeaf7@varnish-cache.org> Message-ID: <059.f9f3ad59164fcb4ead4b531aeb7e376a@varnish-cache.org> #1192: RHEL6: Init-script not giving correct startup ----------------------+--------------------- Reporter: Ueland | Owner: ingvar Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ----------------------+--------------------- Changes (by slink): * status: assigned => new * owner: tfheen => ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:09:20 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:09:20 -0000 Subject: [Varnish] #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.d04f8526414fd13592bb8089e19637d4@varnish-cache.org> #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+-------------------- Reporter: abdi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by slink): * owner: fgsch => phk * status: assigned => new Comment: decision from [[VDD14Q3]] * snapshot stack base pointer * determine space left on stack * make pcre recursion limit dynamic * log advice on stacksize if reaching limit * `pcre_match_limit_recursion` becomes a max -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:12:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:12:12 -0000 Subject: [Varnish] #1557: regsuball() doesn't honor lookahead assertion on repeated strings In-Reply-To: <059.714287d6d2b95c176d62f92faff8648e@varnish-cache.org> References: <059.714287d6d2b95c176d62f92faff8648e@varnish-cache.org> Message-ID: <074.80019cc0488b330b9082ae43f37645c1@varnish-cache.org> #1557: regsuball() doesn't honor lookahead assertion on repeated strings --------------------------------------+--------------------- Reporter: varnish@? | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: lookahead pcre regsuball | --------------------------------------+--------------------- Changes (by martin): * owner: tfheen => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:14:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:14:44 -0000 Subject: [Varnish] #1590: ESI does not handle C-L 0 and C-E gzip In-Reply-To: <043.caca5a4c3e722f0f36772cbca141b8fd@varnish-cache.org> References: <043.caca5a4c3e722f0f36772cbca141b8fd@varnish-cache.org> Message-ID: <058.7b8459589187295d168552ff44d13bf7@varnish-cache.org> #1590: ESI does not handle C-L 0 and C-E gzip --------------------+-------------------- Reporter: fgsch | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+-------------------- Changes (by fgsch): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:18:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:18:12 -0000 Subject: [Varnish] #1406: Setting a header to a falsy value than getting it returns true In-Reply-To: <053.67b679cfde5eb48e50df6e81d4e36d86@varnish-cache.org> References: <053.67b679cfde5eb48e50df6e81d4e36d86@varnish-cache.org> Message-ID: <068.5fe209be41e3d5736772fabb86acf672@varnish-cache.org> #1406: Setting a header to a falsy value than getting it returns true -----------------------------+----------------------- Reporter: brandonwamboldt | Owner: lkarsten Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 3.0.4 Severity: normal | Resolution: Keywords: | -----------------------------+----------------------- Comment (by lkarsten): Changing this back to the 3.0.2 behaviour this late in 3.0 would just make it even more confusing. I'll add a note to the upgrade notes, so it is more accessible. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:23:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:23:34 -0000 Subject: [Varnish] #1556: varnishlog will not run (LIBVARNISHAPI_1.2 & LIBVARNISHAPI_1.3 not found) In-Reply-To: <041.e676bf3287d1e96a45e1f9cf3159d57f@varnish-cache.org> References: <041.e676bf3287d1e96a45e1f9cf3159d57f@varnish-cache.org> Message-ID: <056.609d02c8753335139d234fcbf046d41a@varnish-cache.org> #1556: varnishlog will not run (LIBVARNISHAPI_1.2 & LIBVARNISHAPI_1.3 not found) --------------------+---------------------- Reporter: Tin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: invalid Keywords: | --------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => invalid Comment: In order to do have multiple installations on the same system, one would have to make sure the LD_LIBRARY_PATH points correctly to assist the system in selecting the right libraries. Closing as this is not a bug. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:25:19 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:25:19 -0000 Subject: [Varnish] #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true In-Reply-To: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> References: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> Message-ID: <056.efbd4781c8331bc86872eadfed97fbae@varnish-cache.org> #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: new Priority: high | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: major | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by slink): some races have been fixed regarding this and actually this could have the same cause as #1463, so I am closing this ticket. Please re-open if this still happens with master. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:25:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:25:28 -0000 Subject: [Varnish] #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true In-Reply-To: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> References: <041.7aff9e2db0d2036e852bdfd9a6ae4a8e@varnish-cache.org> Message-ID: <056.2eba63cfb5dce5eabfccd82f3573c011@varnish-cache.org> #1522: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 416: Condition((oc->exp_flags & (1<<7)) == 0) not true ----------------------+---------------------------------- Reporter: Jay | Owner: Type: defect | Status: closed Priority: high | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.0 Severity: major | Resolution: duplicate Keywords: | ----------------------+---------------------------------- Changes (by slink): * status: new => closed * resolution: => duplicate -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:29:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:29:21 -0000 Subject: [Varnish] #1539: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: In-Reply-To: <047.9e25f0913e70f9b448183830fc7e3ec7@varnish-cache.org> References: <047.9e25f0913e70f9b448183830fc7e3ec7@varnish-cache.org> Message-ID: <062.83f5203e5bd68855fda03ecfc2ce65f8@varnish-cache.org> #1539: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: -----------------------+---------------------------------- Reporter: shing6326 | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------- Comment (by slink): fgsch and myself think this is likely to be fixed in master. Would you please test master (or 4.0.2 when released) and re-open if this still happens then? Thank you -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:29:31 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:29:31 -0000 Subject: [Varnish] #1539: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: In-Reply-To: <047.9e25f0913e70f9b448183830fc7e3ec7@varnish-cache.org> References: <047.9e25f0913e70f9b448183830fc7e3ec7@varnish-cache.org> Message-ID: <062.09f227c3479a35d254bc6de1fb79accf@varnish-cache.org> #1539: Assert error in cnt_lookup(), cache/cache_req_fsm.c line 411: -----------------------+---------------------------------- Reporter: shing6326 | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | -----------------------+---------------------------------- Changes (by slink): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:30:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:30:34 -0000 Subject: [Varnish] #1546: vrt.h contains various director related declarations that are no longer referenced. In-Reply-To: <043.0159882f25c8535ca251116021ea50be@varnish-cache.org> References: <043.0159882f25c8535ca251116021ea50be@varnish-cache.org> Message-ID: <058.db8a1c62c8220d58dfe9cf8d92be3245@varnish-cache.org> #1546: vrt.h contains various director related declarations that are no longer referenced. ----------------------+-------------------- Reporter: daghf | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by slink): * owner: => slink -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:31:18 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:31:18 -0000 Subject: [Varnish] #1554: Panic Message - current master V1F_Setup_Fetch(), cache/cache_http1_fetch.c line 180 In-Reply-To: <048.e42c479ec50419283469017e67620cc5@varnish-cache.org> References: <048.e42c479ec50419283469017e67620cc5@varnish-cache.org> Message-ID: <063.b276f500234dcb0df3b9cc4871867ebe@varnish-cache.org> #1554: Panic Message - current master V1F_Setup_Fetch(), cache/cache_http1_fetch.c line 180 ------------------------+-------------------- Reporter: hjanuschka | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+-------------------- Changes (by slink): * owner: => slink * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:36:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:36:38 -0000 Subject: [Varnish] #1554: Panic Message - current master V1F_Setup_Fetch(), cache/cache_http1_fetch.c line 180 In-Reply-To: <048.e42c479ec50419283469017e67620cc5@varnish-cache.org> References: <048.e42c479ec50419283469017e67620cc5@varnish-cache.org> Message-ID: <063.0fde811341c71104b2cf87dae29baa38@varnish-cache.org> #1554: Panic Message - current master V1F_Setup_Fetch(), cache/cache_http1_fetch.c line 180 ------------------------+----------------------- Reporter: hjanuschka | Owner: slink Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Changes (by slink): * status: new => needinfo Comment: can you please re-check with current master? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:51:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:51:29 -0000 Subject: [Varnish] #1595: Make hash director nice enough not to reshuffle clients In-Reply-To: <046.b8b5495c9ae7262c83191e401922a992@varnish-cache.org> References: <046.b8b5495c9ae7262c83191e401922a992@varnish-cache.org> Message-ID: <061.59c6385a6990bf8b1acacb76a62fec4a@varnish-cache.org> #1595: Make hash director nice enough not to reshuffle clients -------------------------+---------------------- Reporter: zviratko | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | -------------------------+---------------------- Comment (by slink): If you want to go for the cookie based persistence, you can all of it in vcl. Use vmod cookie, set a cookie with an id for the backend you have chosen and then select the backend based on that cookie. Regarding non cookie-based persistence: If you were looking after a more stable hash director, this could help you: https://code.uplex.de/uplex-varnish/libvmod-vslp but in your case, VSLP won't help you. To the best of my knowledge, there is no vmod for varnish which would implement persistent sessions as f5 does and I don't think it would be a good idea anyway, because we would open a can of worms regarding distribution of state within varnish clusters. Finally, we don't use trac for enhancement request, so I'd suggest you either put your suggestion on [[Future_VMODS]] or contract someone to implement the feature you require. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 14:51:38 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 14:51:38 -0000 Subject: [Varnish] #1595: Make hash director nice enough not to reshuffle clients In-Reply-To: <046.b8b5495c9ae7262c83191e401922a992@varnish-cache.org> References: <046.b8b5495c9ae7262c83191e401922a992@varnish-cache.org> Message-ID: <061.e3d00fce412fc99486558e977babaa69@varnish-cache.org> #1595: Make hash director nice enough not to reshuffle clients -------------------------+---------------------- Reporter: zviratko | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Changes (by slink): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 15:02:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 15:02:54 -0000 Subject: [Varnish] #1546: vrt.h contains various director related declarations that are no longer referenced. In-Reply-To: <043.0159882f25c8535ca251116021ea50be@varnish-cache.org> References: <043.0159882f25c8535ca251116021ea50be@varnish-cache.org> Message-ID: <058.600064cd14d4fa5d257ac9098d8eef1c@varnish-cache.org> #1546: vrt.h contains various director related declarations that are no longer referenced. ----------------------+--------------------- Reporter: daghf | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Nils Goroll ): * status: new => closed * resolution: => fixed Comment: In [e1dcc194fa5508678fbd04416e326ca486f1dbf5]: {{{ #!CommitTicketReference repository="" revision="e1dcc194fa5508678fbd04416e326ca486f1dbf5" remove some unused declarations Fixes #1546 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 15:05:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 15:05:24 -0000 Subject: [Varnish] #1479: Building man pages fails when building outside of the source tree. In-Reply-To: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> References: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> Message-ID: <078.f270063c002e4349b04cab2de1cefc39@varnish-cache.org> #1479: Building man pages fails when building outside of the source tree. ----------------------+-------------------- Reporter: basile@? | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by slink): note to self: re-check if still fails -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 19:33:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 19:33:12 -0000 Subject: [Varnish] #1597: Running VCC-compiler failed, signal 11 Message-ID: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> #1597: Running VCC-compiler failed, signal 11 -------------------+---------------------- Reporter: Jay | Type: defect Status: new | Priority: normal Milestone: Later | Component: varnishd Version: trunk | Severity: normal Keywords: | -------------------+---------------------- {{{ varnishd (varnish-4.0.1 revision 58db58b) # varnishd -f default.vcl -F Running VCC-compiler failed, signal 11, core dumped VCL compilation failed --------------------- Running varnish 4.0.0 on the same machine and same config works fine (default.vcl is from the varnish files). #0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 #1 0x00007f77d717615c in _nss_files_initgroups_dyn (user=0x0, group=1, start=0x7fff36f57de8, size=0x7fff36f57e30, groupsp=0x7fff36f57e38, limit=65536, errnop=0x7f77d8eeb690) at nss_files/files-initgroups.c:97 #2 0x00007f77d76391ad in internal_getgrouplist (user=user at entry=0x0, group=group at entry=1, size=size at entry=0x7fff36f57e30, groupsp=groupsp at entry=0x7fff36f57e38, limit=65536) at initgroups.c:112 #3 0x00007f77d76394ba in initgroups (user=0x0, group=1) at initgroups.c:219 #4 0x000000000045678c in mgt_sandbox_unix (who=SANDBOX_VCC) at mgt/mgt_sandbox.c:76 #5 0x0000000000456919 in mgt_sandbox_linux (who=) at mgt/mgt_sandbox.c:96 #6 0x0000000000457494 in run_vcc (priv=0x7fff36f59eb0) at mgt/mgt_vcc.c:140 #7 0x00007f77d8acb024 in VSUB_run (sb=sb at entry=0x1ae8d30, func=func at entry=0x457440 , priv=priv at entry=0x7fff36f59eb0, name=name at entry=0x47bde0 "VCC-compiler", maxlines=maxlines at entry=-1) at vsub.c:104 #8 0x00000000004577e8 in mgt_run_cc (status=0x7fff36f59f14, C_flag=0, sb=0x1ae8d30, vcl=) at mgt/mgt_vcc.c:263 #9 mgt_VccCompile (sb=0x7fff36f59f18, b=0x1aeb4a0 "# new 4.0 format.\nvcl 4.0;\n\n# Default backend definition. Set this to point to your content server.\nbackend default {\n .host = \"1.2.3.4\";\n .port = \"80\";\n}\n\nsub vcl_recv {\n # Happens bef"..., C_flag=0, status=0x7fff36f59f14) at mgt/mgt_vcc.c:340 #10 0x0000000000457ed3 in mgt_vcc_default (b_arg=b_arg at entry=0x0, f_arg=f_arg at entry=0x7fff36f5dd6a "default.vcl", vcl=vcl at entry=0x1aeb4a0 "# new 4.0 format.\nvcl 4.0;\n\n# Default backend definition. Set this to point to your content server.\nbackend default {\n .host = \"1.2.3.4\";\n .port = \"80\";\n}\n\nsub vcl_recv {\n # Happens bef"..., C_flag=C_flag at entry=0) at mgt/mgt_vcc.c:431 #11 0x000000000040ed94 in main (argc=, argv=) at mgt/mgt_main.c:654 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Sep 17 19:36:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 17 Sep 2014 19:36:16 -0000 Subject: [Varnish] #1597: Running VCC-compiler failed, signal 11 In-Reply-To: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> References: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> Message-ID: <056.c726c67e9a4756a9e6173187f1c69beb@varnish-cache.org> #1597: Running VCC-compiler failed, signal 11 ----------------------+-------------------- Reporter: Jay | Owner: Type: defect | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Jay): {{{ binutils 2.24 gcc 4.9.1 glibc 2.18 kernel 3.14.11 64-bit }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Sep 18 07:36:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 18 Sep 2014 07:36:30 -0000 Subject: [Varnish] #1554: Panic Message - current master V1F_Setup_Fetch(), cache/cache_http1_fetch.c line 180 In-Reply-To: <048.e42c479ec50419283469017e67620cc5@varnish-cache.org> References: <048.e42c479ec50419283469017e67620cc5@varnish-cache.org> Message-ID: <063.e48ee4d1bf8d556f43c4f777477d91a1@varnish-cache.org> #1554: Panic Message - current master V1F_Setup_Fetch(), cache/cache_http1_fetch.c line 180 ------------------------+----------------------- Reporter: hjanuschka | Owner: slink Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Comment (by hjanuschka): updated to master - seems to be fixed - atleast it didnt happen within 2h! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 19 08:30:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Sep 2014 08:30:25 -0000 Subject: [Varnish] #1594: Make server.* vars available everywhere In-Reply-To: <046.81961a1d4c266fdcc302a327adc3ade0@varnish-cache.org> References: <046.81961a1d4c266fdcc302a327adc3ade0@varnish-cache.org> Message-ID: <061.63633c3d331517102ba3591ef5f9f3cf@varnish-cache.org> #1594: Make server.* vars available everywhere --------------------------------------+---------------------- Reporter: tmagnien | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: invalid Keywords: server vars availability | --------------------------------------+---------------------- Comment (by lkarsten): I think this only applies to the socket-related operations? server.identity reads from heritage, and server.hostname is just a simple gethostname(). Those two I believe should be safe to run in the background context. Have I forgot about something? I wonder if it could be confusing to use "server.hostname" in such a context, since that is in fact the fetching client's (varnish) hostname. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 19 08:30:32 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Sep 2014 08:30:32 -0000 Subject: [Varnish] #1594: Make server.* vars available everywhere In-Reply-To: <046.81961a1d4c266fdcc302a327adc3ade0@varnish-cache.org> References: <046.81961a1d4c266fdcc302a327adc3ade0@varnish-cache.org> Message-ID: <061.5615aed42f994cb4870b52e19894af0e@varnish-cache.org> #1594: Make server.* vars available everywhere --------------------------------------+----------------------- Reporter: tmagnien | Owner: Type: enhancement | Status: reopened Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: Keywords: server vars availability | --------------------------------------+----------------------- Changes (by lkarsten): * status: closed => reopened * resolution: invalid => -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 19 09:33:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Sep 2014 09:33:57 -0000 Subject: [Varnish] #1597: Running VCC-compiler failed, signal 11 In-Reply-To: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> References: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> Message-ID: <056.57544bf03416f37b03a87282858ce4ce@varnish-cache.org> #1597: Running VCC-compiler failed, signal 11 ----------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Changes (by fgsch): * status: new => needinfo Comment: The problem here is initgroups() not getting an user. Do you have nobody in your passwd? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 19 09:46:01 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Sep 2014 09:46:01 -0000 Subject: [Varnish] #1597: Running VCC-compiler failed, signal 11 In-Reply-To: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> References: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> Message-ID: <056.5fe0f3a7e8b9746e6323e4582e087ee0@varnish-cache.org> #1597: Running VCC-compiler failed, signal 11 ----------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Comment (by Jay): There is no nobody user, but it works if I create it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 19 09:51:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Sep 2014 09:51:04 -0000 Subject: [Varnish] #1597: If user "nobody" is not in passwd varnishd will crash on initgroups (was: Running VCC-compiler failed, signal 11) In-Reply-To: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> References: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> Message-ID: <056.47879e5c325d64179a5be06ea4a3e79e@varnish-cache.org> #1597: If user "nobody" is not in passwd varnishd will crash on initgroups ----------------------+----------------------- Reporter: Jay | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 19 09:58:52 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Sep 2014 09:58:52 -0000 Subject: [Varnish] #1597: If user "nobody" is not in passwd varnishd will crash on initgroups In-Reply-To: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> References: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> Message-ID: <056.1d2f45faba251bf31362a6c7cbcf02e7@varnish-cache.org> #1597: If user "nobody" is not in passwd varnishd will crash on initgroups ----------------------+----------------------- Reporter: Jay | Owner: fgsch Type: defect | Status: assigned Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------- Changes (by fgsch): * status: needinfo => assigned * owner: => fgsch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 19 10:29:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Sep 2014 10:29:16 -0000 Subject: [Varnish] #1594: Make server.* vars available everywhere In-Reply-To: <046.81961a1d4c266fdcc302a327adc3ade0@varnish-cache.org> References: <046.81961a1d4c266fdcc302a327adc3ade0@varnish-cache.org> Message-ID: <061.e8bc5288cff110ee425bad994c6a5498@varnish-cache.org> #1594: Make server.* vars available everywhere -------------------------------------+------------------------------------- Reporter: tmagnien | Owner: Poul-Henning Kamp Type: enhancement | Priority: normal | Status: closed Component: build | Milestone: Severity: normal | Version: 4.0.1 Keywords: server vars | Resolution: fixed availability | -------------------------------------+------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: reopened => closed * resolution: => fixed Comment: In [890a45ae8af9d6e70a2365f209707370af1bc574]: {{{ #!CommitTicketReference repository="" revision="890a45ae8af9d6e70a2365f209707370af1bc574" Make server.hostname and server.identity available in all VCL methods. Closes #1594 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Sep 19 15:21:23 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 19 Sep 2014 15:21:23 -0000 Subject: [Varnish] #1415: [PATCH]: Debian init script - Verify the VCL before restart In-Reply-To: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> References: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> Message-ID: <058.67cbf50d17202f77b3b65c014175c8d6@varnish-cache.org> #1415: [PATCH]: Debian init script - Verify the VCL before restart -----------------------+---------------------- Reporter: idl0r | Owner: ssm Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+---------------------- Comment (by ssm): Committed to the debian repository, see http://anonscm.debian.org/cgit /pkg-varnish/pkg- varnish.git/commit/?id=8506ebc61edf42ed0bc517e9db3cbfd03f93a76d Relevant refs: git show debian/4.0.1-1...8506ebc61edf42ed0bc517e9db3cbfd03f93a76d -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 10:13:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 10:13:42 -0000 Subject: [Varnish] #1415: [PATCH]: Debian init script - Verify the VCL before restart In-Reply-To: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> References: <043.e3ff6a6de3d3f34370e3a3c2911903a8@varnish-cache.org> Message-ID: <058.992b6d2e50dfea4fe36b21ec91052744@varnish-cache.org> #1415: [PATCH]: Debian init script - Verify the VCL before restart -----------------------+----------------------- Reporter: idl0r | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+----------------------- Changes (by lkarsten): * owner: ssm => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 10:18:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 10:18:24 -0000 Subject: [Varnish] #1597: If user "nobody" is not in passwd varnishd will crash on initgroups In-Reply-To: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> References: <041.13e9e33e318f667cf325788e01225121@varnish-cache.org> Message-ID: <056.2af6fc2b7f8ce11d871c91cd7f40d7a2@varnish-cache.org> #1597: If user "nobody" is not in passwd varnishd will crash on initgroups ----------------------+--------------------- Reporter: Jay | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Later Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+--------------------- Changes (by martin): * status: assigned => new * owner: fgsch => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 11:14:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 11:14:13 -0000 Subject: [Varnish] #1554: Panic Message - current master V1F_Setup_Fetch(), cache/cache_http1_fetch.c line 180 In-Reply-To: <048.e42c479ec50419283469017e67620cc5@varnish-cache.org> References: <048.e42c479ec50419283469017e67620cc5@varnish-cache.org> Message-ID: <063.bc342c57eb0ffad32c1117510d5b0deb@varnish-cache.org> #1554: Panic Message - current master V1F_Setup_Fetch(), cache/cache_http1_fetch.c line 180 ------------------------+--------------------- Reporter: hjanuschka | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------- Changes (by martin): * status: needinfo => closed * resolution: => fixed Comment: This has been confirmed fixed, probably by b2b6e329da78e465720bec9a26a905e8a77cab92. Closing. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:35:50 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:35:50 -0000 Subject: [Varnish] #1598: Varnish asserts if the backend returns header lines without ':' and doing backend IMS Message-ID: <044.7e0667d88264f9f24aedc738cd60d6bd@varnish-cache.org> #1598: Varnish asserts if the backend returns header lines without ':' and doing backend IMS ----------------------+------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- See attached test case. The test case fails both current master and the 4.0 branch. Asserts on not finding the char ':' in the string in HTTP_Merge(). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:27 -0000 Subject: [Varnish] #1503: return(restart) seems to be changed into return(retry) In-Reply-To: <041.cf2573d353ec972ade6717eda53bca06@varnish-cache.org> References: <041.cf2573d353ec972ade6717eda53bca06@varnish-cache.org> Message-ID: <056.e3c48722f875674d2f443f43e9a2f63a@varnish-cache.org> #1503: return(restart) seems to be changed into return(retry) ---------------------------+--------------------- Reporter: Tin | Owner: scoof Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: return(retry) | ---------------------------+--------------------- Comment (by Lasse Karstensen ): In [016d66a084a9b2c2840135fce300962d1f1127f6]: {{{ #!CommitTicketReference repository="" revision="016d66a084a9b2c2840135fce300962d1f1127f6" Document the new return(retry). Backend restarts are now return(retry). Fixes: #1503 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: =?utf-8?q?Re=3A_=5BVarnish=5D_=231567=3A_error=3A_unused_variabl?= =?utf-8?b?ZSDigJh0duKAmSBhdCBjYWNoZV9hY2NlcHRvci5jIGF0IGNvbXBp?= =?utf-8?q?lation_time_=28Solaris_and_Cygwin=29?= In-Reply-To: <043.22f815a5f6d390bb075af3de6a0aa869@varnish-cache.org> References: <043.22f815a5f6d390bb075af3de6a0aa869@varnish-cache.org> Message-ID: <058.f474cf6283f1759f248411e062147a34@varnish-cache.org> #1567: error: unused variable ?tv? at cache_acceptor.c at compilation time (Solaris and Cygwin) --------------------+--------------------------------------------- Reporter: jdzst | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [1c965a1a612f3ae048241b0eccc735c0c6c079ae]: {{{ #!CommitTicketReference repository="" revision="1c965a1a612f3ae048241b0eccc735c0c6c079ae" Fix compilation if SO_{SND,RCV}TIMEO_WORKS is not defined Fixes #1567 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: [Varnish] #1555: configure not checking for readline.h, giving make error after fixing it. In-Reply-To: <041.90d39daf5df6b4940eecfab0845b4b93@varnish-cache.org> References: <041.90d39daf5df6b4940eecfab0845b4b93@varnish-cache.org> Message-ID: <056.a2c50c5a3d4fb65b7478b8824031298a@varnish-cache.org> #1555: configure not checking for readline.h, giving make error after fixing it. -------------------------------------------------+------------------------- Reporter: Tin | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: readline.h not checked by configure | script | -------------------------------------------------+------------------------- Comment (by Lasse Karstensen ): In [76dd3b7be9e27b48e5673949606795df03e2201e]: {{{ #!CommitTicketReference repository="" revision="76dd3b7be9e27b48e5673949606795df03e2201e" Rework autocrap configuration for libedit/libreadline As before, libedit is preferred over libreadline. Fail configure if neither is found or if libedit includes are missing. Require readline history support (as varnishadm needs it). Previously, if only libreadline was found, all binaries were linked against it. Now only binaries getting linked with LIBEDIT_LIBS will get linked aginst readline if libedit is not found. If configure succeeds, a build should not fail any longer due to libedit/libreadline headers missing. Fixes #1555 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: [Varnish] #1512: Changes to bereq are lost between v_b_r and v_b_f In-Reply-To: <043.04a15d59ba73f8274523e0e9150e84a7@varnish-cache.org> References: <043.04a15d59ba73f8274523e0e9150e84a7@varnish-cache.org> Message-ID: <058.ece2257843575560afcc1eb0597de57d@varnish-cache.org> #1512: Changes to bereq are lost between v_b_r and v_b_f ----------------------+--------------------- Reporter: fgsch | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Lasse Karstensen ): In [02ac12513cb5b7e4fda7e12c3a88f3000dd198e1]: {{{ #!CommitTicketReference repository="" revision="02ac12513cb5b7e4fda7e12c3a88f3000dd198e1" Ensure bereq changes are not lost across vcl_backend_xxx methods Add std.rollback() to rollback req or bereq and mark the builtin rollback as deprecated. Original diff by Nils Goroll. Tweaks and reworked after phk comments by me. Fixes #1512 Conflicts: bin/varnishd/cache/cache_fetch.c }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: [Varnish] #1578: Problem in the TTL calculation, if have age and max-age In-Reply-To: <042.93a8b52b6311da14732c1825ae36a8cc@varnish-cache.org> References: <042.93a8b52b6311da14732c1825ae36a8cc@varnish-cache.org> Message-ID: <057.da514e35b627497ab901220022a5088e@varnish-cache.org> #1578: Problem in the TTL calculation, if have age and max-age ----------------------+------------------------------------------ Reporter: xcir | Owner: Nils Goroll Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | ----------------------+------------------------------------------ Comment (by Lasse Karstensen ): In [e6d50a6b980bfbffce14df81a0093136bd61e55d]: {{{ #!CommitTicketReference repository="" revision="e6d50a6b980bfbffce14df81a0093136bd61e55d" Set default ttl (according to rfc2616 rules) to max-age, do not use Age twice With 160927b690dd076702601b7407eb71bd423c62dd t_origin got corrected by Age, so we already took the age the object had at fetch time into consideration for all other calculations. Fixes #1578 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: [Varnish] #1568: director.hash with req.http.Cookie && empty req.http.Cookie results in SIGSEGV In-Reply-To: <046.f62a984b7424f6d73a1a93d957d4563d@varnish-cache.org> References: <046.f62a984b7424f6d73a1a93d957d4563d@varnish-cache.org> Message-ID: <061.68e8b3b822b24e935674a37925c4d262@varnish-cache.org> #1568: director.hash with req.http.Cookie && empty req.http.Cookie results in SIGSEGV ------------------------------------+---------------------------------- Reporter: zviratko | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: segfault hash director | ------------------------------------+---------------------------------- Comment (by Lasse Karstensen ): In [2852b2d729ef0122ea6f08af2350f49ff49848f1]: {{{ #!CommitTicketReference repository="" revision="2852b2d729ef0122ea6f08af2350f49ff49848f1" Skip NULL and empty arguments when hashing. Hash all other arguments. When multiple arguments were passed to vmod_hash_backend, only the first argument was re-used for the number of arguments passed. Fixes #1568 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1572: better exit codes - varnishd -C should return correct exit value In-Reply-To: <046.db75c8527071670bee1f16144d3a434a@varnish-cache.org> References: <046.db75c8527071670bee1f16144d3a434a@varnish-cache.org> Message-ID: <061.570995b2f8b1d6e76cf9260ebac0068c@varnish-cache.org> #1572: better exit codes - varnishd -C should return correct exit value ----------------------+--------------------- Reporter: zviratko | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Lasse Karstensen ): In [3056ec64ca397ecb79c1b8b9f7c56b8dcbd78552]: {{{ #!CommitTicketReference repository="" revision="3056ec64ca397ecb79c1b8b9f7c56b8dcbd78552" varnishd: streamline exit codes, fix exit codes for vsubs This should bring us closer to the exit codes now documented in varnishd.rst Fixes #1572 for varnishd }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1572: better exit codes - varnishd -C should return correct exit value In-Reply-To: <046.db75c8527071670bee1f16144d3a434a@varnish-cache.org> References: <046.db75c8527071670bee1f16144d3a434a@varnish-cache.org> Message-ID: <061.568d6154a8896ecf179387916d02f483@varnish-cache.org> #1572: better exit codes - varnishd -C should return correct exit value ----------------------+--------------------- Reporter: zviratko | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Lasse Karstensen ): In [bda7856dee92b42e86735c4c6888190a7ea4c696]: {{{ #!CommitTicketReference repository="" revision="bda7856dee92b42e86735c4c6888190a7ea4c696" tools: streamline exit codes, fix exit codes for vsubs This should bring us closer to the exit codes now documented in varnishd.rst Fixes #1572 for tools }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1585: fatal sandbox errors are not fatal to varnishd In-Reply-To: <043.4abf283d80b5b78696ff6dc3bb4ea648@varnish-cache.org> References: <043.4abf283d80b5b78696ff6dc3bb4ea648@varnish-cache.org> Message-ID: <058.60d57364c86d9fbde901a083890d7aa8@varnish-cache.org> #1585: fatal sandbox errors are not fatal to varnishd ----------------------+--------------------- Reporter: slink | Owner: slink Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Lasse Karstensen ): In [5c54bd5d7c162f08d8543cf7d3043bec7c7869d4]: {{{ #!CommitTicketReference repository="" revision="5c54bd5d7c162f08d8543cf7d3043bec7c7869d4" Return 2 from VSUB_run() when the sub process dies with a signal. Fixes a regression from 33e6fe71743059b912d2b00cdbc08196b003e440 Fixes #1585 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1583: revisit solaris sandbox fatal error handling In-Reply-To: <043.2347ee3a8140e28771f796e7a7d5fc15@varnish-cache.org> References: <043.2347ee3a8140e28771f796e7a7d5fc15@varnish-cache.org> Message-ID: <058.b141a9e976e985f2385fd93fd0bddd59@varnish-cache.org> #1583: revisit solaris sandbox fatal error handling ----------------------+---------------------- Reporter: slink | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------- Comment (by Lasse Karstensen ): In [3d6268f839994a8a568129487e1a137ce0edc3ba]: {{{ #!CommitTicketReference repository="" revision="3d6268f839994a8a568129487e1a137ce0edc3ba" panic with INCOMPL() rather than exit(4) Fixes #1583 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1580: varnishd should warn/fail when both -b and -f argument are missing but -a present In-Reply-To: <048.2a0b53d943cfeb5bbd60300af37f41c3@varnish-cache.org> References: <048.2a0b53d943cfeb5bbd60300af37f41c3@varnish-cache.org> Message-ID: <063.df1da244ff224c8390e1b72b1b398e75@varnish-cache.org> #1580: varnishd should warn/fail when both -b and -f argument are missing but -a present ------------------------+--------------------- Reporter: our_martin | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ------------------------+--------------------- Comment (by Lasse Karstensen ): In [1c4e35f838f2e969dfc186c3b0fc9f3f8fbdd782]: {{{ #!CommitTicketReference repository="" revision="1c4e35f838f2e969dfc186c3b0fc9f3f8fbdd782" Add an informative warning when only starting the master process in daemon mode Fixes #1580 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1538: vcc_ParseImport still requires exact VMOD_ABI_Version match In-Reply-To: <046.4c2cb40392bce428250c0ea1ab787adc@varnish-cache.org> References: <046.4c2cb40392bce428250c0ea1ab787adc@varnish-cache.org> Message-ID: <061.5afd63512628360b5693cf485347856c@varnish-cache.org> #1538: vcc_ParseImport still requires exact VMOD_ABI_Version match ----------------------+--------------------------------------------- Reporter: askalski | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [3efca0bee53c39b9bcc4cf4ce62d31b0b671985c]: {{{ #!CommitTicketReference repository="" revision="3efca0bee53c39b9bcc4cf4ce62d31b0b671985c" Relax the vmod abi check if we are not in master For master we retain the more strict check in case we forget to bump the API version as discussed on irc. Implementation idea from scoof. Fixes #1538 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1569: having a subroutine named the same as backend results in Symbol not found In-Reply-To: <046.b47c55eccca631613556802863c1030c@varnish-cache.org> References: <046.b47c55eccca631613556802863c1030c@varnish-cache.org> Message-ID: <061.8786bf186ac641f9504ec79e0adee51e@varnish-cache.org> #1569: having a subroutine named the same as backend results in Symbol not found ----------------------+---------------------------------- Reporter: zviratko | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------- Comment (by Lasse Karstensen ): In [5a01820c20ef91a26c09a274588d41cd5713e11d]: {{{ #!CommitTicketReference repository="" revision="5a01820c20ef91a26c09a274588d41cd5713e11d" Fix an issue where the order of symbol definition determined if code could compile or not. Fixes #1569 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1466: struct req memory leak In-Reply-To: <044.405f83ccd9aea5f6bdeca16bd684d5a1@varnish-cache.org> References: <044.405f83ccd9aea5f6bdeca16bd684d5a1@varnish-cache.org> Message-ID: <059.e3f0e15976a5442b2711a587dd771d06@varnish-cache.org> #1466: struct req memory leak ----------------------+---------------------------------------- Reporter: martin | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [f0994a0bf0bc165fafbd8fc128b4aa1d0d6fe541]: {{{ #!CommitTicketReference repository="" revision="f0994a0bf0bc165fafbd8fc128b4aa1d0d6fe541" Don't leak struct req if we cannot restart it from a waiting list. Fixes: #1466 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: [Varnish] #1562: panic when retrying a short read of req.body - Wrong req_body_status in HTTP1_IterateReqBody() In-Reply-To: <043.34e20926e8817c4ffe68c76d33ea1b30@varnish-cache.org> References: <043.34e20926e8817c4ffe68c76d33ea1b30@varnish-cache.org> Message-ID: <058.50850ad4b3666949ea8b875069599a0d@varnish-cache.org> #1562: panic when retrying a short read of req.body - Wrong req_body_status in HTTP1_IterateReqBody() ----------------------+---------------------- Reporter: slink | Owner: slink Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: unknown Severity: critical | Resolution: fixed Keywords: | ----------------------+---------------------- Comment (by Lasse Karstensen ): In [0bd10ea0556d872f6115f6008233477e9ae1e62a]: {{{ #!CommitTicketReference repository="" revision="0bd10ea0556d872f6115f6008233477e9ae1e62a" Correctly fail bad reads in req.body Spotted and fixed by: Nils Goroll Fixes #1562 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: [Varnish] #1521: Varnish 4 VCL compilation failed on OSX x86_64 In-Reply-To: <046.e981867b3cf05ae3a7f8c85fb022c396@varnish-cache.org> References: <046.e981867b3cf05ae3a7f8c85fb022c396@varnish-cache.org> Message-ID: <061.c66393031be6c31252f58b6548b4671c@varnish-cache.org> #1521: Varnish 4 VCL compilation failed on OSX x86_64 ----------------------+---------------------------------------- Reporter: yoloseem | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [a5e6d3b1936d0ae87bc079520b9f1a6fa816baf5]: {{{ #!CommitTicketReference repository="" revision="a5e6d3b1936d0ae87bc079520b9f1a6fa816baf5" Varnishd needs to run the systems C-compiler to compile the VCL code. For security reasons, we run the C-compiler in a sandbox process which by default uses the same (non-)privileges as the other sandboxes (VCL compiler, test-loader process and the worker process). On some systems access to the C-compiler is limited, also for reasons of security, and varnishd will fail to compile VCL code, unless all the sandboxes are given access to the C-compiler. Add a new parameter "group_cc" which adds a single gid to the grouplist of the sandbox which executes the cc_command, for the benefit of such systems. Do some slightly related polishing of the docs/help-texts in this area while here anyway. Fixes #1521 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1407: Varnishd loses the ability to write to shared memory if you try to start it twice In-Reply-To: <053.90c213397c3b87bfe5b4975288bb67b4@varnish-cache.org> References: <053.90c213397c3b87bfe5b4975288bb67b4@varnish-cache.org> Message-ID: <068.c2b7166e36ca0f78a7bd88e40d2d7354@varnish-cache.org> #1407: Varnishd loses the ability to write to shared memory if you try to start it twice -----------------------------+--------------------- Reporter: brandonwamboldt | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | -----------------------------+--------------------- Comment (by Lasse Karstensen ): In [3826496b3a00e769ce580396a4f40efea423e491]: {{{ #!CommitTicketReference repository="" revision="3826496b3a00e769ce580396a4f40efea423e491" Don't rename the VSM file into place until we have started the child process during startup. Fixes #1407 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1414: r01391.vtc is unstable In-Reply-To: <046.d5a045f162e52112b625f28f45c5fb5b@varnish-cache.org> References: <046.d5a045f162e52112b625f28f45c5fb5b@varnish-cache.org> Message-ID: <061.f048b6c79789ec10c78c2cb5b6b89f82@varnish-cache.org> #1414: r01391.vtc is unstable -------------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [abe621845787c100e90358b138e8600e48aaaaf5]: {{{ #!CommitTicketReference repository="" revision="abe621845787c100e90358b138e8600e48aaaaf5" Reinstate this testcase, but make the servers failure to deliver non-fatal. Fixes: #1414 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1546: vrt.h contains various director related declarations that are no longer referenced. In-Reply-To: <043.0159882f25c8535ca251116021ea50be@varnish-cache.org> References: <043.0159882f25c8535ca251116021ea50be@varnish-cache.org> Message-ID: <058.6892a087f552088888c460209cd09b4b@varnish-cache.org> #1546: vrt.h contains various director related declarations that are no longer referenced. ----------------------+--------------------- Reporter: daghf | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Lasse Karstensen ): In [cebdf0524ef36d6d7c9190315f40725030138fc9]: {{{ #!CommitTicketReference repository="" revision="cebdf0524ef36d6d7c9190315f40725030138fc9" remove some unused declarations Fixes #1546 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: [Varnish] #1579: vcc: conversion to string with + operator incomplete In-Reply-To: <043.08508ce0f1d194a71a635e91c4b7fd66@varnish-cache.org> References: <043.08508ce0f1d194a71a635e91c4b7fd66@varnish-cache.org> Message-ID: <058.e7260055a551ff172cdd4ca6a71d61c9@varnish-cache.org> #1579: vcc: conversion to string with + operator incomplete ----------------------+---------------------------------- Reporter: slink | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------- Comment (by Lasse Karstensen ): In [7d99e1be1c0b772fb84db18bce12eb69c09a22f1]: {{{ #!CommitTicketReference repository="" revision="7d99e1be1c0b772fb84db18bce12eb69c09a22f1" Rework how we infer types in the VCC expresion evaluator. This mainly (only ?) changes things when we ask for an expression of type STRING or STTRING_LIST. Previously addition and subtraction would follow the general rule, "first argument determines intial type" and that would make an expression like this fail: set resp.http.server_port_foo = std.port(server.ip) + "_foo"; Because the addition tries to evaluate "INT + STRING". The idea was that people would rewrite this as: set resp.http.server_port_foo = "" + std.port(server.ip) + "_foo"; To make the first argument STRING and everything will then just work. However, this is needlessly strict in the case where we are actively desiring the expression to evaluate to STRING -- like above where resp.http.* has type STRING. With the new code, when an impossible addition is encountered, it will look at the type requested of the expression, and if it is STRING, convert the current subexpression to STRING and continue adding. A large number of subtests which are designed to fail started working with this change, they have been fixed by not using *.http.* variables as scaffolding.. You can still get into some weird corner-cases like the difference between: set resp.http.foobar = req.ttl + 1s + "_" + req.ttl + 1s; and set resp.http.foobar = req.ttl + 1s + "_" + req.ttl + 1; and set resp.http.foobar = req.ttl + 1s + "_" + (req.ttl + 1s); (Hint: The last one is the only one which does what you think) Fixes #1579 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: [Varnish] #1547: panic when increasing shm_reclen In-Reply-To: <050.6ed11e37793b6c87e37bc1f1cd78d4ba@varnish-cache.org> References: <050.6ed11e37793b6c87e37bc1f1cd78d4ba@varnish-cache.org> Message-ID: <065.b077bad31d12aa7383e877f5b8d4d293@varnish-cache.org> #1547: panic when increasing shm_reclen ---------------------------+---------------------------------------- Reporter: mattrobenolt | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: panic, shmlog | ---------------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [14a9cbc1eab47addf113b05375fb2013c85cf5eb]: {{{ #!CommitTicketReference repository="" revision="14a9cbc1eab47addf113b05375fb2013c85cf5eb" Rename shm_reclen to vsl_reclen for consistency. Leave shm_reclen as a parameter alias for now. Parameter vsl_buffer must be 12 bytes larger than vsl_reclen in order to avoid a panic when we try to put 12 pounds of VSL into a 5 pound vsl_buffer sack. Tweak the opposite parameter Minimum or Maximum value when we set one of of these parameters. Fixes #1547 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: In-Reply-To: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> References: <042.1f68645543388d83b35e9ebe2e4c9d2c@varnish-cache.org> Message-ID: <057.2cae8c55d3aba892a57703accf9deafc@varnish-cache.org> #1592: Assert error in WS_Release(), cache/cache_ws.c line 225: ---------------------+----------------------------------------------- Reporter: olli | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: blocker | Resolution: fixed Keywords: | ---------------------+----------------------------------------------- Changes (by Lasse Karstensen ): * status: reopened => closed * resolution: => fixed Comment: In [29867c1eae2be7d51e61711a7b6aecd579c1065c]: {{{ #!CommitTicketReference repository="" revision="29867c1eae2be7d51e61711a7b6aecd579c1065c" Bail out on workspace exhaustion in VRT_IP_string Fixes: #1592 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: [Varnish] #1574: std.syslog creates empty syslog entry In-Reply-To: <046.b58d20ea1b6449358a9ac17c6df3c9c6@varnish-cache.org> References: <046.b58d20ea1b6449358a9ac17c6df3c9c6@varnish-cache.org> Message-ID: <061.5d34539a9bbc679636f818f64e78c3a6@varnish-cache.org> #1574: std.syslog creates empty syslog entry ----------------------+--------------------------------------------- Reporter: kipusoep | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: vmod | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: syslog | ----------------------+--------------------------------------------- Comment (by Lasse Karstensen ): In [c1acdee858db4719676e8bf5046a2a2c2595714e]: {{{ #!CommitTicketReference repository="" revision="c1acdee858db4719676e8bf5046a2a2c2595714e" Pass the right string to syslog() Fixes #1574 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1584: varnishncsa: format_requestline missing whitespace In-Reply-To: <043.005d215214c91003c1a275be2fd711ca@varnish-cache.org> References: <043.005d215214c91003c1a275be2fd711ca@varnish-cache.org> Message-ID: <058.03c92bde2e6f4205a7d8c257da9b1770@varnish-cache.org> #1584: varnishncsa: format_requestline missing whitespace -------------------------+-------------------------------------------- Reporter: stone | Owner: Lasse Karstensen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------- Comment (by Lasse Karstensen ): In [1eb0a36786e2d653daa14f28af514f516d30514d]: {{{ #!CommitTicketReference repository="" revision="1eb0a36786e2d653daa14f28af514f516d30514d" Do not log garbage requests. Requests that end up in the hard "400 Bad Request" handling used to be logged with incomplete data. (no method, maybe no path, possibly no proto, and no response status) Port scans or anything sending a byte and a linefeed would be logged. Since this is used for logging access to a web site, it makes more sense to skip these garbage requests. Fixes: #1584 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:28 -0000 Subject: [Varnish] #1563: Consider raising the client timeout in varnish test suite In-Reply-To: <044.079169cfe78321142561418cac22e845@varnish-cache.org> References: <044.079169cfe78321142561418cac22e845@varnish-cache.org> Message-ID: <059.43bbe913fc53ffe25f3b14ff2b0e419c@varnish-cache.org> #1563: Consider raising the client timeout in varnish test suite -------------------------+---------------------------------------- Reporter: ingvar | Owner: Poul-Henning Kamp Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: test | -------------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [873a6a03c71cdd64681d5a78a4a0100eb158914e]: {{{ #!CommitTicketReference repository="" revision="873a6a03c71cdd64681d5a78a4a0100eb158914e" Default the http timeout to half of the total testduration. Fixes #1563 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:29 -0000 Subject: [Varnish] #1591: varnishtop contains duplicate entries In-Reply-To: <041.63b5bb01c6c5c9f16226141d9ddcb037@varnish-cache.org> References: <041.63b5bb01c6c5c9f16226141d9ddcb037@varnish-cache.org> Message-ID: <056.89aa52a80de3a7e3442cdcca52438349@varnish-cache.org> #1591: varnishtop contains duplicate entries --------------------+----------------------------------------------- Reporter: kwy | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | --------------------+----------------------------------------------- Comment (by Lasse Karstensen ): In [0ce5d09115b9ea65651a0b3045bc2c52109e7ba2]: {{{ #!CommitTicketReference repository="" revision="0ce5d09115b9ea65651a0b3045bc2c52109e7ba2" Keep two trees in varnishtop, one for order and one for uniqueness. Fixes: #1591 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:38:47 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:38:47 -0000 Subject: [Varnish] #1598: Varnish asserts if the backend returns header lines without ':' and doing backend IMS In-Reply-To: <044.7e0667d88264f9f24aedc738cd60d6bd@varnish-cache.org> References: <044.7e0667d88264f9f24aedc738cd60d6bd@varnish-cache.org> Message-ID: <059.57c1d19dc1ea8a161198aa49192db155@varnish-cache.org> #1598: Varnish asserts if the backend returns header lines without ':' and doing backend IMS ----------------------+-------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by martin): Should we skip these headers during response parsing? Logged with SLT_BogoHeader? Or fail the backend response completely? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 14:53:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 14:53:54 -0000 Subject: [Varnish] #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.e151d577d6646466da4e43fa390d88cb@varnish-cache.org> #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+-------------------- Reporter: abdi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by phk): So this seems to be slightly more complicated than we thought when we talked about it at VDD I played a bit around with the canonical "palindrome-checker" RE "(\w)(?:(?R)|\w?)\1" If I don't JIT compile it, it eats up 3456 bytes of stack per recursion (FreeBSD-current/amd64/CLANG) If I do JIT compile it, it eats up approx 32kB for all recursion levels up to at least 25 Neither number looks like anything actionable... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 16:40:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 16:40:44 -0000 Subject: [Varnish] #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.e0c07a5cf743f6d3b8901d1307b13e8c@varnish-cache.org> #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+-------------------- Reporter: abdi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by slink): phk, your jit results match pcrejit(3): > (jit) uses 32K on the machine stack. However, some large or complicated patterns need more than this. For the case without jit, I wonder how you determined the significant stack memory requirement. I ran this simple check: {{{ $ ./pcretest -m -M PCRE version 8.36-RC1 2014-04-21 re> "(\w)(?:(?R)|\w?)\1" Memory allocation (code space): 33 data> tattarrattat Minimum match() limit = 55 Minimum match() recursion limit = 38 0: tattarrattat 1: t }}} * when `pcretest` presented the prompt: {{{ slink at haggis:~$ pmap -x $(pgrep pcretest) | grep stack 00007fffd2227000 132 12 12 rw--- [ stack ] }}} * after matching tattarrattat {{{ slink at haggis:~$ pmap -x $(pgrep pcretest) | grep stack 00007fffd2227000 132 36 36 rw--- [ stack ] }}} So the 38 recursions have used ~700 bytes each -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 22 20:34:44 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 22 Sep 2014 20:34:44 -0000 Subject: [Varnish] #1599: std.syslog in V4 regression Message-ID: <047.47394859bf9579922d3bcdf05e7060b3@varnish-cache.org> #1599: std.syslog in V4 regression -----------------------+--------------------- Reporter: pstanhope | Type: defect Status: new | Priority: highest Milestone: Later | Component: vmod Version: 4.0.1 | Severity: blocker Keywords: | -----------------------+--------------------- 've just found a regression in the syslog functionality in v4 std module. Not sure when/where it emerged. The log(...) method and the syslog(...) methods where updated to use workspace. But the implementation is slightly different and the result is that the syslog method writes an empty string to syslog. ... CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); u = WS_Reserve(ctx->ws, 0); p = ctx->ws->f; va_start(ap, fmt); p = VRT_StringList(p, u, fmt, ap); va_end(ap); if (p != NULL) syslog((int)fac, "%s", p); WS_Release(ctx->ws, 0); ... I think it should be: ... txt t; CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); u = WS_Reserve(ctx->ws, 0); t.b = ctx->ws->f; va_start(ap, fmt); t.e = VRT_StringList(t.b, u, fmt, ap); va_end(ap); if (t.e != NULL) { assert(t.e > t.b); t.e--; syslog((int)fac, "%s", t.b); } WS_Release(ctx->ws, 0); ... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 23 06:48:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Sep 2014 06:48:54 -0000 Subject: [Varnish] #1599: std.syslog in V4 regression In-Reply-To: <047.47394859bf9579922d3bcdf05e7060b3@varnish-cache.org> References: <047.47394859bf9579922d3bcdf05e7060b3@varnish-cache.org> Message-ID: <062.c1571d630b8d6052f1d268f6f574c7e5@varnish-cache.org> #1599: std.syslog in V4 regression -----------------------+------------------------ Reporter: pstanhope | Owner: Type: defect | Status: closed Priority: highest | Milestone: Later Component: vmod | Version: 4.0.1 Severity: blocker | Resolution: duplicate Keywords: | -----------------------+------------------------ Changes (by scoof): * status: new => closed * resolution: => duplicate Comment: Duplicate of #1574 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 23 07:48:54 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Sep 2014 07:48:54 -0000 Subject: [Varnish] #1598: Varnish asserts if the backend returns header lines without ':' and doing backend IMS In-Reply-To: <044.7e0667d88264f9f24aedc738cd60d6bd@varnish-cache.org> References: <044.7e0667d88264f9f24aedc738cd60d6bd@varnish-cache.org> Message-ID: <059.21812a9ebc0d37b46b9c2b43d40a04f2@varnish-cache.org> #1598: Varnish asserts if the backend returns header lines without ':' and doing backend IMS ----------------------+---------------------------------------- Reporter: martin | 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 [3eae7f22a8e842f47c169cfb1f4fd335b0af65da]: {{{ #!CommitTicketReference repository="" revision="3eae7f22a8e842f47c169cfb1f4fd335b0af65da" Issue 400 code if header lines lack a ':' Fixes #1598 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 23 13:09:31 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Sep 2014 13:09:31 -0000 Subject: [Varnish] #1561: Assert error in VDP_gunzip(), cache/cache_gzip.c line 303 In-Reply-To: <043.94d8bf6c1454372600896f1e48ff1180@varnish-cache.org> References: <043.94d8bf6c1454372600896f1e48ff1180@varnish-cache.org> Message-ID: <058.a9fbec0d5ff85ef0790c7641acf4044c@varnish-cache.org> #1561: Assert error in VDP_gunzip(), cache/cache_gzip.c line 303 ----------------------+---------------------------------------- Reporter: Corey | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [752a95f1fc5bb60cf7e592dac8f34489623dad7a]: {{{ #!CommitTicketReference repository="" revision="752a95f1fc5bb60cf7e592dac8f34489623dad7a" Ensure that we never call a VDP with a zero length unless we are done. Fixes #1561 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 23 13:09:31 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Sep 2014 13:09:31 -0000 Subject: [Varnish] #1553: Assert error in VRY_Prep(), cache/cache_vary.c line 228 In-Reply-To: <048.d61504fcef043c3b9a266da23e519164@varnish-cache.org> References: <048.d61504fcef043c3b9a266da23e519164@varnish-cache.org> Message-ID: <063.728ae886560fad6c3087511291440e9c@varnish-cache.org> #1553: Assert error in VRY_Prep(), cache/cache_vary.c line 228 ----------------------------+---------------------------------------- Reporter: esfourteen | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: fixed Keywords: panic vry_prep | ----------------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [e38860038b92e4e2e0b27882fd9af5ab487665a3]: {{{ #!CommitTicketReference repository="" revision="e38860038b92e4e2e0b27882fd9af5ab487665a3" Make a dedicated cleanup function for req->vary_? to match the dedicated setup function we have. Fixes #1553 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 23 13:09:31 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 23 Sep 2014 13:09:31 -0000 Subject: [Varnish] #1551: Panic message: Missing errorhandling code in HSH_Purge() In-Reply-To: <043.53e32d86a2b629abfc16269dbd859a95@varnish-cache.org> References: <043.53e32d86a2b629abfc16269dbd859a95@varnish-cache.org> Message-ID: <058.212e511fb8e57a78d55558afe7264ba8@varnish-cache.org> #1551: Panic message: Missing errorhandling code in HSH_Purge() ----------------------+---------------------------------------- Reporter: aduca | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Comment (by Lasse Karstensen ): In [dbaba7024a9775175b588260287bf6588ed6da9e]: {{{ #!CommitTicketReference repository="" revision="dbaba7024a9775175b588260287bf6588ed6da9e" If workspace_thread is not be big enough to hold all the objcore pointers that need to be purged we iterate until done. Fixes #1551 Conflicts: bin/varnishd/cache/cache_hash.c }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 29 10:01:35 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Sep 2014 10:01:35 -0000 Subject: [Varnish] #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.8ed71e64d7cffc52bdc2d29a0f08cec0@varnish-cache.org> #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+-------------------- Reporter: abdi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by slink): for completeness: phk had considered the palindrome _complexity_ as a measure for the recursion depth. When we take the actual recursion depth reported by pcre, the numbers are consistent -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 29 10:54:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Sep 2014 10:54:53 -0000 Subject: [Varnish] #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.c000215c4bd8b1dcb6c52f8dfb7a7cc0@varnish-cache.org> #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+-------------------- Reporter: abdi | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by slink): summary of irc discussion: On estimating stack per pcre recursion: * we could dynamically determine the stack space required per pcre recursion: implement a bin search on the pcre recursion limit to determine the minimal recursion depth for some RE and pattern and take the actual stack size used on this. add a safety margin and take this as our stack_bytes / pcre_recursion measure. * but we consider this an overdesign for now * we could run `pcretest` from autocrap and get our stacksize estimate {{{ pcretest -m -C [...] Match recursion uses stack: approximate frame size = 176 bytes }}} * trouble is that `pcretest` does not get installed with -dev packages on some distros (read: at least not on debian) * so we probably just start with 600 bytes The implementation should check the remaining stack space and set the pcre recursion limit accordingly On JIT: We'd want JIT as a per-RE flag only, not as a global flag -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 29 10:57:00 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Sep 2014 10:57:00 -0000 Subject: [Varnish] #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.7b940ab4a42cbfffac1c86a5c366f292@varnish-cache.org> #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+-------------------- Reporter: abdi | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by slink): * owner: phk => slink -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 29 14:34:02 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Sep 2014 14:34:02 -0000 Subject: [Varnish] #1479: Building man pages fails when building outside of the source tree. In-Reply-To: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> References: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> Message-ID: <078.02f2fa74637b60d2a62669cf92db80b5@varnish-cache.org> #1479: Building man pages fails when building outside of the source tree. ----------------------+--------------------- Reporter: basile@? | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Nils Goroll ): * status: new => closed * resolution: => fixed Comment: In [9d8b62f42276aa80540f22eb1bd1c12836954066]: {{{ #!CommitTicketReference repository="" revision="9d8b62f42276aa80540f22eb1bd1c12836954066" Fix out-of-tree builds Fixes #1479 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 29 16:33:10 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Sep 2014 16:33:10 -0000 Subject: [Varnish] #1479: Building man pages fails when building outside of the source tree. In-Reply-To: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> References: <063.6f43cc0cf0e819832d5e81676f409af7@varnish-cache.org> Message-ID: <078.661fd35808debf44a4d11000506561c5@varnish-cache.org> #1479: Building man pages fails when building outside of the source tree. ----------------------+--------------------- Reporter: basile@? | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Comment (by Nils Goroll ): In [5822d0ce45b99e03ee2e611c5ef0d74bfc6a585d]: {{{ #!CommitTicketReference repository="" revision="5822d0ce45b99e03ee2e611c5ef0d74bfc6a585d" Get the out-of-tree build of docs right - finally? Trouble is that sphinx only takes one source dir, but when we build out-of-tree, we need to both use sources from $(srcdir) as well as $(builddir). Fix this by hard-linking from $(srcdir) to $(builddir) and wait for someone to come up with an out-of-tree build on different file systems. Fixes #1479 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 29 17:47:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Sep 2014 17:47:07 -0000 Subject: [Varnish] #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.1e2ced63a9e750648ca30b9eec17565c@varnish-cache.org> #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+-------------------- Reporter: abdi | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by slink): I should have rtfm - pcreapi(3) makes official what we thought was an internal api: > The [stack frame] estimate [...] is obtained by calling pcre_exec with the values NULL, NULL, NULL, -999, and -999 for its first five arguments. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Sep 29 18:51:09 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 29 Sep 2014 18:51:09 -0000 Subject: [Varnish] #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 In-Reply-To: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> References: <042.4a3d8a5cb69dc6179ad46be4f593a479@varnish-cache.org> Message-ID: <057.fd819d7dcac59d36ff04250d09c9a344@varnish-cache.org> #1576: default pcre_match_limit_recursion and thread_pool_stack dont match - varnishd child process crashes with segfault error 6 in libpcre.so.3.13.1 ----------------------+-------------------- Reporter: abdi | Owner: slink Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.1 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by slink): note to self: Tollef says: should also re-enable JIT by default for >=8.32 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 30 09:09:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Sep 2014 09:09:42 -0000 Subject: [Varnish] #1590: ESI does not handle C-L 0 and C-E gzip In-Reply-To: <043.caca5a4c3e722f0f36772cbca141b8fd@varnish-cache.org> References: <043.caca5a4c3e722f0f36772cbca141b8fd@varnish-cache.org> Message-ID: <058.61af6039f44f93c4c1e18b9d24c901f9@varnish-cache.org> #1590: ESI does not handle C-L 0 and C-E gzip --------------------+--------------------- Reporter: fgsch | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [5aec8898c71b7cb8b18093af99733e4199d18e10]: {{{ #!CommitTicketReference repository="" revision="5aec8898c71b7cb8b18093af99733e4199d18e10" Don't bother with any of the beresp.body transformations (esi/gzip/gunzip) if we know the length to be zero. This is inspired by ticket #1590, even though I can't seem to see what Varnish does wrong in that case to begin with. Fixes #1590 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 30 09:20:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Sep 2014 09:20:42 -0000 Subject: [Varnish] #1487: VCL flow outdated In-Reply-To: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> References: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> Message-ID: <058.cc4f9cd83b1e1c8368aabac131ba07c0@varnish-cache.org> #1487: VCL flow outdated ---------------------------+---------------------------------------- Reporter: fgsch | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: low | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [4ad0d5bdfe45eb31111fb1d0b1a4aa72942b477d]: {{{ #!CommitTicketReference repository="" revision="4ad0d5bdfe45eb31111fb1d0b1a4aa72942b477d" Remove the outdated and increasingly misleading dot(1) state graphs from the source code. We now have a working documentation system and these state engines should be documented there, using appropriate tools. Fixes #1487 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 30 09:23:34 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Sep 2014 09:23:34 -0000 Subject: [Varnish] #1487: VCL flow outdated In-Reply-To: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> References: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> Message-ID: <058.b9829c5ecc5ced17504e5cb6b54dfaa5@varnish-cache.org> #1487: VCL flow outdated ---------------------------+---------------------------------------- Reporter: fgsch | Owner: Poul-Henning Kamp Type: defect | Status: reopened Priority: low | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+---------------------------------------- Changes (by slink): * status: closed => reopened * resolution: fixed => Comment: I actually got a requirement and budget to update the VCL DOT graphs because end users consider them really helpful. Wanted to start work last week, most likely will actually do this this week -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 30 09:23:41 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Sep 2014 09:23:41 -0000 Subject: [Varnish] #1487: VCL flow outdated In-Reply-To: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> References: <043.2941297aa37436de85ef9a12659189ae@varnish-cache.org> Message-ID: <058.8e7662aa65bd4ca58570ee7da46a2f9e@varnish-cache.org> #1487: VCL flow outdated ---------------------------+-------------------- Reporter: fgsch | Owner: slink Type: defect | Status: new Priority: low | Milestone: Component: documentation | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+-------------------- Changes (by slink): * status: reopened => new * owner: Poul-Henning Kamp => slink -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Sep 30 09:38:18 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 30 Sep 2014 09:38:18 -0000 Subject: [Varnish] #1590: ESI does not handle C-L 0 and C-E gzip In-Reply-To: <043.caca5a4c3e722f0f36772cbca141b8fd@varnish-cache.org> References: <043.caca5a4c3e722f0f36772cbca141b8fd@varnish-cache.org> Message-ID: <058.eb6a4e30589ee5deacdb72fe9e26540e@varnish-cache.org> #1590: ESI does not handle C-L 0 and C-E gzip --------------------+--------------------- Reporter: fgsch | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------- Comment (by fgsch): As I wrote privately, this is what vfp_gzip_init() does when content- length is 0 but ESI was not doing. Ticket #1320. With this change however the C-E header is not removed anymore, neither from ESI nor non-ESI cases. Also, the code to handle C-L 0 in vfp_gzip_init() should be killed. -- Ticket URL: Varnish The Varnish HTTP Accelerator