From varnish-bugs at varnish-cache.org Sat Feb 1 11:53:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 01 Feb 2014 11:53:12 -0000 Subject: [Varnish] #1424: skin jhinga lala Message-ID: <048.ceb49bdcd98af20675d08f126c90038a@varnish-cache.org> #1424: skin jhinga lala ------------------------+-------------------- Reporter: roniedward | Type: task Status: new | Priority: low Milestone: | Component: build Version: unknown | Severity: normal Keywords: AURAVIE | ------------------------+-------------------- not a halfbad makeup days it's what I have bad game day cell yeah I hope he's enjoyed my little nighthi gate routine don't forget to gather description blast at a low for all of it information all the details and a half lead to[http://goarticles.com/article/Skin-Care-and-Feel- Good/8382738/ AURAVIE] some products and nasty right down exactly yeah I'm address thanks to our high-fate write down a list of all fights aids from a tight asking carotenes said yes they see create guys thank you so much for watching and okay fail everybody its Angie and today's video isgonna be on my current skincare routine now I posted video a few months ago about my how my skin care routine was going to be changing the reason I wagons be changing is that on I realize that I was probably not doing the best things form skin for my page my stage in life can the problem is that wanted to take care of and really the way I was on 2nd it'sgoing under you can hold China where was I um yeah what I realized about my skincare routine is that I wasn't really giving a lot of thought and I was just going around not doing a lotof research doing things that people suggested that do om weather is because they're trying to sell me a service or you know they thought I would have good results with it but I wasn't doing the research myself what decided to do back in October when I posted that videoremember was to really do a lot of research and look carefully into with the products that I need at thispoint and two pursue those rather than just do it waskinda scattershot thing where I would be you know flipping Agassi agency and for something that looks curse that looks fantastic in a sense I'm going to be more useful if I use it so I'll run outand get that's how I was doing it that's fine to do when you were in your twenties and thirties and even I want to say your early fortiespress your body has its own internal clock ourselves know http://goarticles.com/article/Skin-Care-and-Feel-Good/8382738/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Feb 1 12:19:18 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 01 Feb 2014 12:19:18 -0000 Subject: [Varnish] #1425: skin care proper Message-ID: <048.f1f91937a3e3104224e5bfa749d70382@varnish-cache.org> #1425: skin care proper ------------------------+-------------------- Reporter: roniedward | Type: task Status: new | Priority: low Milestone: | Component: build Version: unknown | Severity: normal Keywords: AURAVIE | ------------------------+-------------------- building up with the right name for a couple months now let's start with ohm I wake up in the morning and what do Idol my face usually I look at it in America %uh got hits why is the Crypt Keeper looking back at me I tell you the [http://goarticles.com/article/Skin-Care-and-Feel-Good/8382738/ AURAVIE] morning is the worst time to look your it's always horrified by that I get the shower and I wash my face my a dermatologist recommended this line of products com Sarah b and this is what the face wash looks like put on the glasses and yes it's surmise and hyaluronic acid alright and so this is inexpensive you buy this is the drug store and it's probably twelve dollars for this big thing itsoMG 12 fluid ounces so this is a terrific bargain ohm and you know you just need one pulpit and it's a nice sealed container it's very neat tidbit?s very moisturizing now the reason it has high Laurent acidic it is because this is one of the compounds that has been shown to attract water and it attracts like a thousand times it swat in water and holds it so the number one thing that you can door your skin aside from where some sun block every day is to keep it hydrated this cleanser does not follow up and I love that about it because I feel like at this age anything that phones has a detergent in it and any detergents going to be stripping your skin and I don't mean that get my skin clean especially when I watched it so thoroughly at night so in the morning it doesn't really have a cleaning so because http://goarticles.com/article/Skin-Care-and-Feel-Good/8382738/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Feb 1 12:38:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 01 Feb 2014 12:38:12 -0000 Subject: [Varnish] #1426: skin jhinga lala Message-ID: <048.1009213b29bc7ba238b4cdb1518ccb69@varnish-cache.org> #1426: skin jhinga lala ------------------------+-------------------- Reporter: roniedward | Type: task Status: new | Priority: low Milestone: | Component: build Version: unknown | Severity: normal Keywords: AURAVIE | ------------------------+-------------------- use this I take my dropper I put one property squeeze your fingers together really tight cut this is liquid in it slides right not so squeeze your fingers [http://goarticles.com/article/Skin-Care-and-Feel- Good/8382738/ AURAVIE] together really tight put one drop their weather around rub it all over your face avoiding of course the com your eyes and your I orbital bone area and you know the corners of your mouth whatever extra I have I wrote down my neck I take another drought for I do my chest and I do that explains there right away you don't have to wait you can put on you are Voice Tracer now in the wintertime it?s so dry here that I'm using a stick creamy moisturizing during the day which you is usually my nighttime moisturizer for doing this summer but this is the one Olay Regenerate micro sculpting cream and this is really nice thick the Voice Tracer this is a one ounce jar think and I buy this a Costco there?s two jars in there about 30 thirty dollars thirty one dollars 1.7ounce jar so to these for 30 so I 15 bucks peace on this is a terrific moisturizer I love it on it goes on release okayed slid and I just next night skin feel quenched and you know kind of popped up in and I use the Neutrogena ultra sheer liquid an SPF 70 alright this is super sheer goes on really nicely I just you know basically put a line a bit down my finger and that's as much as Indeed for my face for the nonce better all over a given nice thick coating I and then I let that dry and set up you are um someone really http://goarticles.com/article/Skin-Care-and-Feel-Good/8382738/ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Feb 2 19:31:10 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 02 Feb 2014 19:31:10 -0000 Subject: [Varnish] #1372: Consistent crashes with seg fault error 4 in libc-2.12.so In-Reply-To: <045.a0d66f4881fdf144e127f5a22a64caca@varnish-cache.org> References: <045.a0d66f4881fdf144e127f5a22a64caca@varnish-cache.org> Message-ID: <060.56045ede0ae3b6d75734a9ebe9e66eb1@varnish-cache.org> #1372: Consistent crashes with seg fault error 4 in libc-2.12.so ----------------------+------------------------------ Reporter: tomypro | Owner: Type: defect | Status: new Priority: highest | Milestone: Varnish 3.0 dev Component: varnishd | Version: 3.0.4 Severity: blocker | Resolution: Keywords: | ----------------------+------------------------------ Comment (by tomypro): lkarsten, Thank you for your support with this ticket. We realized we had some inline C outcalls in the vcl file which caused the exception on the cloud servers due to missing libraries. This ticket can be closed. Thanks /T -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 3 11:10:10 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Feb 2014 11:10:10 -0000 Subject: [Varnish] #1372: Consistent crashes with seg fault error 4 in libc-2.12.so In-Reply-To: <045.a0d66f4881fdf144e127f5a22a64caca@varnish-cache.org> References: <045.a0d66f4881fdf144e127f5a22a64caca@varnish-cache.org> Message-ID: <060.8f9b59861184a4668d39e6d35638f897@varnish-cache.org> #1372: Consistent crashes with seg fault error 4 in libc-2.12.so ----------------------+------------------------------ Reporter: tomypro | Owner: Type: defect | Status: closed Priority: highest | Milestone: Varnish 3.0 dev Component: varnishd | Version: 3.0.4 Severity: blocker | Resolution: invalid Keywords: | ----------------------+------------------------------ Changes (by scoof): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 3 11:22:40 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Feb 2014 11:22:40 -0000 Subject: [Varnish] #1336: varnishlog fails to parse log records > 1016 bytes In-Reply-To: <045.8dadb7898aa21ef58549ee630dfa15bb@varnish-cache.org> References: <045.8dadb7898aa21ef58549ee630dfa15bb@varnish-cache.org> Message-ID: <060.d378248e0c42d824eb33c6ee500c9d0d@varnish-cache.org> #1336: varnishlog fails to parse log records > 1016 bytes ------------------------+--------------------- Reporter: mkasick | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: This issue has been fixed in the rewritten Varnish 4 API. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 4 10:48:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 04 Feb 2014 10:48:48 -0000 Subject: [Varnish] #1427: CLI timeout with no apparent load on the machine Message-ID: <043.ca02860bd747676f18c13cd8c162e36e@varnish-cache.org> #1427: CLI timeout with no apparent load on the machine ----------------------+----------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP2 Component: varnishd | Version: unknown Severity: normal | Keywords: ----------------------+----------------------------- When our malloc storage is full, we sometimes experience a CLI timeout and subsequent restart. The server is not loaded at the time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 4 10:54:49 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 04 Feb 2014 10:54:49 -0000 Subject: [Varnish] #1428: Fetch errors rapidly increases Message-ID: <043.91f1ff9302a7a6c6b683ac1dc822a759@varnish-cache.org> #1428: Fetch errors rapidly increases ----------------------+----------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP2 Component: varnishd | Version: unknown Severity: normal | Keywords: ----------------------+----------------------------- After reaching an uptime of little over the ttl of most objects, the (IMS?) fetches start failing rapidly with connect errors, but the backends are up at the time. Will try to get tcpdump next time this occurs. May be related to #1427 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 6 14:38:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 Feb 2014 14:38:03 -0000 Subject: [Varnish] #1429: build error on os x: vtc_varnish.c:816:36: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') Message-ID: <043.0c4c37ad262e3d9210a1a1a8be6d1423@varnish-cache.org> #1429: build error on os x: vtc_varnish.c:816:36: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') --------------------+------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- $ ./autogen.des && ./configure && make -j8 (..) Making all in varnishtest CC varnishtest-vtc.o CC varnishtest-vtc_client.o CC varnishtest-vtc_main.o CC varnishtest-vtc_http.o CC varnishtest-vtc_log.o CC varnishtest-vtc_sema.o CC varnishtest-vtc_server.o CC varnishtest-vtc_varnish.o vtc_varnish.c:816:36: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] av[0], sp.val, av[1], av[2], ref); ^~~ 1 error generated. make[3]: *** [varnishtest-vtc_varnish.o] Error 1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 6 17:46:00 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 Feb 2014 17:46:00 -0000 Subject: [Varnish] #1430: Uncaught syntax error in VCL compiler Message-ID: <046.d8da9fa7b3544130a000f534f306cc67@varnish-cache.org> #1430: Uncaught syntax error in VCL compiler ----------------------+-------------------- Reporter: mcollier | Type: defect Status: new | Priority: low Milestone: | Component: build Version: 3.0.5 | Severity: normal Keywords: | ----------------------+-------------------- I would like to report that the following VCL coding error (on my part) will possibly cause a server reboot, or at the very least dysfunctional varnish environment. I would think the VCL compiler should throw an exception. The error I made was in the first if statement which should read: {{{ if(req.http.host == "abc.com" || req.http.host == "123.com") { }}} Problem Code: {{{ sub vcl_recv { if(req.http.host == "abc.com" || "123.com") { include "wordpress-recv.vcl"; } else if(req.http.host == "xyz.com") { include "drupal-recv.vcl"; } else if(req.http.host ~ "^(www\.)?blah\.com") { error 750 "http://newblah.com"; } return (lookup); } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 7 11:13:15 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Feb 2014 11:13:15 -0000 Subject: [Varnish] #1430: Uncaught syntax error in VCL compiler In-Reply-To: <046.d8da9fa7b3544130a000f534f306cc67@varnish-cache.org> References: <046.d8da9fa7b3544130a000f534f306cc67@varnish-cache.org> Message-ID: <061.3a30f3be391eee320fab3ab95dbdf1ae@varnish-cache.org> #1430: Uncaught syntax error in VCL compiler ----------------------+-------------------- Reporter: mcollier | Owner: Type: defect | Status: new Priority: low | Milestone: Component: build | Version: 3.0.5 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by phk): Uhm, could you explain a bit more ? Basically the mistake you have made means that the first if() is always true, but I fail to see how that can compromise server integrity ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 7 11:29:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Feb 2014 11:29:45 -0000 Subject: [Varnish] #1429: build error on os x: vtc_varnish.c:816:36: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') In-Reply-To: <043.0c4c37ad262e3d9210a1a1a8be6d1423@varnish-cache.org> References: <043.0c4c37ad262e3d9210a1a1a8be6d1423@varnish-cache.org> Message-ID: <058.fafca111f686aa63870c993d596b856e@varnish-cache.org> #1429: build error on os x: vtc_varnish.c:816:36: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') --------------------+---------------------------------------- Reporter: perbu | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [f01131b30ff664f8cdf9657947cc178cbbf32416]: {{{ #!CommitTicketReference repository="" revision="f01131b30ff664f8cdf9657947cc178cbbf32416" Fix printf format nit. Fixes #1429 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 7 11:40:52 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Feb 2014 11:40:52 -0000 Subject: [Varnish] #1431: varnish 3.0.3 stops working - CLI communication error (hdr) Message-ID: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> #1431: varnish 3.0.3 stops working - CLI communication error (hdr) -----------------------+---------------------- Reporter: cherouvim | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: blocker Keywords: | -----------------------+---------------------- I have a low/average traffic site with varnish 3.0.3 fronting a tomcat. varnishstat gives around 20 client_req, 10 cache_hit, 6 cache_miss per second. Uptime has been great (2 months without a problem) but recently it hanged with: {{{ varnishd[1257]: CLI communication error (hdr) varnishd[1257]: Pushing vcls failed: varnishd[1257]: Stopping Child varnishd[1257]: Child (18715) said Child starts varnishd[1257]: ... varnishd[1257]: Child cleanup complete varnishd[1257]: Child (18715) said Child dies varnishd[1257]: Child (18715) died status=1 varnishd[1257]: Child cleanup complete }}} (full messages at http://pastebin.com/raw.php?i=NtmtWNtv) A varnish restart was required for the site to work. Why does this happen? And why can't varnish recover from this situation? Note that this child stop/start has happened once again 10 days ago but that time it was successful: http://pastebin.com/raw.php?i=TF6Y0tpr The VM running this has 10GB ram and the varnish configuration is: {{{ VARNISHD_PARAMS="-f /etc/varnish/vcl.conf -a :90 \ -p thread_pool_min=300 \ -p thread_pool_max=3000 \ -p thread_pool_add_delay=2 \ -s malloc,5G \ -T:6082 \ -u varnish" }}} I've read that a potential issue may be cli_timeout (default: 10 secs) and the advice is to increase it. Is this true? By how much? Also, I think this issue relates to ticket #1119. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 7 11:45:26 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Feb 2014 11:45:26 -0000 Subject: [Varnish] #1431: varnish 3.0.3 stops working - CLI communication error (hdr) In-Reply-To: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> References: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> Message-ID: <062.b04fe37ab2bf8d7b018c53167b61eefe@varnish-cache.org> #1431: varnish 3.0.3 stops working - CLI communication error (hdr) -----------------------+-------------------- Reporter: cherouvim | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: blocker | Resolution: Keywords: | -----------------------+-------------------- Comment (by cherouvim): Also note that when varnish froze the traffic was very very low (maybe 2 client_req per second) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 7 12:29:12 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Feb 2014 12:29:12 -0000 Subject: [Varnish] #1431: varnish 3.0.3 stops working - CLI communication error (hdr) In-Reply-To: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> References: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> Message-ID: <062.bc52f3f245452f6d06f63adc4b0f997b@varnish-cache.org> #1431: varnish 3.0.3 stops working - CLI communication error (hdr) -----------------------+-------------------- Reporter: cherouvim | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: blocker | Resolution: Keywords: | -----------------------+-------------------- Comment (by cherouvim): After some investigation on the exact times that those 2 restarts occured (the later one blocking varnish) it turns out that some increased disk i/o was happening from other processes (db backups, zip, etc). Is there a possibility that varnish's malloc was out of real memory so the o/s was swaping this to the disk, but disk was busy at that time? So the management process thought that the child process was dead because it was blocked waiting on i/o? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 7 14:02:08 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Feb 2014 14:02:08 -0000 Subject: [Varnish] #1430: Uncaught syntax error in VCL compiler In-Reply-To: <046.d8da9fa7b3544130a000f534f306cc67@varnish-cache.org> References: <046.d8da9fa7b3544130a000f534f306cc67@varnish-cache.org> Message-ID: <061.e30e824affc51566147da8d0ab972a9e@varnish-cache.org> #1430: Uncaught syntax error in VCL compiler ----------------------+-------------------- Reporter: mcollier | Owner: Type: defect | Status: new Priority: low | Milestone: Component: build | Version: 3.0.5 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by mcollier): Replying to [comment:1 phk]: > Uhm, could you explain a bit more ? > > Basically the mistake you have made means that the first if() is always true, but I fail to see how that can compromise server integrity ? Perhaps it was coincidence, but with the bad configuration, my server rebooted immediately after doing 'varnish start'. Since this is a production server, I'm afraid I won't be attempting to replicate the problem myself. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 10 10:50:07 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Feb 2014 10:50:07 -0000 Subject: [Varnish] #1430: Uncaught syntax error in VCL compiler In-Reply-To: <046.d8da9fa7b3544130a000f534f306cc67@varnish-cache.org> References: <046.d8da9fa7b3544130a000f534f306cc67@varnish-cache.org> Message-ID: <061.29e8da880ec89e507bf281864003ae69@varnish-cache.org> #1430: Uncaught syntax error in VCL compiler ----------------------+------------------------- Reporter: mcollier | Owner: Type: defect | Status: closed Priority: low | Milestone: Component: build | Version: 3.0.5 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I have tried to replicate this problem, and found no issues. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 11 13:56:53 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 Feb 2014 13:56:53 -0000 Subject: [Varnish] #1428: Fetch errors rapidly increases In-Reply-To: <043.91f1ff9302a7a6c6b683ac1dc822a759@varnish-cache.org> References: <043.91f1ff9302a7a6c6b683ac1dc822a759@varnish-cache.org> Message-ID: <058.ce34473a28c7fcb149441a69f097ee0a@varnish-cache.org> #1428: Fetch errors rapidly increases ----------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP2 Component: varnishd | Version: unknown Severity: normal | Resolution: fixed Keywords: | ----------------------+------------------------------ Changes (by scoof): * status: new => closed * resolution: => fixed Comment: Fixed in [0ccbd8320692becd41f27061737dbfede593550d] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 12 19:07:45 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 Feb 2014 19:07:45 -0000 Subject: [Varnish] #1432: Another build error on OS X Message-ID: <043.5a4782e7bfcb99ccafd99e18c408beba@varnish-cache.org> #1432: Another build error on OS X --------------------+--------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Keywords: --------------------+--------------------- {{{ $ ./autogen.des && ./configure && make -j9 (..) Making all in varnishstat CC varnishstat.o varnishstat.c:68:37: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] printf("\t\t%ju\n", val); ~~~ ^~~ %llu varnishstat.c:122:29: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] printf("\"value\": %ju, ", val); ~~~ ^~~ %llu varnishstat.c:183:31: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] printf("%12ju %12.2f %s\n", val, val / op->up, pt->desc->sdesc); ~~~~~ ^~~ %12llu varnishstat.c:185:29: error: format specifies type 'uintmax_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] printf("%12ju %12s %s\n", val, ". ", pt->desc->sdesc); ~~~~~ ^~~ %12llu 4 errors generated. make[3]: *** [varnishstat.o] Error 1 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 17 05:50:04 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Feb 2014 05:50:04 -0000 Subject: [Varnish] #1433: VMOD compile error: Can't determine vmod installation directory Message-ID: <046.9ac9c549867c00a4f57a347146e93b3d@varnish-cache.org> #1433: VMOD compile error: Can't determine vmod installation directory --------------------------------+-------------------- Reporter: mcollier | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.5 | Severity: minor Keywords: vmod compile error | --------------------------------+-------------------- I'm working on Debian Squeeze with Varnish varnish-3.0.5 revision 1a89b1f and the 'Variable Support' VMOD. I encountered the error: Can't "determine vmod installation directory" during the configure process for the VMOD. I determined that I could supply the path to my VMOD directory using the VMODDIR parameter, however, the documentation states that the VMOD directory should be discovered automatically. I am putting in this ticket to assist in determining why the automatic discovery did not work as advertised. I documented my experience further here: http://resilientresonance.com/content/installing-variable-support-vmod- varnish-cache -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 17 11:06:13 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Feb 2014 11:06:13 -0000 Subject: [Varnish] #1432: Another build error on OS X In-Reply-To: <043.5a4782e7bfcb99ccafd99e18c408beba@varnish-cache.org> References: <043.5a4782e7bfcb99ccafd99e18c408beba@varnish-cache.org> Message-ID: <058.8f1f921e36e3182bd2c0347475cc4d87@varnish-cache.org> #1432: Another build error on OS X --------------------+---------------------------------------- Reporter: perbu | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [c14936bcfff366c8aae97d159d5fcd98050a3058]: {{{ #!CommitTicketReference repository="" revision="c14936bcfff366c8aae97d159d5fcd98050a3058" Fix uintmax_t printf format arguments. Fixes #1432 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 17 11:21:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Feb 2014 11:21:25 -0000 Subject: [Varnish] #1431: varnish 3.0.3 stops working - CLI communication error (hdr) In-Reply-To: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> References: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> Message-ID: <062.33457ea68314dc23085c0002a95258d4@varnish-cache.org> #1431: varnish 3.0.3 stops working - CLI communication error (hdr) -----------------------+----------------------- Reporter: cherouvim | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: blocker | Resolution: Keywords: | -----------------------+----------------------- Changes (by lkarsten): * owner: => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 17 12:07:15 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Feb 2014 12:07:15 -0000 Subject: [Varnish] #1434: std.duration does not handle ms units Message-ID: <043.e5effd09d5223eb03876e96194ec6687@varnish-cache.org> #1434: std.duration does not handle ms units --------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- As per subject. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 17 12:14:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Feb 2014 12:14:48 -0000 Subject: [Varnish] #1435: bereq.{first_byte_timeout, between_bytes_timeout} ignored in vcl_pipe Message-ID: <043.e912e54e9fcdfc8b8607ae03b6ea22cf@varnish-cache.org> #1435: bereq.{first_byte_timeout,between_bytes_timeout} ignored in vcl_pipe --------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- generate.py marks these two variables available in vcl_pipe but the description says otherwise. Code inspection confirms they're not used. Either pipe needs to be removed from generate.py for these two variables or they should be supported and the description updated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 17 12:32:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Feb 2014 12:32:33 -0000 Subject: [Varnish] #1433: VMOD compile error: Can't determine vmod installation directory In-Reply-To: <046.9ac9c549867c00a4f57a347146e93b3d@varnish-cache.org> References: <046.9ac9c549867c00a4f57a347146e93b3d@varnish-cache.org> Message-ID: <061.3b466de49e26ad24e25df2654e8af385@varnish-cache.org> #1433: VMOD compile error: Can't determine vmod installation directory --------------------------------+------------------------- Reporter: mcollier | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.5 Severity: minor | Resolution: worksforme Keywords: vmod compile error | --------------------------------+------------------------- Changes (by martin): * status: new => closed * resolution: => worksforme Comment: This is very likely caused by the libvarnishapi-dev package not being installed on your computer. That package includes a pkgconfig file for Varnish, that will point to the right vmod directory. Without this, there is no way for the configuration script to find the right directory to use. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 17 12:36:46 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Feb 2014 12:36:46 -0000 Subject: [Varnish] #1422: varnishd keeps getting a SIGINT In-Reply-To: <049.bfe295782aa14e08240053a6e8dcb920@varnish-cache.org> References: <049.bfe295782aa14e08240053a6e8dcb920@varnish-cache.org> Message-ID: <064.43c505af679ff0b54c7308e800071c03@varnish-cache.org> #1422: varnishd keeps getting a SIGINT -------------------------+------------------------- Reporter: raymondjiii | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: normal | Resolution: worksforme Keywords: | -------------------------+------------------------- Changes (by martin): * status: new => closed * resolution: => worksforme Comment: Closing this as 'worksforme' due to lack of follow up information from the reporter and being unable to reproduce the problem. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 17 18:28:27 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Feb 2014 18:28:27 -0000 Subject: [Varnish] #1435: bereq.{first_byte_timeout, between_bytes_timeout} ignored in vcl_pipe In-Reply-To: <043.e912e54e9fcdfc8b8607ae03b6ea22cf@varnish-cache.org> References: <043.e912e54e9fcdfc8b8607ae03b6ea22cf@varnish-cache.org> Message-ID: <058.17845ec8b2e8cf7871803109644f5fb4@varnish-cache.org> #1435: bereq.{first_byte_timeout,between_bytes_timeout} ignored in vcl_pipe ----------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by fgsch): * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 17 18:30:22 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Feb 2014 18:30:22 -0000 Subject: [Varnish] #1434: std.duration does not handle ms units In-Reply-To: <043.e5effd09d5223eb03876e96194ec6687@varnish-cache.org> References: <043.e5effd09d5223eb03876e96194ec6687@varnish-cache.org> Message-ID: <058.87b0cd4c8a6428f80182fe701be06477@varnish-cache.org> #1434: std.duration does not handle ms units --------------------+-------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: vmod | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+-------------------- Changes (by fgsch): * component: build => vmod -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 21 10:56:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Feb 2014 10:56:59 -0000 Subject: [Varnish] #1436: VCL Compiler bug Message-ID: <043.61349668008cd62e039e675af2f166b9@varnish-cache.org> #1436: VCL Compiler bug --------------------+--------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Keywords: --------------------+--------------------- The VCL compiler seems to bail when confronted with the following VCL (missing import statement is the most obvious error): vcl 4.0; backend server1 { .host = "192.168.0.10"; } backend server2{ .host = "192.168.0.10"; } sub vcl_init { new bar = directors.round_robin(); bar.add_backend(server1, server2); } -- Error message: Missing errorhandling code in parse_new(), vcc_action.c line 193: Condition((sy2) != 0) not true. Running VCC-compiler failed, signal 6 VCL compilation failed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 21 10:57:24 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Feb 2014 10:57:24 -0000 Subject: [Varnish] #1436: VCL Compiler bug In-Reply-To: <043.61349668008cd62e039e675af2f166b9@varnish-cache.org> References: <043.61349668008cd62e039e675af2f166b9@varnish-cache.org> Message-ID: <058.e078cbc8e02fb1d21c1411f6b0783af7@varnish-cache.org> #1436: VCL Compiler bug --------------------+---------------------- Reporter: perbu | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+---------------------- Description changed by perbu: Old description: > The VCL compiler seems to bail when confronted with the following VCL > (missing import statement is the most obvious error): > > vcl 4.0; > > backend server1 { > .host = "192.168.0.10"; > } > > backend server2{ > .host = "192.168.0.10"; > } > > sub vcl_init { > new bar = directors.round_robin(); > bar.add_backend(server1, server2); > } > > -- > > Error message: > > Missing errorhandling code in parse_new(), vcc_action.c line 193: > Condition((sy2) != 0) not true. > Running VCC-compiler failed, signal 6 > > VCL compilation failed New description: {{{ The VCL compiler seems to bail when confronted with the following VCL (missing import statement is the most obvious error): vcl 4.0; backend server1 { .host = "192.168.0.10"; } backend server2{ .host = "192.168.0.10"; } sub vcl_init { new bar = directors.round_robin(); bar.add_backend(server1, server2); } -- Error message: Missing errorhandling code in parse_new(), vcc_action.c line 193: Condition((sy2) != 0) not true. Running VCC-compiler failed, signal 6 VCL compilation failed }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Feb 23 18:32:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 23 Feb 2014 18:32:59 -0000 Subject: [Varnish] #1437: varnish ESI randomly fetches whole page from backend even if present in cache Message-ID: <048.1429e7959f2b4a0f00d4fd44b16b8edb@varnish-cache.org> #1437: varnish ESI randomly fetches whole page from backend even if present in cache ------------------------+--------------------- Reporter: charanjeet | Type: defect Status: new | Priority: highest Milestone: | Component: build Version: unknown | Severity: normal Keywords: | ------------------------+--------------------- On refreshing the page, Varnish ESI is randomly fetching page from backend even if it was present in cache and it leaves nothing in varnishlog. After few refreshes, it again starts picking the cached page. I haven't set grace value. {{{ sub vcl_recv { if (req.http.Cookie ~ "(LoggedIn)") { if (req.url ~ "CACHEABLE"){ return (lookup); } if (req.url ~ "ESI") { return (pass); } return (pipe); } set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *__utm.=[^;]+;? *", "\1"); } sub vcl_fetch { if (req.http.Cookie ~ "(LoggedIn)") { if (req.url ~ "CACHEABLE"){ set beresp.do_esi = true; set beresp.ttl = 1m; } return(deliver); } }}} Can this be related to no of threads varnish can create? I read that while one object is being fetched from cache, if more requests pile up for for same object, they all wait for the first request to complete. It could be that probably this is not working. I also found an issue on varnish saying that varnishd sends multiple requests to the backend when an object times out. [https://www.varnish-cache.org/trac/ticket/1340] I am not able to make out some pattern for requests going to backend. Please suggest. Any insight would definitely help. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 11:05:19 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 11:05:19 -0000 Subject: [Varnish] #1436: VCL Compiler bug In-Reply-To: <043.61349668008cd62e039e675af2f166b9@varnish-cache.org> References: <043.61349668008cd62e039e675af2f166b9@varnish-cache.org> Message-ID: <058.9851c80398c4c0168e50b869517174c2@varnish-cache.org> #1436: VCL Compiler bug -------------------------+---------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishhist | Version: unknown Severity: normal | Resolution: Keywords: | -------------------------+---------------------- Changes (by phk): * owner: => phk * component: build => varnishhist -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 11:06:28 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 11:06:28 -0000 Subject: [Varnish] #1437: varnish ESI randomly fetches whole page from backend even if present in cache In-Reply-To: <048.1429e7959f2b4a0f00d4fd44b16b8edb@varnish-cache.org> References: <048.1429e7959f2b4a0f00d4fd44b16b8edb@varnish-cache.org> Message-ID: <063.527b9ecdfd733c09778cbc152d9953ee@varnish-cache.org> #1437: varnish ESI randomly fetches whole page from backend even if present in cache ------------------------+---------------------- Reporter: charanjeet | Owner: Type: defect | Status: new Priority: highest | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | ------------------------+---------------------- Comment (by lkarsten): This is most likely related to your use of return(pipe). You might want to look into setting "Connection: close" in vcl_pipe. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 11:06:30 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 11:06:30 -0000 Subject: [Varnish] #1436: VCL Compiler bug In-Reply-To: <043.61349668008cd62e039e675af2f166b9@varnish-cache.org> References: <043.61349668008cd62e039e675af2f166b9@varnish-cache.org> Message-ID: <058.f6e0f1926f640eb85c28666121019b7a@varnish-cache.org> #1436: VCL Compiler bug -------------------------+---------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishhist | Version: unknown Severity: normal | Resolution: Keywords: | -------------------------+---------------------- Description changed by daghf: Old description: > {{{ > The VCL compiler seems to bail when confronted with the following VCL > (missing import statement is the most obvious error): > > vcl 4.0; > > backend server1 { > .host = "192.168.0.10"; > } > > backend server2{ > .host = "192.168.0.10"; > } > > sub vcl_init { > new bar = directors.round_robin(); > bar.add_backend(server1, server2); > } > > -- > > Error message: > > Missing errorhandling code in parse_new(), vcc_action.c line 193: > Condition((sy2) != 0) not true. > Running VCC-compiler failed, signal 6 > > VCL compilation failed > > }}} New description: The VCL compiler seems to bail when confronted with the following VCL (missing import statement is the most obvious error): {{{ vcl 4.0; backend server1 { .host = "192.168.0.10"; } backend server2{ .host = "192.168.0.10"; } sub vcl_init { new bar = directors.round_robin(); bar.add_backend(server1, server2); } -- Error message: Missing errorhandling code in parse_new(), vcc_action.c line 193: Condition((sy2) != 0) not true. Running VCC-compiler failed, signal 6 VCL compilation failed }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 11:06:35 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 11:06:35 -0000 Subject: [Varnish] #1437: varnish ESI randomly fetches whole page from backend even if present in cache In-Reply-To: <048.1429e7959f2b4a0f00d4fd44b16b8edb@varnish-cache.org> References: <048.1429e7959f2b4a0f00d4fd44b16b8edb@varnish-cache.org> Message-ID: <063.9ef7abe725e38a4f55562f1ce8996ff8@varnish-cache.org> #1437: varnish ESI randomly fetches whole page from backend even if present in cache ------------------------+------------------------- Reporter: charanjeet | Owner: Type: defect | Status: closed Priority: highest | Milestone: Component: build | Version: unknown Severity: normal | Resolution: worksforme Keywords: | ------------------------+------------------------- Changes (by lkarsten): * status: new => closed * resolution: => worksforme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 11:13:29 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 11:13:29 -0000 Subject: [Varnish] #1431: varnish 3.0.3 stops working - CLI communication error (hdr) In-Reply-To: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> References: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> Message-ID: <062.183552a857f1b74715b714e2c866f528@varnish-cache.org> #1431: varnish 3.0.3 stops working - CLI communication error (hdr) -----------------------+----------------------- Reporter: cherouvim | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: blocker | Resolution: Keywords: | -----------------------+----------------------- Comment (by lkarsten): I suggest you increase the cli_timeout parameter to 60 seconds, and see if this solves the issue. 60s is the default used in master/4.0. Closing the ticket for now, reopen if increasing doesn't work. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 11:13:41 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 11:13:41 -0000 Subject: [Varnish] #1431: varnish 3.0.3 stops working - CLI communication error (hdr) In-Reply-To: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> References: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> Message-ID: <062.d0efb5d0e898afa727ddee1daca7e243@varnish-cache.org> #1431: varnish 3.0.3 stops working - CLI communication error (hdr) -----------------------+----------------------- Reporter: cherouvim | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: blocker | Resolution: fixed Keywords: | -----------------------+----------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 11:16:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 11:16:03 -0000 Subject: [Varnish] #1427: CLI timeout with no apparent load on the machine In-Reply-To: <043.ca02860bd747676f18c13cd8c162e36e@varnish-cache.org> References: <043.ca02860bd747676f18c13cd8c162e36e@varnish-cache.org> Message-ID: <058.72a69e5fc1f63fced4858858599eb756@varnish-cache.org> #1427: CLI timeout with no apparent load on the machine ----------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP2 Component: varnishd | Version: unknown Severity: normal | Resolution: fixed Keywords: | ----------------------+------------------------------ Changes (by martin): * status: new => closed * resolution: => fixed Comment: cli_timeout has been increased to 60 seconds in 8f26bf57a3130ecf3efa75ad3a422500619ed8aa. This should resolve this issue, so closing the ticket. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 11:17:26 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 11:17:26 -0000 Subject: [Varnish] #1431: varnish 3.0.3 stops working - CLI communication error (hdr) In-Reply-To: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> References: <047.4e8c19a54a81db6dfa1f2cc6c0c3cc95@varnish-cache.org> Message-ID: <062.0c6c23026631292a68de18faff79b12d@varnish-cache.org> #1431: varnish 3.0.3 stops working - CLI communication error (hdr) -----------------------+----------------------- Reporter: cherouvim | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: blocker | Resolution: fixed Keywords: | -----------------------+----------------------- Comment (by cherouvim): OK, will do so. But why can't varnish recover from this situation? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 12:49:57 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 12:49:57 -0000 Subject: [Varnish] #1434: std.duration does not handle ms units In-Reply-To: <043.e5effd09d5223eb03876e96194ec6687@varnish-cache.org> References: <043.e5effd09d5223eb03876e96194ec6687@varnish-cache.org> Message-ID: <058.d88c494ae2e16652d905f4a35acb2e9a@varnish-cache.org> #1434: std.duration does not handle ms units --------------------+--------------------- Reporter: fgsch | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: vmod | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 12:50:16 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 12:50:16 -0000 Subject: [Varnish] #1434: std.duration does not handle ms units In-Reply-To: <043.e5effd09d5223eb03876e96194ec6687@varnish-cache.org> References: <043.e5effd09d5223eb03876e96194ec6687@varnish-cache.org> Message-ID: <058.419177798d060ffea9c4eef50483c355@varnish-cache.org> #1434: std.duration does not handle ms units --------------------+--------------------- Reporter: fgsch | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: vmod | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: In [d35ed6e2617203a0ce9d5cd27bb2286720efab73]: {{{ #!CommitTicketReference repository="" revision="d35ed6e2617203a0ce9d5cd27bb2286720efab73" Add 'ms' conversion qualifier to std.duration Add 'ms' conversion qualifier to std.duration, and update documentation and test case. Fixes: #1434 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Feb 24 21:42:48 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 24 Feb 2014 21:42:48 -0000 Subject: [Varnish] #1438: Bad syntax in 4.0 director docs Message-ID: <044.e4da17937191ec802c85995ecb6cb363@varnish-cache.org> #1438: Bad syntax in 4.0 director docs -----------------------------+--------------------------- Reporter: MPilar | Type: documentation Status: new | Priority: lowest Milestone: Varnish 4.0-TP2 | Component: documentation Version: trunk | Severity: trivial Keywords: | -----------------------------+--------------------------- Hello, In /doc/sphinx/users-guide/vcl-backends.rst line 142: {{{ req.backend = bar.backend; }}} shows as a syntax error when compiling the VCL, I believe it should be: {{{ req.backend = bar.backend(); }}} Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 25 11:41:11 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 25 Feb 2014 11:41:11 -0000 Subject: [Varnish] #1438: Bad syntax in 4.0 director docs In-Reply-To: <044.e4da17937191ec802c85995ecb6cb363@varnish-cache.org> References: <044.e4da17937191ec802c85995ecb6cb363@varnish-cache.org> Message-ID: <059.dd2966151b1f6fd1d41f7cf535c3c313@varnish-cache.org> #1438: Bad syntax in 4.0 director docs ---------------------------+-------------------------------------------- Reporter: MPilar | Owner: Lasse Karstensen Type: documentation | Status: closed Priority: lowest | Milestone: Varnish 4.0-TP2 Component: documentation | Version: trunk Severity: trivial | Resolution: fixed Keywords: | ---------------------------+-------------------------------------------- Changes (by Lasse Karstensen ): * status: new => closed * owner: => Lasse Karstensen * resolution: => fixed Comment: In [fd2f5191b21721ed3c6a6f7e56f0605333bd9c5c]: {{{ #!CommitTicketReference repository="" revision="fd2f5191b21721ed3c6a6f7e56f0605333bd9c5c" Fix faulty example. Reformat tabs/spaces Fixes #1438. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Feb 25 15:40:39 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 25 Feb 2014 15:40:39 -0000 Subject: [Varnish] #1439: Backend name cannot start with if Message-ID: <045.791ad4e2323eca6b387dc78c2cbb9eb6@varnish-cache.org> #1439: Backend name cannot start with if ---------------------+---------------------- Reporter: sambash | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.5 | Severity: normal Keywords: | ---------------------+---------------------- Including the attached vcl, I get the following error: {{{ Message from VCC-compiler: Expected ID got 'if' (program line 331), at ('web.vcl' Line 15 Pos 9) backend if4b5bab7 { --------##--------- Running VCC-compiler failed, exit 1 VCL compilation failed Command failed with error code 106 varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082 vcl.load failed }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Feb 26 10:30:37 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 26 Feb 2014 10:30:37 -0000 Subject: [Varnish] #1440: e00019.vtc occasionally trips an assert Message-ID: <044.1cf9d478ad322048a9826e01a403f898@varnish-cache.org> #1440: e00019.vtc occasionally trips an assert ----------------------+------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Command to reproduce: {{{ $ ./varnishtest -n100 -j8 -i tests/e00019.vtc }}} Backtrace: {{{ *** v1 1.6 debug| Child (25308) died signal=6\n *** v1 1.6 debug| Child (25308) Panic message: Assert error in V1D_Deliver(), cache/cache_http1_deliver.c line 297:\n *** v1 1.6 debug| Condition((req->obj->objcore->busyobj) == 0) not true.\n *** v1 1.6 debug| thread = (cache-worker)\n *** v1 1.6 debug| ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll\n *** v1 1.6 debug| Backtrace:\n *** v1 1.6 debug| 0x445969: pan_backtrace+0x19\n *** v1 1.6 debug| 0x44585d: pan_ic+0x23d\n *** v1 1.6 debug| 0x44f071: V1D_Deliver+0x801\n *** v1 1.6 debug| 0x44da84: cnt_deliver+0x944\n *** v1 1.6 debug| 0x44a07d: CNT_Request+0x64d\n *** v1 1.6 debug| 0x43c8b6: HTTP1_Session+0x536\n *** v1 1.6 debug| 0x452425: ses_req_pool_task+0x1c5\n *** v1 1.6 debug| 0x451f2c: ses_sess_pool_task+0x20c\n *** v1 1.6 debug| 0x451611: SES_pool_accept_task+0x251\n *** v1 1.6 debug| 0x448416: Pool_Work_Thread+0x576\n *** v1 1.6 debug| req = 0x1d7b8e0 {\n *** v1 1.6 debug| sp = 0x7feb7c00b9f0, vxid = 1073742825, step = R_STP_DELIVER,\n *** v1 1.6 debug| req_body = R_BODY_NONE,\n *** v1 1.6 debug| err_code = 200, err_reason = (null),\n *** v1 1.6 debug| restarts = 0, esi_level = 0\n *** v1 1.6 debug| sp = 0x7feb7c00b9f0 {\n *** v1 1.6 debug| fd = 11, vxid = 1000,\n *** v1 1.6 debug| client = 127.0.0.1 36626,\n *** v1 1.6 debug| step = S_STP_WORKING,\n *** v1 1.6 debug| },\n *** v1 1.6 debug| worker = 0x7feb8071fc60 {\n *** v1 1.6 debug| ws = 0x7feb8071fe60 {\n *** v1 1.6 debug| id = "wrk",\n *** v1 1.6 debug| {s,f,r,e} = {0x7feb8071f420,+80,+2048,+2048},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| VCL::method = 0x0,\n *** v1 1.6 debug| VCL::return = deliver,\n *** v1 1.6 debug| },\n *** v1 1.6 debug| ws = 0x1d7ba60 {\n *** v1 1.6 debug| id = "req",\n *** v1 1.6 debug| {s,f,r,e} = {0x1d7d8b0,+160,(nil),+57392},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[req] = {\n *** v1 1.6 debug| ws = 0x1d7ba60[req]\n *** v1 1.6 debug| "GET",\n *** v1 1.6 debug| "bar",\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "X-Forwarded-For: 127.0.0.1",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[resp] = {\n *** v1 1.6 debug| ws = 0x1d7ba60[req]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| "Date: Wed, 26 Feb 2014 10:27:16 GMT",\n *** v1 1.6 debug| "X-Varnish: 1001",\n *** v1 1.6 debug| "Age: 0",\n *** v1 1.6 debug| "Via: 1.1 varnish",\n *** v1 1.6 debug| "Transfer-Encoding: chunked",\n *** v1 1.6 debug| "Connection: keep-alive",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| vcl = {\n *** v1 1.6 debug| srcname = {\n *** v1 1.6 debug| "input",\n *** v1 1.6 debug| "Default",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| busyobj = 0x1d5b880 {\n *** v1 1.6 debug| ws = 0x1d5b948 {\n *** v1 1.6 debug| id = "bo",\n *** v1 1.6 debug| {s,f,r,e} = {0x1d5d840,+464,(nil),+57408},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| is_do_esi\n *** v1 1.6 debug| is_is_gunzip\n *** v1 1.6 debug| bodystatus = 2 (chunked),\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[bereq] = {\n *** v1 1.6 debug| ws = 0x1d5b948[bo]\n *** v1 1.6 debug| "GET",\n *** v1 1.6 debug| "bar",\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "X-Forwarded-For: 127.0.0.1",\n *** v1 1.6 debug| "Accept-Encoding: gzip",\n *** v1 1.6 debug| "X-Varnish: 1002",\n *** v1 1.6 debug| "Host: 127.0.0.1",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[beresp] = {\n *** v1 1.6 debug| ws = 0x1d5b948[bo]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| "Transfer-encoding: chunked",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| ws = 0x1d5bac8 {\n *** v1 1.6 debug| id = "obj",\n *** v1 1.6 debug| {s,f,r,e} = {0x1d8bce0,+32,(nil),+32},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| obj (FETCH) = 0x1d8bb90 {\n *** v1 1.6 debug| vxid = 2147484650,\n *** v1 1.6 debug| http[obj] = {\n *** v1 1.6 debug| ws = 0x1d5bac8[obj]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| len = 131837,\n *** v1 1.6 debug| store = {\n *** v1 1.6 debug| 131072 {\n *** v1 1.6 debug| 3c 31 3e 3c 2f 65 73 69 3a 63 6f 6d 6d 65 6e 74 |<1><1><2><2><|\n *** v1 1.6 debug| [131008 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| 765 {\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| [701 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| }\n *** v1 1.6 debug| obj (REQ) = 0x1d8bb90 {\n *** v1 1.6 debug| vxid = 2147484650,\n *** v1 1.6 debug| http[obj] = {\n *** v1 1.6 debug| ws = 0x1d5bac8[obj]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| len = 131837,\n *** v1 1.6 debug| store = {\n *** v1 1.6 debug| 131072 {\n *** v1 1.6 debug| 3c 31 3e 3c 2f 65 73 69 3a 63 6f 6d 6d 65 6e 74 |<1><1><2><2><|\n *** v1 1.6 debug| [131008 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| 765 {\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| [701 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| \n *** v1 1.6 debug| \n }}} Full test log: {{{ **** top 0.0 macro def varnishd=varnishd **** top 0.0 macro def varnishadm=varnishadm **** top 0.0 macro def varnishstat=varnishstat **** top 0.0 macro def varnishhist=varnishhist **** top 0.0 macro def varnishlog=varnishlog **** top 0.0 macro def varnishncsa=varnishncsa **** top 0.0 macro def vmod_std=std from "/home/martin/varnish/git /varnish-cache/lib/libvmod_std/.libs/libvmod_std.so" **** top 0.0 macro def vmod_debug=debug from "/home/martin/varnish/git /varnish-cache/lib/libvmod_debug/.libs/libvmod_debug.so" **** top 0.0 macro def vmod_directors=directors from "/home/martin/varnish/git/varnish- cache/lib/libvmod_directors/.libs/libvmod_directors.so" **** top 0.0 macro def pwd=/home/martin/varnish/git/varnish- cache/bin/varnishtest **** top 0.0 macro def topbuild=/home/martin/varnish/git/varnish-cache **** top 0.0 macro def bad_ip=192.0.2.255 **** top 0.0 macro def tmpdir=/tmp/vtc.24902.1ade685f * top 0.0 TEST tests/e00019.vtc starting *** top 0.0 varnishtest * top 0.0 TEST Push corners in new ESI parser *** top 0.0 server ** s1 0.0 Starting server **** s1 0.0 macro def s1_addr=127.0.0.1 **** s1 0.0 macro def s1_port=48509 **** s1 0.0 macro def s1_sock=127.0.0.1 48509 * s1 0.0 Listen on 127.0.0.1 48509 *** top 0.0 varnish ** s1 0.0 Started on 127.0.0.1 48509 ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && ${varnishd} -d -d -n /tmp/vtc.24902.1ade685f/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -a '127.0.0.1:0' -M '127.0.0.1 60677' -P /tmp/vtc.24902.1ade685f/v1/varnishd.pid *** v1 0.0 CMD: cd /home/martin/varnish/git/varnish- cache/bin/varnishtest && varnishd -d -d -n /tmp/vtc.24902.1ade685f/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -a '127.0.0.1:0' -M '127.0.0.1 60677' -P /tmp/vtc.24902.1ade685f/v1/varnishd.pid *** v1 0.0 PID: 24943 *** v1 0.0 debug| Platform: Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| 200 276 \n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Varnish Cache CLI 1.0\n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| varnish-4.0.0-tp2 revision 3f79aa1\n *** v1 0.0 debug| \n *** v1 0.0 debug| Type 'help' for command list.\n *** v1 0.0 debug| Type 'quit' to close CLI session.\n *** v1 0.0 debug| Type 'start' to launch worker process.\n *** v1 0.0 debug| \n **** v1 0.1 CLIPOLL 1 0x1 0x0 *** v1 0.1 CLI connection fd = 9 *** v1 0.1 CLI RX 107 **** v1 0.1 CLI RX| xboxfbvjiipmfvqsjxftgytmhkmsffgc\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Authentication required.\n **** v1 0.1 CLI TX| auth 9fdf0e9d724a784a17d8bd203361ae311ddbb0a86b8a2c05963812aa8cbb64fc\n *** v1 0.1 CLI RX 200 **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Varnish Cache CLI 1.0\n **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit\n **** v1 0.1 CLI RX| varnish-4.0.0-tp2 revision 3f79aa1\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Type 'help' for command list.\n **** v1 0.1 CLI RX| Type 'quit' to close CLI session.\n **** v1 0.1 CLI RX| Type 'start' to launch worker process.\n **** v1 0.1 CLI TX| vcl.inline vcl1 << %XJEIFLH|)Xspa8P\n **** v1 0.1 CLI TX| vcl 4.0;\n **** v1 0.1 CLI TX| backend s1 { .host = "127.0.0.1"; .port = "48509"; }\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \tsub vcl_backend_response {\n **** v1 0.1 CLI TX| \t\tif (bereq.url == "bar") {\n **** v1 0.1 CLI TX| \t\t\tset beresp.do_esi = true;\n **** v1 0.1 CLI TX| \t\t}\n **** v1 0.1 CLI TX| \t}\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| Message from VCC-compiler:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| Message from C-compiler:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| Message from dlopen:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| \n **** v1 0.2 CLI RX| VCL compiled. **** v1 0.2 CLI TX| vcl.use vcl1 *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| VCL 'vcl1' now active ** v1 0.2 Start **** v1 0.2 CLI TX| start *** v1 0.2 debug| child (25308) Started\n *** v1 0.3 CLI RX 200 *** v1 0.3 wait-running **** v1 0.3 CLI TX| status *** v1 0.3 debug| Child (25308) said Not running as root, no priv- sep\n *** v1 0.3 debug| Child (25308) said Child starts\n *** v1 0.3 CLI RX 200 **** v1 0.3 CLI RX| Child in state running **** v1 0.3 CLI TX| debug.xid 999 *** v1 0.3 CLI RX 200 **** v1 0.3 CLI RX| XID is 999 **** v1 0.3 CLI TX| debug.listen_address **** v1 0.3 vsl| 0 CLI - Rd debug.xid 999 **** v1 0.3 vsl| 0 CLI - Wr 200 10 XID is 999 *** v1 0.4 CLI RX 200 **** v1 0.4 CLI RX| 127.0.0.1 46370\n ** v1 0.4 Listen on 127.0.0.1 46370 **** v1 0.4 macro def v1_addr=127.0.0.1 **** v1 0.4 macro def v1_port=46370 **** v1 0.4 macro def v1_sock=127.0.0.1 46370 *** top 0.4 varnish **** v1 0.4 CLI TX| param.set debug +esi_chop **** v1 0.4 vsl| 0 CLI - Rd debug.listen_address **** v1 0.4 vsl| 0 CLI - Wr 200 16 127.0.0.1 46370 *** v1 0.4 CLI RX 200 ** v1 0.4 CLI 200 *** top 0.4 varnish **** v1 0.4 CLI TX| param.set debug +syncvsl *** v1 0.4 CLI RX 200 ** v1 0.4 CLI 200 *** top 0.4 client ** c1 0.4 Starting client ** c1 0.4 Waiting for client *** c1 0.4 Connect to 127.0.0.1 46370 *** c1 0.4 connected fd 10 from 127.0.0.1 36626 to 127.0.0.1 46370 *** c1 0.4 txreq **** c1 0.4 txreq| GET bar HTTP/1.1\r\n **** c1 0.4 txreq| \r\n *** s1 0.4 accepted fd 4 *** s1 0.4 rxreq *** c1 0.4 rxresp **** s1 0.4 rxhdr| GET bar HTTP/1.1\r\n **** s1 0.4 rxhdr| X-Forwarded-For: 127.0.0.1\r\n **** s1 0.4 rxhdr| Accept-Encoding: gzip\r\n **** s1 0.4 rxhdr| X-Varnish: 1002\r\n **** s1 0.4 rxhdr| Host: 127.0.0.1\r\n **** s1 0.4 rxhdr| \r\n **** s1 0.4 http[ 0] | GET **** s1 0.4 http[ 1] | bar **** s1 0.4 http[ 2] | HTTP/1.1 **** s1 0.4 http[ 3] | X-Forwarded-For: 127.0.0.1 **** s1 0.4 http[ 4] | Accept-Encoding: gzip **** s1 0.4 http[ 5] | X-Varnish: 1002 **** s1 0.4 http[ 6] | Host: 127.0.0.1 **** s1 0.4 bodylen = 0 *** s1 0.4 txresp **** s1 0.4 txresp| HTTP/1.1 200 Ok\r\n **** s1 0.4 txresp| Transfer-encoding: chunked\r\n **** s1 0.4 txresp| \r\n *** s1 0.4 chunked **** s1 0.4 chunked| 18\r\n **** s1 0.4 chunked| <1><1>\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 27\r\n **** s1 0.4 chunked| <2><2>\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 29\r\n **** s1 0.4 chunked| <3><3>\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 27\r\n **** s1 0.4 chunked| <4><4>\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 10\r\n **** s1 0.4 chunked|

\r\n *** s1 0.4 chunkedlen **** s1 0.4 chunked| 100\r\n **** s1 0.4 chunked| 0123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 12\r\n **** s1 0.4 chunked|

\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 10\r\n **** s1 0.4 chunked|

\r\n *** s1 0.4 chunkedlen **** s1 0.5 chunked| 10000\r\n **** s1 0.5 chunked| 01234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701... *** s1 0.5 chunked **** s1 0.5 chunked| 12\r\n **** s1 0.5 chunked|

\r\n *** s1 0.5 chunked **** s1 0.5 chunked| e\r\n **** s1 0.5 chunked| \r\n *** s1 0.5 chunkedlen **** s1 0.5 chunked| 100\r\n **** s1 0.5 chunked| 0123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567\r\n *** s1 0.5 chunked **** s1 0.5 chunked| e\r\n **** s1 0.5 chunked| \r\n *** s1 0.5 chunkedlen **** s1 0.5 chunked| 10000\r\n **** s1 0.5 chunked| 01234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701... *** s1 0.5 chunked **** s1 0.5 chunked| e\r\n **** s1 0.5 chunked| \r\n *** s1 0.5 chunkedlen **** s1 0.5 chunked| 0\r\n **** s1 0.5 chunked| \r\n *** s1 0.5 rxreq **** v1 0.5 vsl| 1000 Begin c sess 0 HTTP/1 **** v1 0.5 vsl| 1000 SessOpen c 127.0.0.1 36626 127.0.0.1:0 127.0.0.1 46370 1393410436.813103 11 **** v1 0.5 vsl| 1001 Begin c req 1000 rxreq **** v1 0.5 vsl| 1000 Link c req 1001 rxreq **** v1 0.5 vsl| 1001 ReqStart c 127.0.0.1 36626 **** v1 0.5 vsl| 1001 ReqMethod c GET **** v1 0.5 vsl| 1001 ReqURL c bar **** v1 0.5 vsl| 1001 ReqProtocol c HTTP/1.1 **** v1 0.5 vsl| 1001 VCL_call c RECV **** v1 0.5 vsl| 1001 ReqHeader c X-Forwarded-For: 127.0.0.1 **** v1 0.5 vsl| 1001 VCL_return c hash **** v1 0.5 vsl| 1001 VCL_call c HASH **** v1 0.5 vsl| 1001 VCL_return c lookup **** v1 0.5 vsl| 1001 Debug c XXXX MISS **** v1 0.5 vsl| 1001 VCL_call c MISS **** v1 0.5 vsl| 1001 VCL_return c fetch **** v1 0.5 vsl| 1002 Begin b bereq 1001 fetch **** v1 0.5 vsl| 1001 Link c bereq 1002 fetch **** v1 0.5 vsl| 1002 BereqMethod b GET **** v1 0.5 vsl| 1002 BereqURL b bar **** v1 0.5 vsl| 1002 BereqProtocol b HTTP/1.1 **** v1 0.5 vsl| 1002 BereqHeader b X-Forwarded-For: 127.0.0.1 **** v1 0.5 vsl| 1002 BereqHeader b Accept-Encoding: gzip **** v1 0.5 vsl| 1002 VCL_call b BACKEND_FETCH **** v1 0.5 vsl| 1002 VCL_return b fetch **** v1 0.5 vsl| 1002 BereqHeader b X-Varnish: 1002 **** v1 0.5 vsl| 1002 Debug b XXX BOS: 0 -> 1 **** v1 0.5 vsl| 1002 BackendOpen b 15 s1(127.0.0.1,,48509) 127.0.0.1 55107 **** v1 0.5 vsl| 1002 Backend b 15 s1 s1(127.0.0.1,,48509) **** v1 0.5 vsl| 1002 BereqHeader b Host: 127.0.0.1 **** v1 0.5 vsl| 1002 BerespProtocol b HTTP/1.1 **** v1 0.5 vsl| 1002 BerespStatus b 200 **** v1 0.5 vsl| 1002 BerespResponse b Ok **** v1 0.5 vsl| 1002 BerespHeader b Transfer-encoding: chunked **** v1 0.5 vsl| 1002 TTL b RFC 20 -1 -1 1393410437 1393410437 0 0 0 **** v1 0.5 vsl| 1002 VCL_call b BACKEND_RESPONSE **** v1 0.5 vsl| 1002 VCL_return b deliver **** v1 0.5 vsl| 1002 Storage b malloc s0 **** v1 0.5 vsl| 1002 ObjProtocol b HTTP/1.1 **** v1 0.5 vsl| 1002 ObjStatus b 200 **** v1 0.5 vsl| 1002 ObjResponse b Ok **** v1 0.5 vsl| 1002 ESI_xmlerror b ERR at 14 ESI 1.0 illegal end-tag **** v1 0.5 vsl| 1002 ESI_xmlerror b ERR at 39 XML 1.0 '>' does not follow '/' in tag **** v1 0.5 vsl| 1002 ESI_xmlerror b ERR at 60 ESI 1.0 needs final '/' **** v1 0.5 vsl| 1002 ESI_xmlerror b WARN at 130 ESI 1.0 lacks final '/' **** v1 0.5 vsl| 1002 ESI_xmlerror b ERR at 139 ESI 1.0 element ---- c1 0.6 HTTP rx EOF (fd:10 read: Success) ---- s1 0.6 HTTP rx EOF (fd:4 read: Success) * top 0.6 RESETTING after tests/e00019.vtc ** s1 0.6 Waiting for server **** s1 0.6 macro undef s1_addr **** s1 0.6 macro undef s1_port **** s1 0.6 macro undef s1_sock **** v1 0.6 vsl| 1002 Fetch_Body b 2(chunked) **** v1 0.6 vsl| 1002 Length b 131837 **** v1 0.6 vsl| 1002 Debug b XXX BOS: 1 -> 3 **** v1 0.6 vsl| 0 ExpKill - EXP_Inbox p=0x1d8b980 e=0.000000000 f=0x1c10 **** v1 0.6 vsl| 1001 RespProtocol c HTTP/1.1 **** v1 0.6 vsl| 0 ExpKill - EXP_When p=0x1d8b980 e=1393410466.813253164 f=0x1c10 **** v1 0.6 vsl| 1001 RespStatus c 200 **** v1 0.6 vsl| 1001 RespResponse c Ok **** v1 0.6 vsl| 1001 RespHeader c Date: Wed, 26 Feb 2014 10:27:16 GMT **** v1 0.6 vsl| 1001 RespHeader c X-Varnish: 1001 **** v1 0.6 vsl| 1001 RespHeader c Age: 0 **** v1 0.6 vsl| 1001 RespHeader c Via: 1.1 varnish **** v1 0.6 vsl| 1001 VCL_call c DELIVER **** v1 0.6 vsl| 1001 VCL_return c deliver **** v1 0.6 vsl| 1001 Debug c RES_MODE 18 **** v1 0.6 vsl| 1001 RespHeader c Transfer-Encoding: chunked **** v1 0.6 vsl| 1001 RespHeader c Connection: keep-alive *** v1 1.6 debug| Child (25308) died signal=6\n *** v1 1.6 debug| Child (25308) Panic message: Assert error in V1D_Deliver(), cache/cache_http1_deliver.c line 297:\n *** v1 1.6 debug| Condition((req->obj->objcore->busyobj) == 0) not true.\n *** v1 1.6 debug| thread = (cache-worker)\n *** v1 1.6 debug| ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll\n *** v1 1.6 debug| Backtrace:\n *** v1 1.6 debug| 0x445969: pan_backtrace+0x19\n *** v1 1.6 debug| 0x44585d: pan_ic+0x23d\n *** v1 1.6 debug| 0x44f071: V1D_Deliver+0x801\n *** v1 1.6 debug| 0x44da84: cnt_deliver+0x944\n *** v1 1.6 debug| 0x44a07d: CNT_Request+0x64d\n *** v1 1.6 debug| 0x43c8b6: HTTP1_Session+0x536\n *** v1 1.6 debug| 0x452425: ses_req_pool_task+0x1c5\n *** v1 1.6 debug| 0x451f2c: ses_sess_pool_task+0x20c\n *** v1 1.6 debug| 0x451611: SES_pool_accept_task+0x251\n *** v1 1.6 debug| 0x448416: Pool_Work_Thread+0x576\n *** v1 1.6 debug| req = 0x1d7b8e0 {\n *** v1 1.6 debug| sp = 0x7feb7c00b9f0, vxid = 1073742825, step = R_STP_DELIVER,\n *** v1 1.6 debug| req_body = R_BODY_NONE,\n *** v1 1.6 debug| err_code = 200, err_reason = (null),\n *** v1 1.6 debug| restarts = 0, esi_level = 0\n *** v1 1.6 debug| sp = 0x7feb7c00b9f0 {\n *** v1 1.6 debug| fd = 11, vxid = 1000,\n *** v1 1.6 debug| client = 127.0.0.1 36626,\n *** v1 1.6 debug| step = S_STP_WORKING,\n *** v1 1.6 debug| },\n *** v1 1.6 debug| worker = 0x7feb8071fc60 {\n *** v1 1.6 debug| ws = 0x7feb8071fe60 {\n *** v1 1.6 debug| id = "wrk",\n *** v1 1.6 debug| {s,f,r,e} = {0x7feb8071f420,+80,+2048,+2048},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| VCL::method = 0x0,\n *** v1 1.6 debug| VCL::return = deliver,\n *** v1 1.6 debug| },\n *** v1 1.6 debug| ws = 0x1d7ba60 {\n *** v1 1.6 debug| id = "req",\n *** v1 1.6 debug| {s,f,r,e} = {0x1d7d8b0,+160,(nil),+57392},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[req] = {\n *** v1 1.6 debug| ws = 0x1d7ba60[req]\n *** v1 1.6 debug| "GET",\n *** v1 1.6 debug| "bar",\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "X-Forwarded-For: 127.0.0.1",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[resp] = {\n *** v1 1.6 debug| ws = 0x1d7ba60[req]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| "Date: Wed, 26 Feb 2014 10:27:16 GMT",\n *** v1 1.6 debug| "X-Varnish: 1001",\n *** v1 1.6 debug| "Age: 0",\n *** v1 1.6 debug| "Via: 1.1 varnish",\n *** v1 1.6 debug| "Transfer-Encoding: chunked",\n *** v1 1.6 debug| "Connection: keep-alive",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| vcl = {\n *** v1 1.6 debug| srcname = {\n *** v1 1.6 debug| "input",\n *** v1 1.6 debug| "Default",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| busyobj = 0x1d5b880 {\n *** v1 1.6 debug| ws = 0x1d5b948 {\n *** v1 1.6 debug| id = "bo",\n *** v1 1.6 debug| {s,f,r,e} = {0x1d5d840,+464,(nil),+57408},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| is_do_esi\n *** v1 1.6 debug| is_is_gunzip\n *** v1 1.6 debug| bodystatus = 2 (chunked),\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[bereq] = {\n *** v1 1.6 debug| ws = 0x1d5b948[bo]\n *** v1 1.6 debug| "GET",\n *** v1 1.6 debug| "bar",\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "X-Forwarded-For: 127.0.0.1",\n *** v1 1.6 debug| "Accept-Encoding: gzip",\n *** v1 1.6 debug| "X-Varnish: 1002",\n *** v1 1.6 debug| "Host: 127.0.0.1",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[beresp] = {\n *** v1 1.6 debug| ws = 0x1d5b948[bo]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| "Transfer-encoding: chunked",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| ws = 0x1d5bac8 {\n *** v1 1.6 debug| id = "obj",\n *** v1 1.6 debug| {s,f,r,e} = {0x1d8bce0,+32,(nil),+32},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| obj (FETCH) = 0x1d8bb90 {\n *** v1 1.6 debug| vxid = 2147484650,\n *** v1 1.6 debug| http[obj] = {\n *** v1 1.6 debug| ws = 0x1d5bac8[obj]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| len = 131837,\n *** v1 1.6 debug| store = {\n *** v1 1.6 debug| 131072 {\n *** v1 1.6 debug| 3c 31 3e 3c 2f 65 73 69 3a 63 6f 6d 6d 65 6e 74 |<1><1><2><2><|\n *** v1 1.6 debug| [131008 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| 765 {\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| [701 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| }\n *** v1 1.6 debug| obj (REQ) = 0x1d8bb90 {\n *** v1 1.6 debug| vxid = 2147484650,\n *** v1 1.6 debug| http[obj] = {\n *** v1 1.6 debug| ws = 0x1d5bac8[obj]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| len = 131837,\n *** v1 1.6 debug| store = {\n *** v1 1.6 debug| 131072 {\n *** v1 1.6 debug| 3c 31 3e 3c 2f 65 73 69 3a 63 6f 6d 6d 65 6e 74 |<1><1><2><2><|\n *** v1 1.6 debug| [131008 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| 765 {\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| [701 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| \n *** v1 1.6 debug| \n ** v1 1.6 Wait *** v1 1.6 debug| Child cleanup complete\n ** v1 1.6 R 24943 Status: 0000 (u 0.088005 s 0.176011) * top 1.6 TEST tests/e00019.vtc FAILED }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 27 10:03:03 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Feb 2014 10:03:03 -0000 Subject: [Varnish] #1440: e00019.vtc occasionally trips an assert In-Reply-To: <044.1cf9d478ad322048a9826e01a403f898@varnish-cache.org> References: <044.1cf9d478ad322048a9826e01a403f898@varnish-cache.org> Message-ID: <059.e920270c7c5cb8c471feeee9bbf38ab9@varnish-cache.org> #1440: e00019.vtc occasionally trips an assert ----------------------+---------------------------------------- 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 ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [a95525aff978039148712306134ad60d9b9c0b67]: {{{ #!CommitTicketReference repository="" revision="a95525aff978039148712306134ad60d9b9c0b67" Remove an almost correct assert. The real condition is that either there is no busyobj or it is in state BOS_FINISHED, being rapidly dismantled. The locking of testing that would be to complex and expensive so we eliminate the assert instead, and strengthen another busyobj related check a little bit in compensation. Fixes #1440 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 27 12:00:21 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Feb 2014 12:00:21 -0000 Subject: [Varnish] #1440: e00019.vtc occasionally trips an assert In-Reply-To: <044.1cf9d478ad322048a9826e01a403f898@varnish-cache.org> References: <044.1cf9d478ad322048a9826e01a403f898@varnish-cache.org> Message-ID: <059.fa0877c6ac07bc6c9a862c790a0b6588@varnish-cache.org> #1440: e00019.vtc occasionally trips an assert ----------------------+---------------------------------------- Reporter: martin | Owner: Poul-Henning Kamp Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------------- Changes (by lkarsten): * status: closed => reopened * resolution: fixed => Comment: This still fails intermittently on latest master: 42cec19d525f56297626831782643d776866e87a I need to run with at least -j6 on my 4hwthreads laptop to reproduce it. This is probably just a coincidence, though. {{{ lkarsten at immer:~/work/varnish-cache/bin/varnishtest$ ./varnishtest -j 6 -n 20 -i tests/e00019.vtc # top TEST tests/e00019.vtc passed (1.741) # top TEST tests/e00019.vtc passed (1.755) # top TEST tests/e00019.vtc passed (1.732) # top TEST tests/e00019.vtc passed (1.714) # top TEST tests/e00019.vtc passed (1.900) # top TEST tests/e00019.vtc passed (1.881) # top TEST tests/e00019.vtc passed (1.721) # top TEST tests/e00019.vtc passed (1.731) # top TEST tests/e00019.vtc passed (1.680) # top TEST tests/e00019.vtc passed (1.750) # top TEST tests/e00019.vtc passed (1.727) # top TEST tests/e00019.vtc passed (1.770) # top TEST tests/e00019.vtc passed (1.677) # top TEST tests/e00019.vtc passed (1.657) **** top 0.0 macro def varnishd=varnishd **** top 0.0 macro def varnishadm=varnishadm **** top 0.0 macro def varnishstat=varnishstat **** top 0.0 macro def varnishhist=varnishhist **** top 0.0 macro def varnishlog=varnishlog **** top 0.0 macro def varnishncsa=varnishncsa **** top 0.0 macro def vmod_std=std from "/home/lkarsten/work/varnish- cache/lib/libvmod_std/.libs/libvmod_std.so" **** top 0.0 macro def vmod_debug=debug from "/home/lkarsten/work /varnish-cache/lib/libvmod_debug/.libs/libvmod_debug.so" **** top 0.0 macro def vmod_directors=directors from "/home/lkarsten/work/varnish- cache/lib/libvmod_directors/.libs/libvmod_directors.so" **** top 0.0 macro def pwd=/home/lkarsten/work/varnish- cache/bin/varnishtest **** top 0.0 macro def topbuild=/home/lkarsten/work/varnish-cache **** top 0.0 macro def bad_ip=192.0.2.255 **** top 0.0 macro def tmpdir=/tmp/vtc.1829.56860393 * top 0.0 TEST tests/e00019.vtc starting *** top 0.0 varnishtest * top 0.0 TEST Push corners in new ESI parser *** top 0.0 server ** s1 0.0 Starting server **** s1 0.0 macro def s1_addr=127.0.0.1 **** s1 0.0 macro def s1_port=51043 **** s1 0.0 macro def s1_sock=127.0.0.1 51043 * s1 0.0 Listen on 127.0.0.1 51043 *** top 0.0 varnish ** s1 0.0 Started on 127.0.0.1 51043 ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && ${varnishd} -d -d -n /tmp/vtc.1829.56860393/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -a '127.0.0.1:0' -M '127.0.0.1 43647' -P /tmp/vtc.1829.56860393/v1/varnishd.pid *** v1 0.0 CMD: cd /home/lkarsten/work/varnish-cache/bin/varnishtest && varnishd -d -d -n /tmp/vtc.1829.56860393/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -a '127.0.0.1:0' -M '127.0.0.1 43647' -P /tmp/vtc.1829.56860393/v1/varnishd.pid *** v1 0.0 PID: 5574 *** v1 0.0 debug| Platform: Linux,3.12-1-amd64,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| 200 275 \n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Varnish Cache CLI 1.0\n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Linux,3.12-1-amd64,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| varnish-4.0.0-tp2 revision d8f74bc\n *** v1 0.0 debug| \n *** v1 0.0 debug| Type 'help' for command list.\n *** v1 0.0 debug| Type 'quit' to close CLI session.\n *** v1 0.0 debug| Type 'start' to launch worker process.\n *** v1 0.0 debug| \n **** v1 0.1 CLIPOLL 1 0x1 0x0 *** v1 0.1 CLI connection fd = 9 *** v1 0.1 CLI RX 107 **** v1 0.1 CLI RX| wwpsvtsdvyywiqucwmeyuzayftiqyfwu\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Authentication required.\n **** v1 0.1 CLI TX| auth d862871a96c9238ec6cc57bb7bd4dbe8b633adb032b2e585639496c23cf3f374\n *** v1 0.1 CLI RX 200 **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Varnish Cache CLI 1.0\n **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Linux,3.12-1-amd64,x86_64,-smalloc,-smalloc,-hcritbit\n **** v1 0.1 CLI RX| varnish-4.0.0-tp2 revision d8f74bc\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Type 'help' for command list.\n **** v1 0.1 CLI RX| Type 'quit' to close CLI session.\n **** v1 0.1 CLI RX| Type 'start' to launch worker process.\n **** v1 0.1 CLI TX| vcl.inline vcl1 << %XJEIFLH|)Xspa8P\n **** v1 0.1 CLI TX| vcl 4.0;\n **** v1 0.1 CLI TX| backend s1 { .host = "127.0.0.1"; .port = "51043"; }\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \tsub vcl_backend_response {\n **** v1 0.1 CLI TX| \t\tif (bereq.url == "bar") {\n **** v1 0.1 CLI TX| \t\t\tset beresp.do_esi = true;\n **** v1 0.1 CLI TX| \t\t}\n **** v1 0.1 CLI TX| \t}\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| Message from VCC-compiler:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| Message from C-compiler:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| Message from dlopen:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| \n **** v1 0.2 CLI RX| VCL compiled. **** v1 0.2 CLI TX| vcl.use vcl1 *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| VCL 'vcl1' now active ** v1 0.2 Start **** v1 0.2 CLI TX| start *** v1 0.3 debug| child (6126) Started\n *** v1 0.3 CLI RX 200 *** v1 0.3 wait-running **** v1 0.3 CLI TX| status *** v1 0.3 debug| Child (6126) said Not running as root, no priv-sep\n *** v1 0.3 debug| Child (6126) said Child starts\n *** v1 0.3 CLI RX 200 **** v1 0.3 CLI RX| Child in state running **** v1 0.3 CLI TX| debug.xid 999 *** v1 0.3 CLI RX 200 **** v1 0.3 CLI RX| XID is 999 **** v1 0.3 CLI TX| debug.listen_address **** v1 0.4 vsl| 0 CLI - Rd debug.xid 999 **** v1 0.4 vsl| 0 CLI - Wr 200 10 XID is 999 *** v1 0.4 CLI RX 200 **** v1 0.4 CLI RX| 127.0.0.1 55617\n ** v1 0.4 Listen on 127.0.0.1 55617 **** v1 0.4 macro def v1_addr=127.0.0.1 **** v1 0.4 macro def v1_port=55617 **** v1 0.4 macro def v1_sock=127.0.0.1 55617 *** top 0.4 varnish **** v1 0.4 CLI TX| param.set debug +esi_chop **** v1 0.4 vsl| 0 CLI - Rd debug.listen_address **** v1 0.4 vsl| 0 CLI - Wr 200 16 127.0.0.1 55617 *** v1 0.4 CLI RX 200 ** v1 0.4 CLI 200 *** top 0.4 varnish **** v1 0.4 CLI TX| param.set debug +syncvsl *** v1 0.5 CLI RX 200 ** v1 0.5 CLI 200 *** top 0.5 client ** c1 0.5 Starting client ** c1 0.5 Waiting for client *** c1 0.5 Connect to 127.0.0.1 55617 *** c1 0.5 connected fd 10 from 127.0.0.1 36946 to 127.0.0.1 55617 *** c1 0.5 txreq **** c1 0.5 txreq| GET bar HTTP/1.1\r\n **** c1 0.5 txreq| \r\n *** c1 0.5 rxresp *** s1 0.5 accepted fd 4 *** s1 0.5 rxreq **** s1 0.5 rxhdr| GET bar HTTP/1.1\r\n **** s1 0.5 rxhdr| X-Forwarded-For: 127.0.0.1\r\n **** s1 0.5 rxhdr| Accept-Encoding: gzip\r\n **** s1 0.5 rxhdr| X-Varnish: 1002\r\n **** s1 0.5 rxhdr| Host: 127.0.0.1\r\n **** s1 0.5 rxhdr| \r\n **** s1 0.5 http[ 0] | GET **** s1 0.5 http[ 1] | bar **** s1 0.5 http[ 2] | HTTP/1.1 **** s1 0.5 http[ 3] | X-Forwarded-For: 127.0.0.1 **** s1 0.5 http[ 4] | Accept-Encoding: gzip **** s1 0.5 http[ 5] | X-Varnish: 1002 **** s1 0.5 http[ 6] | Host: 127.0.0.1 **** s1 0.5 bodylen = 0 *** s1 0.5 txresp **** s1 0.5 txresp| HTTP/1.1 200 Ok\r\n **** s1 0.5 txresp| Transfer-encoding: chunked\r\n **** s1 0.5 txresp| \r\n *** s1 0.5 chunked **** s1 0.5 chunked| 18\r\n **** s1 0.5 chunked| <1><1>\r\n *** s1 0.5 chunked **** s1 0.5 chunked| 27\r\n **** s1 0.5 chunked| <2><2>\r\n *** s1 0.5 chunked **** s1 0.5 chunked| 29\r\n **** s1 0.5 chunked| <3><3>\r\n *** s1 0.5 chunked **** s1 0.5 chunked| 27\r\n **** s1 0.5 chunked| <4><4>\r\n *** s1 0.5 chunked **** s1 0.5 chunked| 10\r\n **** s1 0.5 chunked|

\r\n *** s1 0.5 chunkedlen **** s1 0.5 chunked| 100\r\n **** s1 0.5 chunked| 0123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567\r\n *** s1 0.5 chunked **** s1 0.5 chunked| 12\r\n **** s1 0.5 chunked|

\r\n *** s1 0.5 chunked **** s1 0.5 chunked| 10\r\n **** s1 0.5 chunked|

\r\n *** s1 0.5 chunkedlen **** s1 0.5 chunked| 10000\r\n **** s1 0.5 chunked| 01234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701... *** s1 0.5 chunked **** s1 0.5 chunked| 12\r\n **** s1 0.5 chunked|

\r\n *** s1 0.5 chunked **** s1 0.5 chunked| e\r\n **** s1 0.5 chunked| \r\n *** s1 0.5 chunkedlen **** s1 0.5 chunked| 100\r\n **** s1 0.5 chunked| 0123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567\r\n *** s1 0.5 chunked **** s1 0.5 chunked| e\r\n **** s1 0.5 chunked| \r\n *** s1 0.5 chunkedlen **** s1 0.5 chunked| 10000\r\n **** s1 0.5 chunked| 01234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701... *** s1 0.5 chunked **** s1 0.5 chunked| e\r\n **** s1 0.5 chunked| \r\n *** s1 0.5 chunkedlen **** s1 0.5 chunked| 0\r\n **** s1 0.5 chunked| \r\n *** s1 0.5 rxreq **** v1 0.5 vsl| 1000 Begin c sess 0 HTTP/1 **** v1 0.5 vsl| 1000 SessOpen c 127.0.0.1 36946 127.0.0.1:0 127.0.0.1 55617 1393502162.254776 12 **** v1 0.5 vsl| 1001 Begin c req 1000 rxreq **** v1 0.5 vsl| 1000 Link c req 1001 rxreq **** v1 0.5 vsl| 1001 ReqStart c 127.0.0.1 36946 **** v1 0.5 vsl| 1001 ReqMethod c GET **** v1 0.5 vsl| 1001 ReqURL c bar **** v1 0.5 vsl| 1001 ReqProtocol c HTTP/1.1 **** v1 0.5 vsl| 1001 VCL_call c RECV **** v1 0.5 vsl| 1001 ReqHeader c X-Forwarded-For: 127.0.0.1 **** v1 0.5 vsl| 1001 VCL_return c hash **** v1 0.5 vsl| 1001 VCL_call c HASH **** v1 0.5 vsl| 1001 VCL_return c lookup **** v1 0.5 vsl| 1001 Debug c XXXX MISS **** v1 0.5 vsl| 1001 VCL_call c MISS **** v1 0.5 vsl| 1001 VCL_return c fetch **** v1 0.5 vsl| 1002 Begin b bereq 1001 fetch **** v1 0.5 vsl| 1001 Link c bereq 1002 fetch **** v1 0.5 vsl| 1002 BereqMethod b GET **** v1 0.5 vsl| 1002 BereqURL b bar **** v1 0.5 vsl| 1002 BereqProtocol b HTTP/1.1 **** v1 0.5 vsl| 1002 BereqHeader b X-Forwarded-For: 127.0.0.1 **** v1 0.5 vsl| 1002 BereqHeader b Accept-Encoding: gzip **** v1 0.5 vsl| 1002 VCL_call b BACKEND_FETCH **** v1 0.5 vsl| 1002 VCL_return b fetch **** v1 0.5 vsl| 1002 BereqHeader b X-Varnish: 1002 **** v1 0.5 vsl| 1002 Debug b XXX BOS: 0 -> 1 **** v1 0.5 vsl| 1002 BackendOpen b 15 s1(127.0.0.1,,51043) 127.0.0.1 49855 **** v1 0.5 vsl| 1002 Backend b 15 s1 s1(127.0.0.1,,51043) **** v1 0.5 vsl| 1002 BereqHeader b Host: 127.0.0.1 **** v1 0.5 vsl| 1002 BerespProtocol b HTTP/1.1 **** v1 0.5 vsl| 1002 BerespStatus b 200 **** v1 0.5 vsl| 1002 BerespResponse b Ok **** v1 0.5 vsl| 1002 BerespHeader b Transfer-encoding: chunked **** v1 0.5 vsl| 1002 TTL b RFC 20 -1 -1 1393502162 1393502162 0 0 0 **** v1 0.5 vsl| 1002 VCL_call b BACKEND_RESPONSE **** v1 0.5 vsl| 1002 VCL_return b deliver **** v1 0.5 vsl| 1002 Storage b malloc s0 **** v1 0.5 vsl| 1002 ObjProtocol b HTTP/1.1 **** v1 0.5 vsl| 1002 ObjStatus b 200 **** v1 0.5 vsl| 1002 ObjResponse b Ok **** v1 0.5 vsl| 1002 ESI_xmlerror b ERR at 16 ESI 1.0 illegal end-tag **** v1 0.5 vsl| 1002 ESI_xmlerror b ERR at 40 XML 1.0 '>' does not follow '/' in tag **** v1 0.5 vsl| 1002 ESI_xmlerror b ERR at 60 ESI 1.0 needs final '/' **** v1 0.5 vsl| 1002 ESI_xmlerror b WARN at 130 ESI 1.0 lacks final '/' **** v1 0.5 vsl| 1002 ESI_xmlerror b ERR at 138 ESI 1.0 element **** v1 0.6 vsl| 1002 Fetch_Body b 2(chunked) **** v1 0.6 vsl| 1002 Length b 131837 **** v1 0.6 vsl| 1002 Debug b XXX BOS: 1 -> 3 **** v1 0.6 vsl| 0 ExpKill - EXP_Inbox p=0x7f48d8000950 e=0.000000000 f=0x1c10 **** v1 0.6 vsl| 1001 RespProtocol c HTTP/1.1 **** v1 0.6 vsl| 1001 RespStatus c 200 **** v1 0.6 vsl| 1001 RespResponse c Ok **** v1 0.6 vsl| 0 ExpKill - EXP_When p=0x7f48d8000950 e=1393502192.254838943 f=0x1c10 **** v1 0.6 vsl| 1001 RespHeader c Date: Thu, 27 Feb 2014 11:56:02 GMT **** v1 0.6 vsl| 1001 RespHeader c X-Varnish: 1001 **** v1 0.6 vsl| 1001 RespHeader c Age: 0 **** v1 0.6 vsl| 1001 RespHeader c Via: 1.1 varnish **** v1 0.6 vsl| 1001 VCL_call c DELIVER **** v1 0.6 vsl| 1001 VCL_return c deliver **** v1 0.6 vsl| 1001 Debug c RES_MODE 18 **** v1 0.6 vsl| 1001 RespHeader c Transfer-Encoding: chunked **** v1 0.6 vsl| 1001 RespHeader c Connection: keep-alive ---- c1 0.6 HTTP rx EOF (fd:10 read: Success) * top 0.6 RESETTING after tests/e00019.vtc ** s1 0.6 Waiting for server **** s1 0.6 macro undef s1_addr **** s1 0.6 macro undef s1_port **** s1 0.6 macro undef s1_sock ** v1 1.6 Wait *** v1 1.6 debug| Child (6126) died signal=6\n *** v1 1.6 debug| Child (6126) Panic message: Assert error in V1D_Deliver(), cache/cache_http1_deliver.c line 297:\n *** v1 1.6 debug| Condition((req->obj->objcore->busyobj) == 0) not true.\n *** v1 1.6 debug| thread = (cache-worker)\n *** v1 1.6 debug| ident = Linux,3.12-1-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll\n *** v1 1.6 debug| Backtrace:\n *** v1 1.6 debug| 0x44a519: pan_backtrace+0x19\n *** v1 1.6 debug| 0x44a40b: pan_ic+0x25b\n *** v1 1.6 debug| 0x454a0e: V1D_Deliver+0x87e\n *** v1 1.6 debug| 0x453220: cnt_deliver+0xa20\n *** v1 1.6 debug| 0x44f176: CNT_Request+0x706\n *** v1 1.6 debug| 0x4407f2: HTTP1_Session+0x5c2\n *** v1 1.6 debug| 0x458180: ses_req_pool_task+0x210\n *** v1 1.6 debug| 0x457bd1: ses_sess_pool_task+0x261\n *** v1 1.6 debug| 0x4571d1: SES_pool_accept_task+0x2a1\n *** v1 1.6 debug| 0x44d213: Pool_Work_Thread+0x5e3\n *** v1 1.6 debug| req = 0x7f48e80409a0 {\n *** v1 1.6 debug| sp = 0x7f48ec000fa0, vxid = 1073742825, step = R_STP_DELIVER,\n *** v1 1.6 debug| req_body = R_BODY_NONE,\n *** v1 1.6 debug| err_code = 200, err_reason = (null),\n *** v1 1.6 debug| restarts = 0, esi_level = 0\n *** v1 1.6 debug| sp = 0x7f48ec000fa0 {\n *** v1 1.6 debug| fd = 12, vxid = 1000,\n *** v1 1.6 debug| client = 127.0.0.1 36946,\n *** v1 1.6 debug| step = S_STP_WORKING,\n *** v1 1.6 debug| },\n *** v1 1.6 debug| worker = 0x7f490c47fc68 {\n *** v1 1.6 debug| ws = 0x7f490c47fe68 {\n *** v1 1.6 debug| id = "wrk",\n *** v1 1.6 debug| {s,f,r,e} = {0x7f490c47f430,+80,+2048,+2048},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| VCL::method = 0x0,\n *** v1 1.6 debug| VCL::return = deliver,\n *** v1 1.6 debug| },\n *** v1 1.6 debug| ws = 0x7f48e8040b20 {\n *** v1 1.6 debug| id = "req",\n *** v1 1.6 debug| {s,f,r,e} = {0x7f48e8042970,+160,(nil),+57392},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[req] = {\n *** v1 1.6 debug| ws = 0x7f48e8040b20[req]\n *** v1 1.6 debug| "GET",\n *** v1 1.6 debug| "bar",\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "X-Forwarded-For: 127.0.0.1",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[resp] = {\n *** v1 1.6 debug| ws = 0x7f48e8040b20[req]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| "Date: Thu, 27 Feb 2014 11:56:02 GMT",\n *** v1 1.6 debug| "X-Varnish: 1001",\n *** v1 1.6 debug| "Age: 0",\n *** v1 1.6 debug| "Via: 1.1 varnish",\n *** v1 1.6 debug| "Transfer-Encoding: chunked",\n *** v1 1.6 debug| "Connection: keep-alive",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| vcl = {\n *** v1 1.6 debug| srcname = {\n *** v1 1.6 debug| "input",\n *** v1 1.6 debug| "Default",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| busyobj = 0x7f48f80409a0 {\n *** v1 1.6 debug| ws = 0x7f48f8040a68 {\n *** v1 1.6 debug| id = "bo",\n *** v1 1.6 debug| {s,f,r,e} = {0x7f48f8042960,+464,(nil),+57408},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| is_do_esi\n *** v1 1.6 debug| is_is_gunzip\n *** v1 1.6 debug| bodystatus = 2 (chunked),\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[bereq] = {\n *** v1 1.6 debug| ws = 0x7f48f8040a68[bo]\n *** v1 1.6 debug| "GET",\n *** v1 1.6 debug| "bar",\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "X-Forwarded-For: 127.0.0.1",\n *** v1 1.6 debug| "Accept-Encoding: gzip",\n *** v1 1.6 debug| "X-Varnish: 1002",\n *** v1 1.6 debug| "Host: 127.0.0.1",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| http[beresp] = {\n *** v1 1.6 debug| ws = 0x7f48f8040a68[bo]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| "Transfer-encoding: chunked",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| ws = 0x7f48f8040be8 {\n *** v1 1.6 debug| id = "obj",\n *** v1 1.6 debug| {s,f,r,e} = {0x7f48dc000a10,+32,(nil),+32},\n *** v1 1.6 debug| },\n *** v1 1.6 debug| obj (FETCH) = 0x7f48dc0008c0 {\n *** v1 1.6 debug| vxid = 2147484650,\n *** v1 1.6 debug| http[obj] = {\n *** v1 1.6 debug| ws = 0x7f48f8040be8[obj]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| len = 131837,\n *** v1 1.6 debug| store = {\n *** v1 1.6 debug| 131072 {\n *** v1 1.6 debug| 3c 31 3e 3c 2f 65 73 69 3a 63 6f 6d 6d 65 6e 74 |<1><1><2><2><|\n *** v1 1.6 debug| [131008 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| 765 {\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| [701 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| }\n *** v1 1.6 debug| obj (REQ) = 0x7f48dc0008c0 {\n *** v1 1.6 debug| vxid = 2147484650,\n *** v1 1.6 debug| http[obj] = {\n *** v1 1.6 debug| ws = 0x7f48f8040be8[obj]\n *** v1 1.6 debug| "HTTP/1.1",\n *** v1 1.6 debug| "200",\n *** v1 1.6 debug| "Ok",\n *** v1 1.6 debug| },\n *** v1 1.6 debug| len = 131837,\n *** v1 1.6 debug| store = {\n *** v1 1.6 debug| 131072 {\n *** v1 1.6 debug| 3c 31 3e 3c 2f 65 73 69 3a 63 6f 6d 6d 65 6e 74 |<1><1><2><2><|\n *** v1 1.6 debug| [131008 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| 765 {\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37 30 |1234567012345670|\n *** v1 1.6 debug| [701 more]\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| },\n *** v1 1.6 debug| \n *** v1 1.6 debug| \n *** v1 1.7 debug| Child cleanup complete\n ** v1 1.7 R 5574 Status: 0000 (u 0.112000 s 0.152000) * top 1.7 TEST tests/e00019.vtc FAILED # top TEST tests/e00019.vtc FAILED (1.654) exit=1 lkarsten at immer:~/work/varnish-cache/bin/varnishtest$ q }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 27 12:14:25 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Feb 2014 12:14:25 -0000 Subject: [Varnish] #1440: e00019.vtc occasionally trips an assert In-Reply-To: <044.1cf9d478ad322048a9826e01a403f898@varnish-cache.org> References: <044.1cf9d478ad322048a9826e01a403f898@varnish-cache.org> Message-ID: <059.d432c62beb7dbc671eb3016c4e200cbe@varnish-cache.org> #1440: e00019.vtc occasionally trips an assert ----------------------+---------------------------------------- Reporter: martin | Owner: Poul-Henning Kamp Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------------- Comment (by lkarsten): Disregard the last entry, I didn't properly clean/rebuild my tree. However, when verifying this, the test case failed of a different reason: {{{ **** top 0.0 macro def varnishd=varnishd **** top 0.0 macro def varnishadm=varnishadm **** top 0.0 macro def varnishstat=varnishstat **** top 0.0 macro def varnishhist=varnishhist **** top 0.0 macro def varnishlog=varnishlog **** top 0.0 macro def varnishncsa=varnishncsa **** top 0.0 macro def vmod_std=std from "/home/lkarsten/work/varnish- cache/lib/libvmod_std/.libs/libvmod_std.so" **** top 0.0 macro def vmod_debug=debug from "/home/lkarsten/work /varnish-cache/lib/libvmod_debug/.libs/libvmod_debug.so" **** top 0.0 macro def vmod_directors=directors from "/home/lkarsten/work/varnish- cache/lib/libvmod_directors/.libs/libvmod_directors.so" **** top 0.0 macro def pwd=/home/lkarsten/work/varnish- cache/bin/varnishtest **** top 0.0 macro def topbuild=/home/lkarsten/work/varnish-cache **** top 0.0 macro def bad_ip=192.0.2.255 **** top 0.0 macro def tmpdir=/tmp/vtc.18031.7794acc1 * top 0.0 TEST tests/e00019.vtc starting *** top 0.0 varnishtest * top 0.0 TEST Push corners in new ESI parser *** top 0.0 server ** s1 0.0 Starting server **** s1 0.0 macro def s1_addr=127.0.0.1 **** s1 0.0 macro def s1_port=36268 **** s1 0.0 macro def s1_sock=127.0.0.1 36268 * s1 0.0 Listen on 127.0.0.1 36268 *** top 0.0 varnish ** s1 0.0 Started on 127.0.0.1 36268 ** v1 0.0 Launch *** v1 0.0 CMD: cd ${pwd} && ${varnishd} -d -d -n /tmp/vtc.18031.7794acc1/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -a '127.0.0.1:0' -M '127.0.0.1 50381' -P /tmp/vtc.18031.7794acc1/v1/varnishd.pid *** v1 0.0 CMD: cd /home/lkarsten/work/varnish-cache/bin/varnishtest && varnishd -d -d -n /tmp/vtc.18031.7794acc1/v1 -l 2m,1m,- -p auto_restart=off -p syslog_cli_traffic=off -p sigsegv_handler=on -a '127.0.0.1:0' -M '127.0.0.1 50381' -P /tmp/vtc.18031.7794acc1/v1/varnishd.pid *** v1 0.0 PID: 18072 *** v1 0.0 debug| Platform: Linux,3.12-1-amd64,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| 200 275 \n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Varnish Cache CLI 1.0\n *** v1 0.0 debug| -----------------------------\n *** v1 0.0 debug| Linux,3.12-1-amd64,x86_64,-smalloc,-smalloc,-hcritbit\n *** v1 0.0 debug| varnish-4.0.0-tp2 revision 0eb0c12\n *** v1 0.0 debug| \n *** v1 0.0 debug| Type 'help' for command list.\n *** v1 0.0 debug| Type 'quit' to close CLI session.\n *** v1 0.0 debug| Type 'start' to launch worker process.\n *** v1 0.0 debug| \n **** v1 0.1 CLIPOLL 1 0x1 0x0 *** v1 0.1 CLI connection fd = 9 *** v1 0.1 CLI RX 107 **** v1 0.1 CLI RX| dlcmbiufkycctwfmanotkohkodidlgpo\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Authentication required.\n **** v1 0.1 CLI TX| auth 418abac6fa0d5bc10cf71dd0696c2a46c3ebdd3f45b7f9c29477721e5b82c33e\n *** v1 0.1 CLI RX 200 **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Varnish Cache CLI 1.0\n **** v1 0.1 CLI RX| -----------------------------\n **** v1 0.1 CLI RX| Linux,3.12-1-amd64,x86_64,-smalloc,-smalloc,-hcritbit\n **** v1 0.1 CLI RX| varnish-4.0.0-tp2 revision 0eb0c12\n **** v1 0.1 CLI RX| \n **** v1 0.1 CLI RX| Type 'help' for command list.\n **** v1 0.1 CLI RX| Type 'quit' to close CLI session.\n **** v1 0.1 CLI RX| Type 'start' to launch worker process.\n **** v1 0.1 CLI TX| vcl.inline vcl1 << %XJEIFLH|)Xspa8P\n **** v1 0.1 CLI TX| vcl 4.0;\n **** v1 0.1 CLI TX| backend s1 { .host = "127.0.0.1"; .port = "36268"; }\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| \tsub vcl_backend_response {\n **** v1 0.1 CLI TX| \t\tif (bereq.url == "bar") {\n **** v1 0.1 CLI TX| \t\t\tset beresp.do_esi = true;\n **** v1 0.1 CLI TX| \t\t}\n **** v1 0.1 CLI TX| \t}\n **** v1 0.1 CLI TX| \n **** v1 0.1 CLI TX| %XJEIFLH|)Xspa8P\n *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| Message from VCC-compiler:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| Message from C-compiler:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| Message from dlopen:\n **** v1 0.2 CLI RX| Not running as root, no priv-sep\n **** v1 0.2 CLI RX| \n **** v1 0.2 CLI RX| VCL compiled. **** v1 0.2 CLI TX| vcl.use vcl1 *** v1 0.2 CLI RX 200 **** v1 0.2 CLI RX| VCL 'vcl1' now active ** v1 0.2 Start **** v1 0.2 CLI TX| start *** v1 0.2 debug| child (18416) Started\n *** v1 0.2 CLI RX 200 *** v1 0.2 wait-running **** v1 0.2 CLI TX| status *** v1 0.2 debug| Child (18416) said Not running as root, no priv- sep\n *** v1 0.2 debug| Child (18416) said Child starts\n *** v1 0.3 CLI RX 200 **** v1 0.3 CLI RX| Child in state running **** v1 0.3 CLI TX| debug.xid 999 *** v1 0.3 CLI RX 200 **** v1 0.3 CLI RX| XID is 999 **** v1 0.3 CLI TX| debug.listen_address **** v1 0.3 vsl| 0 CLI - Rd debug.xid 999 **** v1 0.3 vsl| 0 CLI - Wr 200 10 XID is 999 *** v1 0.4 CLI RX 200 **** v1 0.4 CLI RX| 127.0.0.1 34864\n ** v1 0.4 Listen on 127.0.0.1 34864 **** v1 0.4 macro def v1_addr=127.0.0.1 **** v1 0.4 macro def v1_port=34864 **** v1 0.4 macro def v1_sock=127.0.0.1 34864 *** top 0.4 varnish **** v1 0.4 CLI TX| param.set debug +esi_chop **** v1 0.4 vsl| 0 CLI - Rd debug.listen_address **** v1 0.4 vsl| 0 CLI - Wr 200 16 127.0.0.1 34864 *** v1 0.4 CLI RX 200 ** v1 0.4 CLI 200 *** top 0.4 varnish **** v1 0.4 CLI TX| param.set debug +syncvsl *** v1 0.4 CLI RX 200 ** v1 0.4 CLI 200 *** top 0.4 client ** c1 0.4 Starting client ** c1 0.4 Waiting for client *** c1 0.4 Connect to 127.0.0.1 34864 *** c1 0.4 connected fd 10 from 127.0.0.1 45443 to 127.0.0.1 34864 *** c1 0.4 txreq **** c1 0.4 txreq| GET bar HTTP/1.1\r\n **** c1 0.4 txreq| \r\n *** c1 0.4 rxresp *** s1 0.4 accepted fd 4 *** s1 0.4 rxreq **** s1 0.4 rxhdr| GET bar HTTP/1.1\r\n **** s1 0.4 rxhdr| X-Forwarded-For: 127.0.0.1\r\n **** s1 0.4 rxhdr| Accept-Encoding: gzip\r\n **** s1 0.4 rxhdr| X-Varnish: 1002\r\n **** s1 0.4 rxhdr| Host: 127.0.0.1\r\n **** s1 0.4 rxhdr| \r\n **** s1 0.4 http[ 0] | GET **** s1 0.4 http[ 1] | bar **** s1 0.4 http[ 2] | HTTP/1.1 **** s1 0.4 http[ 3] | X-Forwarded-For: 127.0.0.1 **** s1 0.4 http[ 4] | Accept-Encoding: gzip **** s1 0.4 http[ 5] | X-Varnish: 1002 **** s1 0.4 http[ 6] | Host: 127.0.0.1 **** s1 0.4 bodylen = 0 *** s1 0.4 txresp **** s1 0.4 txresp| HTTP/1.1 200 Ok\r\n **** s1 0.4 txresp| Transfer-encoding: chunked\r\n **** s1 0.4 txresp| \r\n *** s1 0.4 chunked **** s1 0.4 chunked| 18\r\n **** s1 0.4 chunked| <1><1>\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 27\r\n **** s1 0.4 chunked| <2><2>\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 29\r\n **** s1 0.4 chunked| <3><3>\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 27\r\n **** s1 0.4 chunked| <4><4>\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 10\r\n **** s1 0.4 chunked|

\r\n *** s1 0.4 chunkedlen **** s1 0.4 chunked| 100\r\n **** s1 0.4 chunked| 0123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 12\r\n **** s1 0.4 chunked|

\r\n *** s1 0.4 chunked **** s1 0.4 chunked| 10\r\n **** s1 0.4 chunked|

\r\n *** s1 0.4 chunkedlen **** s1 0.4 chunked| 10000\r\n **** s1 0.4 chunked| 01234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701... *** s1 0.4 chunked **** s1 0.4 chunked| 12\r\n **** s1 0.4 chunked|

\r\n *** s1 0.4 chunked **** s1 0.4 chunked| e\r\n **** s1 0.4 chunked| \r\n *** s1 0.4 chunkedlen **** s1 0.4 chunked| 100\r\n **** s1 0.4 chunked| 0123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567\r\n *** s1 0.4 chunked **** s1 0.4 chunked| e\r\n **** s1 0.4 chunked| \r\n *** s1 0.4 chunkedlen **** v1 0.4 vsl| 1000 Begin c sess 0 HTTP/1 **** v1 0.4 vsl| 1000 SessOpen c 127.0.0.1 45443 127.0.0.1:0 127.0.0.1 34864 1393503049.402590 12 **** v1 0.4 vsl| 1001 Begin c req 1000 rxreq **** v1 0.4 vsl| 1000 Link c req 1001 rxreq **** v1 0.4 vsl| 1001 ReqStart c 127.0.0.1 45443 **** v1 0.4 vsl| 1001 ReqMethod c GET **** v1 0.4 vsl| 1001 ReqURL c bar **** v1 0.4 vsl| 1001 ReqProtocol c HTTP/1.1 **** v1 0.4 vsl| 1001 VCL_call c RECV **** v1 0.4 vsl| 1001 ReqHeader c X-Forwarded-For: 127.0.0.1 **** v1 0.4 vsl| 1001 VCL_return c hash **** v1 0.4 vsl| 1001 VCL_call c HASH **** v1 0.4 vsl| 1001 VCL_return c lookup **** v1 0.4 vsl| 1001 Debug c XXXX MISS **** v1 0.4 vsl| 1001 VCL_call c MISS **** v1 0.4 vsl| 1001 VCL_return c fetch **** v1 0.4 vsl| 1002 Begin b bereq 1001 fetch **** v1 0.4 vsl| 1001 Link c bereq 1002 fetch **** v1 0.4 vsl| 1002 BereqMethod b GET **** v1 0.4 vsl| 1002 BereqURL b bar **** v1 0.4 vsl| 1002 BereqProtocol b HTTP/1.1 **** v1 0.4 vsl| 1002 BereqHeader b X-Forwarded-For: 127.0.0.1 **** v1 0.4 vsl| 1002 BereqHeader b Accept-Encoding: gzip **** v1 0.4 vsl| 1002 VCL_call b BACKEND_FETCH **** v1 0.4 vsl| 1002 VCL_return b fetch **** v1 0.4 vsl| 1002 BereqHeader b X-Varnish: 1002 **** v1 0.4 vsl| 1002 BackendOpen b 15 s1(127.0.0.1,,36268) 127.0.0.1 41768 **** v1 0.4 vsl| 1002 Backend b 15 s1 s1(127.0.0.1,,36268) **** v1 0.4 vsl| 1002 BereqHeader b Host: 127.0.0.1 **** v1 0.4 vsl| 1002 BerespProtocol b HTTP/1.1 **** v1 0.4 vsl| 1002 BerespStatus b 200 **** v1 0.4 vsl| 1002 BerespResponse b Ok **** v1 0.4 vsl| 1002 BerespHeader b Transfer-encoding: chunked **** v1 0.4 vsl| 1002 TTL b RFC 20 -1 -1 1393503049 1393503049 0 0 0 **** v1 0.4 vsl| 1002 VCL_call b BACKEND_RESPONSE **** v1 0.4 vsl| 1002 VCL_return b deliver **** v1 0.4 vsl| 1002 Storage b malloc s0 **** v1 0.4 vsl| 1002 ObjProtocol b HTTP/1.1 **** v1 0.4 vsl| 1002 ObjStatus b 200 **** v1 0.4 vsl| 1002 ObjResponse b Ok **** v1 0.4 vsl| 1002 ESI_xmlerror b ERR at 16 ESI 1.0 illegal end-tag **** v1 0.4 vsl| 1002 ESI_xmlerror b ERR at 38 XML 1.0 '>' does not follow '/' in tag **** v1 0.4 vsl| 1002 ESI_xmlerror b ERR at 60 ESI 1.0 needs final '/' **** v1 0.4 vsl| 1002 ESI_xmlerror b WARN at 130 ESI 1.0 lacks final '/' **** v1 0.4 vsl| 1002 ESI_xmlerror b ERR at 139 ESI 1.0 element **** s1 0.4 chunked| 10000\r\n **** s1 0.4 chunked| 01234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701234567012345670123456701... *** s1 0.4 chunked **** s1 0.4 chunked| e\r\n **** s1 0.4 chunked| \r\n *** s1 0.4 chunkedlen **** s1 0.4 chunked| 0\r\n **** s1 0.4 chunked| \r\n *** s1 0.4 rxreq **** c1 0.6 rxhdr| HTTP/1.1 200 Ok\r\n **** c1 0.6 rxhdr| Date: Thu, 27 Feb 2014 12:10:49 GMT\r\n **** c1 0.6 rxhdr| X-Varnish: 1001\r\n **** c1 0.6 rxhdr| Age: 0\r\n **** c1 0.6 rxhdr| Via: 1.1 varnish\r\n **** c1 0.6 rxhdr| Transfer-Encoding: chunked\r\n **** c1 0.6 rxhdr| Connection: keep-alive\r\n **** c1 0.6 rxhdr| \r\n **** c1 0.6 http[ 0] | HTTP/1.1 **** c1 0.6 http[ 1] | 200 **** c1 0.6 http[ 2] | Ok **** c1 0.6 http[ 3] | Date: Thu, 27 Feb 2014 12:10:49 GMT **** c1 0.6 http[ 4] | X-Varnish: 1001 **** c1 0.6 http[ 5] | Age: 0 **** c1 0.6 http[ 6] | Via: 1.1 varnish **** c1 0.6 http[ 7] | Transfer-Encoding: chunked **** c1 0.6 http[ 8] | Connection: keep-alive **** c1 0.6 len| 0015\r\n **** c1 0.6 chunk| <1><1><2><2><3><3><4> **** v1 0.6 vsl| 1002 Fetch_Body b 2(chunked) **** v1 0.6 vsl| 1002 Length b 131837 **** v1 0.6 vsl| 0 ExpKill - EXP_Inbox p=0x7fb918000950 e=0.000000000 f=0x1c10 **** v1 0.6 vsl| 1001 RespProtocol c HTTP/1.1 **** v1 0.6 vsl| 1001 RespStatus c 200 **** v1 0.6 vsl| 1001 RespResponse c Ok **** v1 0.6 vsl| 0 ExpKill - EXP_When p=0x7fb918000950 e=1393503079.402649403 f=0x1c10 **** v1 0.6 vsl| 1001 RespHeader c Date: Thu, 27 Feb 2014 12:10:49 GMT **** v1 0.6 vsl| 1001 RespHeader c X-Varnish: 1001 **** v1 0.6 vsl| 1001 RespHeader c Age: 0 **** v1 0.6 vsl| 1001 RespHeader c Via: 1.1 varnish **** v1 0.6 vsl| 1001 VCL_call c DELIVER **** v1 0.6 vsl| 1001 VCL_return c deliver **** v1 0.6 vsl| 1001 Debug c RES_MODE 18 **** v1 0.6 vsl| 1001 RespHeader c Transfer-Encoding: chunked **** v1 0.6 vsl| 1001 RespHeader c Connection: keep-alive **** v1 0.6 vsl| 1003 Begin c req 1000 rxreq **** v1 0.6 vsl| 1000 Link c req 1003 rxreq **** v1 0.6 vsl| 1003 Begin c req 1001 esi **** v1 0.6 vsl| 1001 Link c req 1003 esi **** v1 0.6 vsl| 1003 ReqStart c 127.0.0.1 45443 **** v1 0.6 vsl| 1003 ReqMethod c GET **** v1 0.6 vsl| 1003 ReqURL c bar/foo **** v1 0.6 vsl| 1003 ReqProtocol c HTTP/1.1 **** v1 0.6 vsl| 1003 VCL_call c RECV **** v1 0.6 vsl| 1003 ReqHeader c X-Forwarded-For: 127.0.0.1 **** v1 0.6 vsl| 1003 VCL_return c hash **** v1 0.6 vsl| 1003 VCL_call c HASH **** v1 0.6 vsl| 1003 VCL_return c lookup **** v1 0.6 vsl| 1003 Debug c XXXX MISS **** v1 0.6 vsl| 1003 VCL_call c MISS **** v1 0.6 vsl| 1003 VCL_return c fetch **** v1 0.6 vsl| 1004 Begin b bereq 1003 fetch **** v1 0.6 vsl| 1003 Link c bereq 1004 fetch **** v1 0.6 vsl| 1004 BereqMethod b GET **** v1 0.6 vsl| 1004 BereqURL b bar/foo **** v1 0.6 vsl| 1004 BereqProtocol b HTTP/1.1 **** v1 0.6 vsl| 1004 BereqHeader b X-Forwarded-For: 127.0.0.1 **** v1 0.6 vsl| 1004 BereqHeader b Accept-Encoding: gzip **** v1 0.6 vsl| 1004 VCL_call b BACKEND_FETCH **** v1 0.6 vsl| 1004 VCL_return b fetch **** v1 0.6 vsl| 1004 BereqHeader b X-Varnish: 1004 **** v1 0.6 vsl| 1004 BackendOpen b 16 s1(127.0.0.1,,36268) 127.0.0.1 41777 **** v1 0.6 vsl| 1004 Backend b 16 s1 s1(127.0.0.1,,36268) **** v1 0.6 vsl| 1004 BereqHeader b Host: 127.0.0.1 **** v1 0.6 vsl| 1002 BackendReuse b 15 s1(127.0.0.1,,36268) **** v1 0.6 vsl| 1002 BereqEnd b 1393503049.402762890 1393503049.554100037 0.000026806 0.000209815 0.150583778 0.150793593 **** v1 0.6 vsl| 1002 End b **** v1 3.3 vsl| 0 CLI - Rd ping **** v1 3.3 vsl| 0 CLI - Wr 200 19 PONG 1393503052 1.0 **** v1 6.2 vsl| 0 CLI - Rd ping **** v1 6.2 vsl| 0 CLI - Wr 200 19 PONG 1393503055 1.0 **** v1 9.2 vsl| 0 CLI - Rd ping **** v1 9.2 vsl| 0 CLI - Wr 200 19 PONG 1393503058 1.0 **** v1 12.3 vsl| 0 CLI - Rd ping **** v1 12.3 vsl| 0 CLI - Wr 200 19 PONG 1393503061 1.0 **** v1 15.3 vsl| 0 CLI - Rd ping **** v1 15.3 vsl| 0 CLI - Wr 200 19 PONG 1393503064 1.0 ---- s1 15.5 HTTP rx timeout (fd:4 15000 ms) ---- c1 15.6 HTTP rx timeout (fd:10 15000 ms) * top 15.6 RESETTING after tests/e00019.vtc ** s1 15.6 Waiting for server **** s1 15.6 macro undef s1_addr **** s1 15.6 macro undef s1_port **** s1 15.6 macro undef s1_sock **** v1 15.6 vsl| 1004 FetchError b http first read error: EOF **** v1 15.6 vsl| 1004 BackendClose b 16 s1(127.0.0.1,,36268) **** v1 15.6 vsl| 1004 BerespProtocol b HTTP/1.1 **** v1 15.6 vsl| 1004 BerespStatus b 503 **** v1 15.6 vsl| 1004 BerespResponse b Backend fetch failed **** v1 15.6 vsl| 1004 BerespHeader b Content-Length: 0 **** v1 15.6 vsl| 1004 BerespHeader b Connection: close **** v1 15.6 vsl| 1004 VCL_call b BACKEND_ERROR **** v1 15.6 vsl| 1004 VCL_return b deliver **** v1 15.6 vsl| 1004 BerespHeader b Content-Length: 0 **** v1 15.6 vsl| 1004 BerespHeader b X-XXXPHK: yes **** v1 15.6 vsl| 1004 Storage b malloc Transient **** v1 15.6 vsl| 1004 ObjProtocol b HTTP/1.1 **** v1 15.6 vsl| 1004 ObjStatus b 503 **** v1 15.6 vsl| 1004 ObjResponse b Backend fetch failed **** v1 15.6 vsl| 1004 ObjHeader b X-XXXPHK: yes **** v1 15.6 vsl| 0 ExpKill - EXP_Inbox p=0x7fb918000b60 e=0.000000000 f=0x1c10 **** v1 15.6 vsl| 1004 BereqEnd b 1393503049.553846598 1393503064.566039085 0.000018227 nan nan nan **** v1 15.6 vsl| 0 ExpKill - EXP_When p=0x7fb918000b60 e=0.000000000 f=0x1c10 **** v1 15.6 vsl| 0 ExpKill - EXP_Expired x=1004 t=-1393503065 **** v1 15.6 vsl| 1004 End b **** v1 15.6 vsl| 1003 RespProtocol c HTTP/1.1 **** v1 15.6 vsl| 1003 RespStatus c 503 **** v1 15.6 vsl| 1003 RespResponse c Backend fetch failed **** v1 15.6 vsl| 1003 RespHeader c X-XXXPHK: yes **** v1 15.6 vsl| 1003 RespHeader c Date: Thu, 27 Feb 2014 12:11:04 GMT **** v1 15.6 vsl| 1003 RespHeader c X-Varnish: 1003 **** v1 15.6 vsl| 1003 RespHeader c Age: 1393503065 **** v1 15.6 vsl| 1003 RespHeader c Via: 1.1 varnish **** v1 15.6 vsl| 1003 VCL_call c DELIVER **** v1 15.6 vsl| 1003 VCL_return c deliver **** v1 15.6 vsl| 1003 RespHeader c Content-Length: 0 **** v1 15.6 vsl| 1003 Debug c RES_MODE 28 **** v1 15.6 vsl| 1003 RespUnset c Content-Length: 0 **** v1 15.6 vsl| 1003 RespHeader c Transfer-Encoding: chunked **** v1 15.6 vsl| 1003 RespHeader c Connection: keep-alive **** v1 15.6 vsl| 1003 Debug c XXX REF 1 **** v1 15.6 vsl| 1003 Length c 0 **** v1 15.6 vsl| 1003 ReqEnd c 1393503049.402649403 1393503049.402590036 -15.163525820 15.163466454 -15.163525820 **** v1 15.6 vsl| 1003 End c **** v1 15.6 vsl| 0 End - **** v1 15.6 vsl| 1001 Debug c XXX REF 2 **** v1 15.6 vsl| 1001 Length c 0 **** v1 15.6 vsl| 1001 ReqEnd c 1393503049.402649403 1393503049.402590036 -0.151128054 0.151068687 -0.151128054 **** v1 15.6 vsl| 1001 End c ** v1 16.6 Wait **** v1 16.6 vsl| 0 CLI - EOF on CLI connection, worker stops ** v1 17.6 R 18072 Status: 0000 (u 0.148000 s 0.160000) * top 17.6 TEST tests/e00019.vtc FAILED # top TEST tests/e00019.vtc FAILED (17.612) exit=1 lkarsten at immer:~/work/varnish-cache/bin/varnishtest$ }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 27 14:17:42 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Feb 2014 14:17:42 -0000 Subject: [Varnish] #1441: Varnish API does not group correctly for ESI Message-ID: <044.ba370e030f72295c625b9b51c5f8af95@varnish-cache.org> #1441: Varnish API does not group correctly for ESI ----------------------+------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- When using varnishlog -g request, the grouping is not correct for ESI subrequests. This is due to duplicate Begin and End records. This happens because first the log records for a normal request are logged, before the ESI marked ones. Attached test case. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 27 14:20:33 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Feb 2014 14:20:33 -0000 Subject: [Varnish] #1441: Varnish API does not group correctly for ESI In-Reply-To: <044.ba370e030f72295c625b9b51c5f8af95@varnish-cache.org> References: <044.ba370e030f72295c625b9b51c5f8af95@varnish-cache.org> Message-ID: <059.34c76ba28068a531c81796f0403859ca@varnish-cache.org> #1441: Varnish API does not group correctly for ESI ----------------------+-------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Description changed by martin: Old description: > When using varnishlog -g request, the grouping is not correct for ESI > subrequests. > > This is due to duplicate Begin and End records. This happens because > first the log records for a normal request are logged, before the ESI > marked ones. > > Attached test case. New description: When using varnishlog -g request or -g session, the grouping is not correct for ESI subrequests. This is due to duplicate Begin and End records. This happens because first the log records for a normal request are logged, before the ESI marked ones. Attached test case. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Feb 27 15:02:59 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 27 Feb 2014 15:02:59 -0000 Subject: [Varnish] #1441: Varnish API does not group correctly for ESI In-Reply-To: <044.ba370e030f72295c625b9b51c5f8af95@varnish-cache.org> References: <044.ba370e030f72295c625b9b51c5f8af95@varnish-cache.org> Message-ID: <059.2425400a2f33eb8b95dd08ee1cceb3b8@varnish-cache.org> #1441: Varnish API does not group correctly for ESI ----------------------+----------------------------------------------- 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 ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [df1cdb82cb1c103c1ae610fc6e6ebb4e75de054f]: {{{ #!CommitTicketReference repository="" revision="df1cdb82cb1c103c1ae610fc6e6ebb4e75de054f" Avoid duplicate Begin/End records on ESI subrequests When starting an ESI subrequest, make sure that the Begin/End headers are only output once, formatted for ESI. Fixes: #1441 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Feb 28 10:51:37 2014 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 28 Feb 2014 10:51:37 -0000 Subject: [Varnish] #1440: e00019.vtc occasionally trips an assert In-Reply-To: <044.1cf9d478ad322048a9826e01a403f898@varnish-cache.org> References: <044.1cf9d478ad322048a9826e01a403f898@varnish-cache.org> Message-ID: <059.04db87de34dc26c78c5aced58b5d2c71@varnish-cache.org> #1440: e00019.vtc occasionally trips an assert ----------------------+---------------------------------------- Reporter: martin | Owner: Poul-Henning Kamp Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------------- Comment (by martin): I have analyzed this, and found the timeout failure to be caused by a test design issue rather than a Varnish problem. When finishing a fetch, the BO is set to BOS_FINISHED before the fetch thread calls VDI_RecycleFd. If the second (esi-included object) fetch is issued in this window, it'll create a new backend connection, which the varnishtest server can't cope with. This causes a timeout failure. One solution could be to alter the test case having the server say "Connection: close" on the first reply and do an accept between the backend requests. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From mike at cloudcannon.com Wed Feb 5 20:33:55 2014 From: mike at cloudcannon.com (Mike Neumegen) Date: Wed, 05 Feb 2014 20:33:55 -0000 Subject: Gzipping SVG Message-ID: Gzip doesn't work on SVG files for me. I have GZip compression working for other file types. I've tried this VLC and it didn't work. I'm not sure what else to try. I wasn't sure whether I needed to escape the + or not so I put all the versions in: if (beresp.http.content-type ~ "^(image/svg|image/svg\+xml|image/svg+xml)$") { set beresp.do_gzip = true; } It returns the file but does not perform the compression. Is my configuration wrong or is this a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: