Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Varnish: Bugs

#1027: signal 6 on calling error in vcl_deliver

 

 

Varnish bugs RSS feed   Index | Next | Previous | View Threaded


varnish-bugs at varnish-cache

Oct 5, 2011, 2:11 PM

Post #1 of 8 (410 views)
Permalink
#1027: signal 6 on calling error in vcl_deliver

#1027: signal 6 on calling error in vcl_deliver
-------------------+--------------------------------------------------------
Reporter: kwy | Type: defect
Status: new | Priority: normal
Milestone: | Component: varnishd
Version: trunk | Severity: normal
Keywords: |
-------------------+--------------------------------------------------------
Hi.

The following VCL will core varnish on accessing the /fail url, as will
any other use of error in deliver.

I have specific use cases for doing this, in particular to force a
synthetic response on conditions detected in vcl_deliver.

https://github.com/comotion/security.vcl/blob/master/vcl/modules/cloak.vcl

As it is I've worked around the issue by using restarts, but I 'spect you
want to avoid a segfault anyways.

---

sub vcl_recv {
if (req.url ~ "^/fail"){
set req.http.fail = "fail";
return (lookup);
}
}

sub vcl_deliver {
if(req.http.fail){
error 200 "ok";
}
}



Child (23949) died signal=6 (core dumped)
Child (23949) Panic message: Assert error in VCL_deliver_method(),
../../include/vcl_returns.h line 62:
Condition((1U << sp->handling) & ((1U << 9) | (1U << 0) )) not true.
thread = (cache-worker)
ident = Linux,2.6.32-33-server,x86_64,-sfile,-smalloc,-hcritbit,epoll
Backtrace:
0x43665e: pan_backtrace+19
0x436933: pan_ic+1ad
0x43f8b8: VCL_deliver_method+10a
0x416f53: cnt_prepresp+52c
0x41bec2: CNT_Session+7c3
0x437d89: Pool_Work_Thread+8b3
0x44ab46: wrk_thread_real+3e7
0x44ad0f: WRK_thread+b4
0x7ffbcfefd9ca: _end+7ffbcf867752
0x7ffbcfc5a70d: _end+7ffbcf5c4495
sp = 0x7ffbc87b5040 {
fd = 14, id = 14, xid = 1363644113,
client = 87.238.35.17 59639,
step = STP_PREPRESP,
handling = error,
err_code = 200, err_reason = ok,
restarts = 0, esi_level = 0
flags =
bodystatus = 0
ws = 0x7ffbc87b51a8 {
id = "sess",
{s,f,r,e} = {0x7ffbc87b5c48,+456,(nil),+65536},
},
http[req] = {
ws = 0x7ffbc87b51a8[sess]
"GET",
"/fail",
"HTTP/1.1",
"Host: u.delta9.pl",
"User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101
Firefox/4.0.1",
"Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Accept-Language: en-us,en;q=0.5",
"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
"Keep-Alive: 115",
"DNT: 1",
"Connection: keep-alive",
"fail: fail",
"Accept-Encoding: gzip",
},
worker = 0x7ffb40ce69d0 {
ws = 0x7ffb40ce6ca0 {
id = "wrk",
{s,f,r,e} = {0x7ffb40cd4920,+144,(nil),+65536},
},
http[resp] = {
ws = 0x7ffb40ce6ca0[wrk]
"HTTP/1.1",
"Service Unavailable",
"Server: Varnish",
"Content-Type: text/html; charset=utf-8",
"Retry-After: 5",
"Content-Length: 419",
"Accept-Ranges: bytes",
"Date: Wed, 05 Oct 2011 20:27:16 GMT",
"X-Varnish: 1363644113",
"Age: 0",
"Via: 1.1 varnish",
"Connection: close",
},
},
vcl = {
srcname = {
"input",
"Default",
},
},
obj = 0x7ffba6eff000 {
xid = 1363644113,
ws = 0x7ffba6eff018 {
id = "obj",
{s,f,r,e} = {0x7ffba6eff540,+176,(nil),+1024},
},
http[obj] = {
ws = 0x7ffba6eff018[obj]
"HTTP/1.1",
"Service Unavailable",
"Date: Wed, 05 Oct 2011 20:27:16 GMT",
"Server: Varnish",
"Content-Type: text/html; charset=utf-8",
"Retry-After: 5",
"Content-Length: 419",
},
len = 419,
store = {
419 {
0a 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 |.<?xml version="|
31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 75 |1.0" encoding="u|
74 66 2d 38 22 3f 3e 0a 3c 21 44 4f 43 54 59 50 |tf-8"?>.<!DOCTYP|
45 20 68 74 6d 6c 20 50 55 42 4c 49 43 20 22 2d |E html PUBLIC "-|
[355 more]
},
},
},
},


Child cleanup complete
child (23985) Started
Child (23985) said Child starts
Child (23985) said SMF.s0 mmap'ed 2147483648 bytes of 2147483648

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1027>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs


varnish-bugs at varnish-cache

Oct 10, 2011, 3:14 AM

Post #2 of 8 (379 views)
Permalink
Re: #1027: signal 6 on calling error in vcl_deliver [In reply to]

#1027: signal 6 on calling error in vcl_deliver
-------------------+--------------------------------------------------------
Reporter: kwy | Type: defect
Status: new | Priority: normal
Milestone: | Component: varnishd
Version: trunk | Severity: normal
Keywords: |
-------------------+--------------------------------------------------------
Description changed by kristian:

Old description:

> Hi.
>
> The following VCL will core varnish on accessing the /fail url, as will
> any other use of error in deliver.
>
> I have specific use cases for doing this, in particular to force a
> synthetic response on conditions detected in vcl_deliver.
>
> https://github.com/comotion/security.vcl/blob/master/vcl/modules/cloak.vcl
>
> As it is I've worked around the issue by using restarts, but I 'spect you
> want to avoid a segfault anyways.
>
> ---
>
> sub vcl_recv {
> if (req.url ~ "^/fail"){
> set req.http.fail = "fail";
> return (lookup);
> }
> }
>
> sub vcl_deliver {
> if(req.http.fail){
> error 200 "ok";
> }
> }
>

>
> Child (23949) died signal=6 (core dumped)
> Child (23949) Panic message: Assert error in VCL_deliver_method(),
> ../../include/vcl_returns.h line 62:
> Condition((1U << sp->handling) & ((1U << 9) | (1U << 0) )) not true.
> thread = (cache-worker)
> ident = Linux,2.6.32-33-server,x86_64,-sfile,-smalloc,-hcritbit,epoll
> Backtrace:
> 0x43665e: pan_backtrace+19
> 0x436933: pan_ic+1ad
> 0x43f8b8: VCL_deliver_method+10a
> 0x416f53: cnt_prepresp+52c
> 0x41bec2: CNT_Session+7c3
> 0x437d89: Pool_Work_Thread+8b3
> 0x44ab46: wrk_thread_real+3e7
> 0x44ad0f: WRK_thread+b4
> 0x7ffbcfefd9ca: _end+7ffbcf867752
> 0x7ffbcfc5a70d: _end+7ffbcf5c4495
> sp = 0x7ffbc87b5040 {
> fd = 14, id = 14, xid = 1363644113,
> client = 87.238.35.17 59639,
> step = STP_PREPRESP,
> handling = error,
> err_code = 200, err_reason = ok,
> restarts = 0, esi_level = 0
> flags =
> bodystatus = 0
> ws = 0x7ffbc87b51a8 {
> id = "sess",
> {s,f,r,e} = {0x7ffbc87b5c48,+456,(nil),+65536},
> },
> http[req] = {
> ws = 0x7ffbc87b51a8[sess]
> "GET",
> "/fail",
> "HTTP/1.1",
> "Host: u.delta9.pl",
> "User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101
> Firefox/4.0.1",
> "Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
> "Accept-Language: en-us,en;q=0.5",
> "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
> "Keep-Alive: 115",
> "DNT: 1",
> "Connection: keep-alive",
> "fail: fail",
> "Accept-Encoding: gzip",
> },
> worker = 0x7ffb40ce69d0 {
> ws = 0x7ffb40ce6ca0 {
> id = "wrk",
> {s,f,r,e} = {0x7ffb40cd4920,+144,(nil),+65536},
> },
> http[resp] = {
> ws = 0x7ffb40ce6ca0[wrk]
> "HTTP/1.1",
> "Service Unavailable",
> "Server: Varnish",
> "Content-Type: text/html; charset=utf-8",
> "Retry-After: 5",
> "Content-Length: 419",
> "Accept-Ranges: bytes",
> "Date: Wed, 05 Oct 2011 20:27:16 GMT",
> "X-Varnish: 1363644113",
> "Age: 0",
> "Via: 1.1 varnish",
> "Connection: close",
> },
> },
> vcl = {
> srcname = {
> "input",
> "Default",
> },
> },
> obj = 0x7ffba6eff000 {
> xid = 1363644113,
> ws = 0x7ffba6eff018 {
> id = "obj",
> {s,f,r,e} = {0x7ffba6eff540,+176,(nil),+1024},
> },
> http[obj] = {
> ws = 0x7ffba6eff018[obj]
> "HTTP/1.1",
> "Service Unavailable",
> "Date: Wed, 05 Oct 2011 20:27:16 GMT",
> "Server: Varnish",
> "Content-Type: text/html; charset=utf-8",
> "Retry-After: 5",
> "Content-Length: 419",
> },
> len = 419,
> store = {
> 419 {
> 0a 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 |.<?xml
> version="|
> 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 75 |1.0"
> encoding="u|
> 74 66 2d 38 22 3f 3e 0a 3c 21 44 4f 43 54 59 50
> |tf-8"?>.<!DOCTYP|
> 45 20 68 74 6d 6c 20 50 55 42 4c 49 43 20 22 2d |E html PUBLIC
> "-|
> [355 more]
> },
> },
> },
> },
>

> Child cleanup complete
> child (23985) Started
> Child (23985) said Child starts
> Child (23985) said SMF.s0 mmap'ed 2147483648 bytes of 2147483648

New description:

Hi.

The following VCL will core varnish on accessing the /fail url, as will
any other use of error in deliver.

I have specific use cases for doing this, in particular to force a
synthetic response on conditions detected in vcl_deliver.

https://github.com/comotion/security.vcl/blob/master/vcl/modules/cloak.vcl

As it is I've worked around the issue by using restarts, but I 'spect you
want to avoid a segfault anyways.

---
{{{

sub vcl_recv {
if (req.url ~ "^/fail"){
set req.http.fail = "fail";
return (lookup);
}
}

sub vcl_deliver {
if(req.http.fail){
error 200 "ok";
}
}

}}}

{{{
Child (23949) died signal=6 (core dumped)
Child (23949) Panic message: Assert error in VCL_deliver_method(),
../../include/vcl_returns.h line 62:
Condition((1U << sp->handling) & ((1U << 9) | (1U << 0) )) not true.
thread = (cache-worker)
ident = Linux,2.6.32-33-server,x86_64,-sfile,-smalloc,-hcritbit,epoll
Backtrace:
0x43665e: pan_backtrace+19
0x436933: pan_ic+1ad
0x43f8b8: VCL_deliver_method+10a
0x416f53: cnt_prepresp+52c
0x41bec2: CNT_Session+7c3
0x437d89: Pool_Work_Thread+8b3
0x44ab46: wrk_thread_real+3e7
0x44ad0f: WRK_thread+b4
0x7ffbcfefd9ca: _end+7ffbcf867752
0x7ffbcfc5a70d: _end+7ffbcf5c4495
sp = 0x7ffbc87b5040 {
fd = 14, id = 14, xid = 1363644113,
client = 87.238.35.17 59639,
step = STP_PREPRESP,
handling = error,
err_code = 200, err_reason = ok,
restarts = 0, esi_level = 0
flags =
bodystatus = 0
ws = 0x7ffbc87b51a8 {
id = "sess",
{s,f,r,e} = {0x7ffbc87b5c48,+456,(nil),+65536},
},
http[req] = {
ws = 0x7ffbc87b51a8[sess]
"GET",
"/fail",
"HTTP/1.1",
"Host: u.delta9.pl",
"User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101
Firefox/4.0.1",
"Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Accept-Language: en-us,en;q=0.5",
"Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7",
"Keep-Alive: 115",
"DNT: 1",
"Connection: keep-alive",
"fail: fail",
"Accept-Encoding: gzip",
},
worker = 0x7ffb40ce69d0 {
ws = 0x7ffb40ce6ca0 {
id = "wrk",
{s,f,r,e} = {0x7ffb40cd4920,+144,(nil),+65536},
},
http[resp] = {
ws = 0x7ffb40ce6ca0[wrk]
"HTTP/1.1",
"Service Unavailable",
"Server: Varnish",
"Content-Type: text/html; charset=utf-8",
"Retry-After: 5",
"Content-Length: 419",
"Accept-Ranges: bytes",
"Date: Wed, 05 Oct 2011 20:27:16 GMT",
"X-Varnish: 1363644113",
"Age: 0",
"Via: 1.1 varnish",
"Connection: close",
},
},
vcl = {
srcname = {
"input",
"Default",
},
},
obj = 0x7ffba6eff000 {
xid = 1363644113,
ws = 0x7ffba6eff018 {
id = "obj",
{s,f,r,e} = {0x7ffba6eff540,+176,(nil),+1024},
},
http[obj] = {
ws = 0x7ffba6eff018[obj]
"HTTP/1.1",
"Service Unavailable",
"Date: Wed, 05 Oct 2011 20:27:16 GMT",
"Server: Varnish",
"Content-Type: text/html; charset=utf-8",
"Retry-After: 5",
"Content-Length: 419",
},
len = 419,
store = {
419 {
0a 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 |.<?xml version="|
31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 75 |1.0" encoding="u|
74 66 2d 38 22 3f 3e 0a 3c 21 44 4f 43 54 59 50 |tf-8"?>.<!DOCTYP|
45 20 68 74 6d 6c 20 50 55 42 4c 49 43 20 22 2d |E html PUBLIC "-|
[355 more]
},
},
},
},


Child cleanup complete
child (23985) Started
Child (23985) said Child starts
Child (23985) said SMF.s0 mmap'ed 2147483648 bytes of 2147483648
}}}

--

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1027#comment:1>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs


varnish-bugs at varnish-cache

Oct 17, 2011, 5:43 AM

Post #3 of 8 (360 views)
Permalink
Re: #1027: signal 6 on calling error in vcl_deliver [In reply to]

#1027: signal 6 on calling error in vcl_deliver
-------------------+--------------------------------------------------------
Reporter: kwy | Type: defect
Status: new | Priority: normal
Milestone: | Component: varnishd
Version: trunk | Severity: normal
Keywords: |
-------------------+--------------------------------------------------------

Comment(by kristian):

Test case:

{{{

varnishtest "Test if you can error in vcl_deliver"

server s1 {
rxreq
txresp -status 200

rxreq
txresp -status 200
} -start

varnish v1 -vcl+backend {
sub vcl_deliver {
error 201 "ok";
}
} -start

client c1 {
txreq -req GET
rxresp
expect resp.status == 201

} -run
}}}

Comment:

So, hmm, there are two parts to this. One is that VCC and Varnish disagree
on where error is allowed (i.e: It should either work or give a VCL
compile error). The second part is that we don't have error in deliver....
Pretty sure we had it a short while ago.

Ah, yes, here we go.

714e0ef684edef8a370c10676e00fe8411894b91

https://www.varnish-
cache.org/trac/changeset/714e0ef684edef8a370c10676e00fe8411894b91

So that explains why you can't do it.

I'm removing this from the list of allowed VCL returns in deliver now, and
that turns this into a feature request of sorts. Though considering we had
error in vcl_deliver in the past, it might pass as a regression?

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1027#comment:2>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs


varnish-bugs at varnish-cache

Oct 17, 2011, 5:58 AM

Post #4 of 8 (359 views)
Permalink
Re: #1027: signal 6 on calling error in vcl_deliver [In reply to]

#1027: signal 6 on calling error in vcl_deliver
---------------------+------------------------------------------------------
Reporter: kwy | Type: defect
Status: closed | Priority: normal
Milestone: | Component: varnishd
Version: trunk | Severity: normal
Resolution: fixed | Keywords:
---------------------+------------------------------------------------------
Changes (by Kristian Lyngstol <kristian@…>):

* status: new => closed
* resolution: => fixed


Comment:

(In [e18a6ab53fbae30b633fbe5f040b5686bec6ea4d]) Formally remove error from
vcl_deliver VCC

Note that error wasn't actually working in vcl_deliver, and this just puts
VCC in line with the rest of Varnish. Syntax errors are better than assert
errors.

Re #1027

I'll leave it for later discussion to see if we close #1027, which is
technically a feature request now, though a request for a feature we used
to have (not sure how well it worked).

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1027#comment:3>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs


varnish-bugs at varnish-cache

Oct 17, 2011, 5:59 AM

Post #5 of 8 (355 views)
Permalink
Re: #1027: signal 6 on calling error in vcl_deliver [In reply to]

#1027: signal 6 on calling error in vcl_deliver
-----------------------+----------------------------------------------------
Reporter: kwy | Type: defect
Status: reopened | Priority: normal
Milestone: | Component: varnishd
Version: trunk | Severity: normal
Resolution: | Keywords:
-----------------------+----------------------------------------------------
Changes (by kristian):

* status: closed => reopened
* resolution: fixed =>


Comment:

GOD DARN IT. I actually /looked up the syntax for trac references/ and
then that @!#!@#...

So what I was saying was: oops.

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1027#comment:4>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs


varnish-bugs at varnish-cache

Nov 1, 2011, 4:03 AM

Post #6 of 8 (318 views)
Permalink
Re: #1027: signal 6 on calling error in vcl_deliver [In reply to]

#1027: signal 6 on calling error in vcl_deliver
-----------------------+----------------------------------------------------
Reporter: kwy | Type: defect
Status: reopened | Priority: normal
Milestone: | Component: varnishd
Version: trunk | Severity: normal
Resolution: | Keywords:
-----------------------+----------------------------------------------------

Comment(by kwy):

My take is that it should be possible to error out of anywhere. Seems to
me the problem is there is no response object to work on, which triggers
the panic in deliver.

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1027#comment:5>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs


varnish-bugs at varnish-cache

Nov 1, 2011, 7:36 AM

Post #7 of 8 (318 views)
Permalink
Re: #1027: signal 6 on calling error in vcl_deliver [In reply to]

#1027: signal 6 on calling error in vcl_deliver
-----------------------+----------------------------------------------------
Reporter: kwy | Type: defect
Status: reopened | Priority: normal
Milestone: | Component: varnishd
Version: trunk | Severity: normal
Resolution: | Keywords:
-----------------------+----------------------------------------------------

Comment(by kristian):

The reason it panics in deliver was because the VCL compiler thought you
could do error in vcl_deliver, and varnishd disagreed. It paniced on an
assert that checks for legal return values. error; was one of the few
states that weren't automatically synchronized between VCC and varnishd.

The reason it's not possible at the moment is because vcl_error goes
through vcl_deliver now. There's some work going on here which will
simplify this whole situation, but since that's the type of change best
suited for a major release (think removal of vcl_error more or less), the
question of what to do on the short term remains.

I do believe the conclusion from a bugwash was: It should be fixed short-
term too. Just a matter of sitting down and doing it.

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1027#comment:6>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs


varnish-bugs at varnish-cache

Apr 30, 2012, 3:35 AM

Post #8 of 8 (249 views)
Permalink
Re: #1027: signal 6 on calling error in vcl_deliver [In reply to]

#1027: signal 6 on calling error in vcl_deliver
-------------------------+--------------------------------------------------
Reporter: kwy | Type: defect
Status: closed | Priority: normal
Milestone: | Component: varnishd
Version: trunk | Severity: normal
Resolution: worksforme | Keywords:
-------------------------+--------------------------------------------------
Changes (by phk):

* status: reopened => closed
* resolution: => worksforme


Comment:

I'm closing this ticket with a timeout.

We're working in a different direction that this would take us, so I'd
rather avoid the detour.

The VCL compiler will error out now, and a possible workaround is
restart+error.

--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1027#comment:7>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

_______________________________________________
varnish-bugs mailing list
varnish-bugs [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs

Varnish bugs RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.