[Varnish] #1007: Varnish crashing (Assert error in res_dorange(), cache_response.c line 99)
Varnish
varnish-bugs at varnish-cache.org
Tue Sep 6 10:02:37 CEST 2011
#1007: Varnish crashing (Assert error in res_dorange(), cache_response.c line 99)
-----------------------+----------------------------------------------------
Reporter: tonyflint | Type: defect
Status: new | Priority: normal
Milestone: | Component: varnishd
Version: 3.0.1 | Severity: major
Keywords: |
-----------------------+----------------------------------------------------
Description changed by phk:
Old description:
> Varnish version: 3.0.1 (3.0.1-1~lucid1)
> Architecture: x86_64
> RAM: 12G
> OS/Kernel: Ubuntu 10.04.1/2.6.27.21-0.1-xen
> VCL: Customized, attached (IPs obfuscated)
>
> Varnish is crashing when given a simple request that includes both Range:
> and Accept-Encoding: headers.
>
> The simplest request I've found so far that causes this is:
>
> curl -H "Range: bytes=0-40960" -H "Accept-Encoding: gzip" localhost -o
> /dev/null
>
> I'm starting varnish through init with the following DAEMON_OPTS:
> -a :80 \
> -T localhost:2000 \
> -f /etc/varnish/default_varnish_3.0.vcl \
> -S /etc/varnish/secret \
> -s malloc,11G \
> -p thread_pool_min=100 \
> -p thread_pools=4 \
> -p thread_pool_add_delay=2"
>
> The syslog panic messages are as follows:
>
> Sep 2 13:47:30 localhost varnishd[10752]: Platform:
> Linux,2.6.27.21-0.1-xen,x86_64,-smalloc,-smalloc,-hcritbit
> Sep 2 13:47:32 localhost varnishd[10752]: CLI debug Rd start
> Sep 2 13:47:32 localhost varnishd[10752]: child (10779) Started
> Sep 2 13:47:32 localhost varnishd[10752]: CLI debug Wr 200
> Sep 2 13:47:32 localhost varnishd[10752]: Child (10779) said Child
> starts
> Sep 2 13:47:57 localhost varnishd[10752]: Child (10779) died signal=6
> Sep 2 13:47:57 localhost varnishd[10752]: Child (10779) Panic message:
> Assert error in res_dorange(), cache_response.c line 99:#012
> Condition(sp->wrk->res_mode & RES_LEN) not true.#012thread = (cache-
> worker)#012ident =
> Linux,2.6.27.21-0.1-xen,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012
> 0x42ea38: /usr/sbin/varnishd() [0x42ea38]#012 0x4320ad:
> /usr/sbin/varnishd(RES_WriteObj+0x6bd) [0x4320ad]#012 0x416d5b:
> /usr/sbin/varnishd() [0x416d5b]#012 0x4190cd:
> /usr/sbin/varnishd(CNT_Session+0x55d) [0x4190cd]#012 0x430398:
> /usr/sbin/varnishd() [0x430398]#012 0x430821: /usr/sbin/varnishd()
> [0x430821]#012 0x7fe4a473a9ca: /lib/libpthread.so.0(+0x69ca)
> [0x7fe4a473a9ca]#012 0x7fe4a449770d: /lib/libc.so.6(clone+0x6d)
> [0x7fe4a449770d]#012sp = 0x7fe499738008 {#012 fd = 3, id = 3, xid =
> 887019497,#012 client = 127.0.0.1 49463,#012 step = STP_DELIVER,#012
> handling = deliver,#012 err_code = 200, err_reason = (null),#012
> restarts = 0, esi_level = 0#012 flags = do_gzip do_esi is_gunzip#012
> bodystatus = 4#012 ws = 0x7fe499738080 { #012 id = "sess",#012
> {s,f,r,e} = {0x7fe499738cc8,+544,(nil),+65536},#012 },#012 http[req] =
> {#012 ws = 0x7fe499738080[sess]#012 "GET",#012 "/",#012
> "HTTP/1.1",#012 "User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu)
> libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15",#012 "Host:
> localhost",#012 "Accept: */*",#012 "Range: bytes=0-40960",#012
> "app_request: true",#012 "esi_compatible: true",#012
> "mobileDelivery: no",#012 "saveMobileOption: ",#012 "wpCookie:
> ",#012 "mobileOverride: false",#012 "mobileDevice: false",#012
> "saveABgroup: true",#012 "X-ABGROUP: B",#012 "X-Forwarded-For:
> 127.0.0.1",#012 "Accept-Encoding: gzip",#012 },#012 worker =
> 0x7fe42ee29b60 {#012 ws = 0x7fe42ee29d08 { #012 id = "wrk",#012
> {s,f,r,e} = {0x7fe42ee17af0,+2064,(nil),+65536},#012 },#012
> http[resp] = {#012 ws = 0x7fe42ee29d08[wrk]#012
> "HTTP/1.1",#012 "OK",#012 "Cache
> Sep 2 13:47:57 localhost varnishd[10752]: Child cleanup complete
>
> Attachments:
>
> varnish_debug_output.txt -- screen log of running varnishd in debug mode
> and causing the crash
> varnishlog_crash_request -- varnishlog of request/crash sequence
> running_vcl -- VCL running when this crash occurs
>
> I have not attached the coredump; it is 3.3G. If it's needed I can upload
> it to S3 or some other convenient place.
New description:
Varnish version: 3.0.1 (3.0.1-1~lucid1)
Architecture: x86_64
RAM: 12G
OS/Kernel: Ubuntu 10.04.1/2.6.27.21-0.1-xen
VCL: Customized, attached (IPs obfuscated)
Varnish is crashing when given a simple request that includes both Range:
and Accept-Encoding: headers.
The simplest request I've found so far that causes this is:
curl -H "Range: bytes=0-40960" -H "Accept-Encoding: gzip" localhost -o
/dev/null
{{{
I'm starting varnish through init with the following DAEMON_OPTS:
-a :80 \
-T localhost:2000 \
-f /etc/varnish/default_varnish_3.0.vcl \
-S /etc/varnish/secret \
-s malloc,11G \
-p thread_pool_min=100 \
-p thread_pools=4 \
-p thread_pool_add_delay=2"
The syslog panic messages are as follows:
Sep 2 13:47:30 localhost varnishd[10752]: Platform:
Linux,2.6.27.21-0.1-xen,x86_64,-smalloc,-smalloc,-hcritbit
Sep 2 13:47:32 localhost varnishd[10752]: CLI debug Rd start
Sep 2 13:47:32 localhost varnishd[10752]: child (10779) Started
Sep 2 13:47:32 localhost varnishd[10752]: CLI debug Wr 200
Sep 2 13:47:32 localhost varnishd[10752]: Child (10779) said Child starts
Sep 2 13:47:57 localhost varnishd[10752]: Child (10779) died signal=6
Sep 2 13:47:57 localhost varnishd[10752]: Child (10779) Panic message:
Assert error in res_dorange(),
cache_response.c line 99:
Condition(sp->wrk->res_mode & RES_LEN) not true.
thread = (cache-worker)
ident = Linux,2.6.27.21-0.1-xen,x86_64,-smalloc,-smalloc,-hcritbit,epoll
Backtrace:
0x42ea38: /usr/sbin/varnishd() [0x42ea38]
0x4320ad: /usr/sbin/varnishd(RES_WriteObj+0x6bd) [0x4320ad]
0x416d5b: /usr/sbin/varnishd() [0x416d5b]
0x4190cd: /usr/sbin/varnishd(CNT_Session+0x55d) [0x4190cd]
0x430398: /usr/sbin/varnishd() [0x430398]
0x430821: /usr/sbin/varnishd() [0x430821]
0x7fe4a473a9ca: /lib/libpthread.so.0(+0x69ca) [0x7fe4a473a9ca]
0x7fe4a449770d: /lib/libc.so.6(clone+0x6d) [0x7fe4a449770d]
sp = 0x7fe499738008 {
fd = 3, id = 3, xid = 887019497,
client = 127.0.0.1 49463,
step = STP_DELIVER,
handling = deliver,
err_code = 200, err_reason = (null),
restarts = 0, esi_level = 0
flags = do_gzip do_esi is_gunzip
bodystatus = 4
ws = 0x7fe499738080 {
id = "sess",
{s,f,r,e} = {0x7fe499738cc8,+544,(nil),+65536},
},
http[req] = {
ws = 0x7fe499738080[sess]
"GET",
"/",
"HTTP/1.1",
"User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7
OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15",
"Host: localhost",
"Accept: */*",
"Range: bytes=0-40960",
"app_request: true",
"esi_compatible: true",
"mobileDelivery: no",
"saveMobileOption: ",
"wpCookie: ",
"mobileOverride: false",
"mobileDevice: false",
"saveABgroup: true",
"X-ABGROUP: B",
"X-Forwarded-For: 127.0.0.1",
"Accept-Encoding: gzip",
},
worker = 0x7fe42ee29b60 {
ws = 0x7fe42ee29d08 {
id = "wrk",
{s,f,r,e} = {0x7fe42ee17af0,+2064,(nil),+65536},
},
http[resp] = {
ws = 0x7fe42ee29d08[wrk]
"HTTP/1.1",
"OK",
"Cache
Sep 2 13:47:57 localhost varnishd[10752]: Child cleanup complete
}}}
Attachments:
varnish_debug_output.txt -- screen log of running varnishd in debug mode
and causing the crash
varnishlog_crash_request -- varnishlog of request/crash sequence
running_vcl -- VCL running when this crash occurs
I have not attached the coredump; it is 3.3G. If it's needed I can upload
it to S3 or some other convenient place.
--
--
Ticket URL: <http://www.varnish-cache.org/trac/ticket/1007#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator
More information about the varnish-bugs
mailing list