trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyangtack Lee <hyangt...@gmail.com>
Subject Re: crash on HttpTunnel::chain_abort_all when receiving a range request
Date Fri, 19 Apr 2013 08:37:33 GMT
Thank you for reply.

> This looks like the crash reported in
https://issues.apache.org/jira/browse/TS-1756. Are you able to attach a
specific HTTP request (or curl command line) that can reproduce this crash?

I have 5 clustered ATS. They are on the same subnet and clustered by
ip-multicast.
ATS is configured as forwarding proxy and range lookup is enabled.

CONFIG proxy.config.http.cache.range.lookup INT 1

The following is cache-size-related parameters.

CONFIG proxy.config.cache.ram_cache.size INT 12884901888
CONFIG proxy.config.cache.ram_cache_cutoff INT 104857600
CONFIG proxy.config.cache.max_doc_size INT 0

The reproduce step is as follows:
1. send HTTP GET to ATS for some resource without range header.
2. send HTTP GET to ATS for some resource without range header again for
checking the resource was cached. (TCP_HIT on ATS log)
  The resource might be stored in memory because its size is smaller than
cutoff config(about 170KB).
3. send HTTP GET to ATS for the same resource again, with range header. (I
asked just 10 bytes)
 Range: bytes=1-10
4. After that, ATS generates core file.
  Somtimes, ATS responds with wrong http headers like below. (strange
content-type, wrong content-length, and no content-range)
HTTP/1.1 206 Partial Content\r\n
Etag: "1366196912453"
Date: Fri, 19 Apr 2013 08:27:08 GMT
Content-Type: multipart/byteranges; boundary=RANGE_SEPARATOR
Content-Length: 175712
Age: 18
Connection: close
Server: ATS/3.2.4

I've tried the above scenario on ATS 3.0.5 with the same configurations,
but there's no core generated and no problem.


On 19 April 2013 01:17, James Peach <jpeach@apache.org> wrote:

> On Apr 17, 2013, at 10:21 PM, Hyangtack Lee <hyangtack@gmail.com> wrote:
>
> > Hi All,
> >
> > I'm testing ATS 3.2.4 on centos 5.7 x86_64.
> > I got a core file when I sent a range request(using HTTP Range header)
> to ATS. It is always reproduced.
>
> This looks like the crash reported in
> https://issues.apache.org/jira/browse/TS-1756. Are you able to attach a
> specific HTTP request (or curl command line) that can reproduce this crash?
>
> > Is this a known issue? Cannot ATS support a range request?
>
> Range requests are supported. I can't tell from the stack trace whether
> this is related to range requests or not.
>
> >
> > Thanks in advance.
> >
> > backtrace is as follows:
> > (gdb) bt
> > #0  HttpTunnel::chain_abort_all (this=0x2aaaafafb1c0, p=0x2aaaafafb3b8)
> at HttpTunnel.cc:1306
> > #1  0x0000000000571722 in HttpTunnel::kill_tunnel (this=0x3b19ff0) at
> HttpTunnel.cc:490
> > #2  0x000000000052892a in HttpSM::state_watch_for_client_abort
> (this=0x2aaaafaf9650, event=104, data=<value optimized out>)
> >     at HttpSM.cc:876
> > #3  0x0000000000530a5c in HttpSM::main_handler (this=0x2aaaafaf9650,
> event=104, data=0x2aaad403d5d8) at HttpSM.cc:2447
> > #4  0x0000000000694897 in read_from_net (nh=0x2aaaaafe51e8,
> vc=0x2aaad403d4d0, thread=<value optimized out>)
> >     at ../../iocore/eventsystem/I_Continuation.h:146
> > #5  0x0000000000689ed9 in NetHandler::mainNetEvent (this=0x2aaaaafe51e8,
> event=<value optimized out>, e=0x2aaaac37701c)
> >     at UnixNet.cc:372
> > #6  0x00000000006b993f in EThread::process_event (this=0x2aaaaafe2010,
> e=0x3b91330, calling_code=5) at I_Continuation.h:146
> > #7  0x00000000006ba24c in EThread::execute (this=0x2aaaaafe2010) at
> UnixEThread.cc:264
> > #8  0x00000000006b8d8e in spawn_thread_internal (a=0x3b8a3b0) at
> Thread.cc:88
> > #9  0x0000003fe760677d in start_thread () from /lib64/libpthread.so.0
> > #10 0x0000003fe6ed49ad in clone () from /lib64/libc.so.6
> > (gdb) p *p
> > $2 = {consumer_list = {head = 0x2aaaafafb1f8}, self_consumer = 0x0, vc =
> 0x4877bd0, vc_handler = (int (HttpSM::*)(HttpSM *, int,
> >     HttpTunnelProducer *)) 0x525e10
> <HttpSM::tunnel_handler_cache_read(int, HttpTunnelProducer*)>, read_vio =
> 0x0,
> >   read_buffer = 0x2aaab14cd810, buffer_start = 0x0, vc_type =
> HT_CACHE_READ, chunked_handler = {chunked_reader = 0x0,
> >     dechunked_buffer = 0x0, dechunked_size = 0, dechunked_reader = 0x0,
> chunked_buffer = 0x0, chunked_size = 0,
> >     truncation = false, skip_bytes = 0, state = CHUNK_READ_CHUNK,
> cur_chunk_size = 0, bytes_left = 0, last_server_event = 0,
> >     running_sum = 0, num_digits = 0}, chunking_action =
> TCA_PASSTHRU_DECHUNKED_CONTENT, do_chunking = false,
> >   do_dechunking = false, do_chunked_passthru = false, init_bytes_done =
> 0, nbytes = 175712, ntodo = 175712, bytes_read = 0,
> >   handler_state = 0, num_consumers = 1, alive = false, read_success =
> false, name = 0x6dda6e "cache read"}
> > (gdb) p p->read_vio
> > $3 = (VIO *) 0x0
>
>

Mime
View raw message