varnish-bugs at varnish-cache
Aug 30, 2011, 12:28 AM
Post #2 of 8
(372 views)
Permalink
|
|
Re: #994: Assert error in http_GetHdr(), cache_http.c
[In reply to]
|
|
#994: Assert error in http_GetHdr(), cache_http.c
---------------------+------------------------------------------------------
Reporter: pmialon | Type: defect
Status: new | Priority: normal
Milestone: | Component: varnishd
Version: trunk | Severity: blocker
Keywords: |
---------------------+------------------------------------------------------
Old description:
> From Git af353a6b6a45e2a47e17aa84389950a1c65854ec
>
> With the debian package varnish 3.0.0 this bug didn't appear, it seems
> that this is a regression.
>
> This bugs is hit frequently, on our servers varnish never reaches one
> hour of uptime.
>
> {{{
> Aug 29 14:24:34 cloud3 varnishd[3495]: Child (19452) Panic message:
> Assert error in http_GetHdr(), cache_http.c line 266:
> Condition(l == strlen(hdr + 1)) not true.
> thread = (cache-worker)
> ident = Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit,epoll
> Backtrace:
> 0x42e4c8: /usr/sbin/varnishd() [0x42e4c8]
> 0x429c08: /usr/sbin/varnishd(http_GetHdr+0x68) [0x429c08]
> 0x433c47: /usr/sbin/varnishd(VRY_Match+0xf7) [0x433c47]
> 0x427e86: /usr/sbin/varnishd(HSH_Lookup+0x2a6) [0x427e86]
> 0x415a3b: /usr/sbin/varnishd() [0x415a3b]
> 0x418fc5: /usr/sbin/varnishd(CNT_Session+0x675) [0x418fc5]
> 0x430c78: /usr/sbin/varnishd() [0x430c78]
> 0x42fe49: /usr/sbin/varnishd() [0x42fe49]
> 0x7ffff6ab48ba: /lib/libpthread.so.0(+0x68ba) [0x7ffff6ab48ba]
> 0x7ffff681c02d: /lib/libc.so.6(clone+0x6d) [0x7ffff681c02d]
> sp = 0x7ec790b21008 {
> fd = 53, id = 53, xid = 2071385764,
> client = 127.0.0.1 11364,
> step = STP_LOOKUP,
> handling = hash,
> restarts = 0, esi_level = 0
> flags =
> bodystatus = 4
> ws = 0x7ec790b21080 {
> id = "sess",
> {s,f,r,e} = {0x7ec790b21cc8,+3344,+65536,+65536},
> },
> http[req] = {
> ws = 0x7ec790b21080[sess]
> "GET",
> "/searchkw/xml/?_q%5B0%5D=%28suzuki%7Bw%3D1%7D+115%7Bw%3D1%7D%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D4&_q%5B1%5D=%28suzuki%7Bw%3D1%7D%29+OPT%28115%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D3&_q%5B2%5D=OPT%28suzuki+OR+115%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D3&_q%5B3%5D=OPT%28suzuki+OR+115%29+-category%3Aall+country%3AES+%28category%3Amiscellaneous%29+querywords%3E%3D2&_vn%5B0%5D=defaultkw_new&_vn%5B1%5D=defaultkw_new&_vn%5B2%5D=defaultkw_new&_vn%5B3%5D=seo_keywords_round_new&_cc%5B0%5D=IT&_cc%5B1%5D=IT&_cc%5B2%5D=IT&_cc%5B3%5D=ES&_comp=gzip&_fmt=JSON&_hashq%5B1%5D=1&_hashq%5B2%5D=1&_hashq%5B3%5D=1&_hstart%5B2%5D=1",
> "HTTP/1.1",
> "Connection: Close",
> "X-URL:
> /searchkw/xml/?_q%5B0%5D=%28suzuki%7Bw%3D1%7D+115%7Bw%3D1%7D%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D4&_q%5B1%5D=%28suzuki%7Bw%3D1%7D%29+OPT%28115%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D3&_q%5B2%5D=OPT%28suzuki+OR+115%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D3&_q%5B3%5D=OPT%28suzuki+OR+115%29+-category%3Aall+country%3AES+%28category%3Amiscellaneous%29+querywords%3E%3D2&_vn%5B0%5D=defaultkw_new&_vn%5B1%5D=defaultkw_new&_vn%5B2%5D=defaultkw_new&_vn%5B3%5D=seo_keywords_round_new&_cc%5B0%5D=IT&_cc%5B1%5D=IT&_cc%5B2%5D=IT&_cc%5B3%5D=ES&_comp=gzip&_fmt=JSON&_hashq%5B1%5D=1&_hashq%5B2%5D=1&_hashq%5B3%5D=1&_hstart%5B2%5D=1&ttls=672",
> },
> worker = 0x7ec7616f8b90 {
> ws = 0x7ec7616f8d38 {
> id = "wrk",
> {s,f,r,e} = {0x7ec7616e6b20,0x7ec7616e6b20,(nil),+65536},
> },
> },
> vcl = {
> srcname = {
> "input",
> "Default",
> },
> },
> },
>
> }}}
New description:
From Git af353a6b6a45e2a47e17aa84389950a1c65854ec
With the debian package varnish 3.0.0 this bug didn't appear, it seems
that this is a regression.
This bugs is hit frequently, on our servers varnish never reaches one hour
of uptime.
{{{
Aug 29 14:24:34 cloud3 varnishd[3495]: Child (19452)
Panic message:
Assert error in http_GetHdr(), cache_http.c line 266:
Condition(l == strlen(hdr + 1)) not true.
thread = (cache-worker)
ident = Linux,2.6.32-5-amd64,x86_64,-sfile,-smalloc,-hcritbit,epoll
Backtrace:
0x42e4c8: /usr/sbin/varnishd() [0x42e4c8]
0x429c08: /usr/sbin/varnishd(http_GetHdr+0x68) [0x429c08]
0x433c47: /usr/sbin/varnishd(VRY_Match+0xf7) [0x433c47]
0x427e86: /usr/sbin/varnishd(HSH_Lookup+0x2a6) [0x427e86]
0x415a3b: /usr/sbin/varnishd() [0x415a3b]
0x418fc5: /usr/sbin/varnishd(CNT_Session+0x675) [0x418fc5]
0x430c78: /usr/sbin/varnishd() [0x430c78]
0x42fe49: /usr/sbin/varnishd() [0x42fe49]
0x7ffff6ab48ba: /lib/libpthread.so.0(+0x68ba) [0x7ffff6ab48ba]
0x7ffff681c02d: /lib/libc.so.6(clone+0x6d) [0x7ffff681c02d]
sp = 0x7ec790b21008 {
fd = 53, id = 53, xid = 2071385764,
client = 127.0.0.1 11364,
step = STP_LOOKUP,
handling = hash,
restarts = 0, esi_level = 0
flags =
bodystatus = 4
ws = 0x7ec790b21080 {
id = "sess",
{s,f,r,e} = {0x7ec790b21cc8,+3344,+65536,+65536},
},
http[req] = {
ws = 0x7ec790b21080[sess]
"GET",
"/searchkw/xml/?_q%5B0%5D=%28suzuki%7Bw%3D1%7D+115%7Bw%3D1%7D%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D4&_q%5B1%5D=%28suzuki%7Bw%3D1%7D%29+OPT%28115%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D3&_q%5B2%5D=OPT%28suzuki+OR+115%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D3&_q%5B3%5D=OPT%28suzuki+OR+115%29+-category%3Aall+country%3AES+%28category%3Amiscellaneous%29+querywords%3E%3D2&_vn%5B0%5D=defaultkw_new&_vn%5B1%5D=defaultkw_new&_vn%5B2%5D=defaultkw_new&_vn%5B3%5D=seo_keywords_round_new&_cc%5B0%5D=IT&_cc%5B1%5D=IT&_cc%5B2%5D=IT&_cc%5B3%5D=ES&_comp=gzip&_fmt=JSON&_hashq%5B1%5D=1&_hashq%5B2%5D=1&_hashq%5B3%5D=1&_hstart%5B2%5D=1",
"HTTP/1.1",
"Connection: Close",
"X-URL:
/searchkw/xml/?_q%5B0%5D=%28suzuki%7Bw%3D1%7D+115%7Bw%3D1%7D%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D4&_q%5B1%5D=%28suzuki%7Bw%3D1%7D%29+OPT%28115%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D3&_q%5B2%5D=OPT%28suzuki+OR+115%29+-category%3Aall+country%3AIT+%28category%3Amiscellaneous%29+querywords%3E%3D2+querywords%3C%3D3&_q%5B3%5D=OPT%28suzuki+OR+115%29+-category%3Aall+country%3AES+%28category%3Amiscellaneous%29+querywords%3E%3D2&_vn%5B0%5D=defaultkw_new&_vn%5B1%5D=defaultkw_new&_vn%5B2%5D=defaultkw_new&_vn%5B3%5D=seo_keywords_round_new&_cc%5B0%5D=IT&_cc%5B1%5D=IT&_cc%5B2%5D=IT&_cc%5B3%5D=ES&_comp=gzip&_fmt=JSON&_hashq%5B1%5D=1&_hashq%5B2%5D=1&_hashq%5B3%5D=1&_hstart%5B2%5D=1&ttls=672",
},
worker = 0x7ec7616f8b90 {
ws = 0x7ec7616f8d38 {
id = "wrk",
{s,f,r,e} = {0x7ec7616e6b20,0x7ec7616e6b20,(nil),+65536},
},
},
vcl = {
srcname = {
"input",
"Default",
},
},
},
}}}
--
Comment(by phk):
I would be very interested in knowing what the Vary: header it was
processing looked like.
You can either find this in varnishlog, if you can identify the object it
is trying to match in the hash, or if the crash results in a core dump, it
can be extracted from there.
Alternatively, if you can simply get me the argument passed to
http_GetHdr() from the coredump that would help too.
--
Ticket URL: <http://www.varnish-cache.org/trac/ticket/994#comment:1>
Varnish <http://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
|
