[jira] [Created] (TS-2877) http_load wait timeout when response body is zero

2014-06-05 Thread Masaori Koshiba (JIRA) 
Masaori Koshiba created TS-2877:
---

 Summary: http_load wait timeout when response body is zero
 Key: TS-2877
 URL: https://issues.apache.org/jira/browse/TS-2877
 Project: Traffic Server
  Issue Type: Bug
  Components: Tools
Reporter: Masaori Koshiba


It look like http_load wait until timeout when a keep-alive enabled server 
returns empty body. 

I build http_load from master branch (commit 
90ff1a79015a73d7906170f05c3d36fd3127e7d1)

For example, setup a keep-alive enabled Apache and a url which return empty 
body. 

h3. Apache settings
{noformat}
KeepAlive on
KeepAliveTimeout 10
{noformat}

h3. Request by curl
curl get response in 0.02 seconds.
{noformat}
$ time curl -vs http://localhost/empty
* About to connect() to localhost port 80 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /empty HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 
> zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: localhost
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 05 Jun 2014 06:56:23 GMT
< Last-Modified: Wed, 04 Jun 2014 10:20:15 GMT
< Accept-Ranges: bytes
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host localhost left intact
* Closing connection #0
curl -vs http://localhost/empty  0.02s user 0.00s system 87% cpu 0.030 total
{noformat}

h3. Request by http_load
http_load wait 10 seconds.
{noformat}
$ cat url.txt
http://localhost/empty
$ ./http_load/http_load.master -verbose -parallel 1 -fetches 1 -keep_alive 1 
./url.txt
1 fetches on 1 conns, 1 max parallel, 0 bytes, in 10.0114 seconds
0 mean bytes/fetch
0.0998858 fetches/sec, 0 bytes/sec
msecs/connect: 0.112 mean, 0.112 max, 0.112 min
msecs/first-response: 0.7 mean, 0.7 max, 0.7 min
HTTP response codes:
  code 200 -- 1
Socket slot stats:
  slot  -- 1 connections, 1 requests, 1 responses
{noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2877) http_load wait timeout when response body is zero

2014-06-05 Thread Masaori Koshiba (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Masaori Koshiba updated TS-2877:


Attachment: http_load.patch

A patch to close the connection when content_lenght is zero.

> http_load wait timeout when response body is zero
> -
>
> Key: TS-2877
> URL: https://issues.apache.org/jira/browse/TS-2877
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tools
>Reporter: Masaori Koshiba
> Attachments: http_load.patch
>
>
> It look like http_load wait until timeout when a keep-alive enabled server 
> returns empty body. 
> I build http_load from master branch (commit 
> 90ff1a79015a73d7906170f05c3d36fd3127e7d1)
> For example, setup a keep-alive enabled Apache and a url which return empty 
> body. 
> h3. Apache settings
> {noformat}
> KeepAlive on
> KeepAliveTimeout 10
> {noformat}
> h3. Request by curl
> curl get response in 0.02 seconds.
> {noformat}
> $ time curl -vs http://localhost/empty
> * About to connect() to localhost port 80 (#0)
> *   Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 80 (#0)
> > GET /empty HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 
> > NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: localhost
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Date: Thu, 05 Jun 2014 06:56:23 GMT
> < Last-Modified: Wed, 04 Jun 2014 10:20:15 GMT
> < Accept-Ranges: bytes
> < Content-Length: 0
> < Content-Type: text/plain; charset=utf-8
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
> curl -vs http://localhost/empty  0.02s user 0.00s system 87% cpu 0.030 total
> {noformat}
> h3. Request by http_load
> http_load wait 10 seconds.
> {noformat}
> $ cat url.txt
> http://localhost/empty
> $ ./http_load/http_load.master -verbose -parallel 1 -fetches 1 -keep_alive 1 
> ./url.txt
> 1 fetches on 1 conns, 1 max parallel, 0 bytes, in 10.0114 seconds
> 0 mean bytes/fetch
> 0.0998858 fetches/sec, 0 bytes/sec
> msecs/connect: 0.112 mean, 0.112 max, 0.112 min
> msecs/first-response: 0.7 mean, 0.7 max, 0.7 min
> HTTP response codes:
>   code 200 -- 1
> Socket slot stats:
>   slot  -- 1 connections, 1 requests, 1 responses
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2877) http_load wait untill timeout when response body is zero

2014-06-05 Thread Masaori Koshiba (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Masaori Koshiba updated TS-2877:


Summary: http_load wait untill timeout when response body is zero  (was: 
http_load wait timeout when response body is zero)

> http_load wait untill timeout when response body is zero
> 
>
> Key: TS-2877
> URL: https://issues.apache.org/jira/browse/TS-2877
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tools
>Reporter: Masaori Koshiba
> Attachments: http_load.patch
>
>
> It look like http_load wait until timeout when a keep-alive enabled server 
> returns empty body. 
> I build http_load from master branch (commit 
> 90ff1a79015a73d7906170f05c3d36fd3127e7d1)
> For example, setup a keep-alive enabled Apache and a url which return empty 
> body. 
> h3. Apache settings
> {noformat}
> KeepAlive on
> KeepAliveTimeout 10
> {noformat}
> h3. Request by curl
> curl get response in 0.02 seconds.
> {noformat}
> $ time curl -vs http://localhost/empty
> * About to connect() to localhost port 80 (#0)
> *   Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 80 (#0)
> > GET /empty HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 
> > NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: localhost
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Date: Thu, 05 Jun 2014 06:56:23 GMT
> < Last-Modified: Wed, 04 Jun 2014 10:20:15 GMT
> < Accept-Ranges: bytes
> < Content-Length: 0
> < Content-Type: text/plain; charset=utf-8
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
> curl -vs http://localhost/empty  0.02s user 0.00s system 87% cpu 0.030 total
> {noformat}
> h3. Request by http_load
> http_load wait 10 seconds.
> {noformat}
> $ cat url.txt
> http://localhost/empty
> $ ./http_load/http_load.master -verbose -parallel 1 -fetches 1 -keep_alive 1 
> ./url.txt
> 1 fetches on 1 conns, 1 max parallel, 0 bytes, in 10.0114 seconds
> 0 mean bytes/fetch
> 0.0998858 fetches/sec, 0 bytes/sec
> msecs/connect: 0.112 mean, 0.112 max, 0.112 min
> msecs/first-response: 0.7 mean, 0.7 max, 0.7 min
> HTTP response codes:
>   code 200 -- 1
> Socket slot stats:
>   slot  -- 1 connections, 1 requests, 1 responses
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2236) fabricate_with_old_api adds zero byte at the end of the response body

2014-06-05 Thread Thach Tran (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thach Tran updated TS-2236:
---

Attachment: TS-2236.patch

I'm seeing this too whenever a remap plugin set an error response body using 
TSHttpTxnErrorBodySet.

I think the bug is simply failed to realise that ink_bvsprintf will return 
resulting len including the final null.

> fabricate_with_old_api adds zero byte at the end of the response body
> -
>
> Key: TS-2236
> URL: https://issues.apache.org/jira/browse/TS-2236
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: portl4t
>Assignee: portl4t
> Fix For: sometime
>
> Attachments: TS-2236.patch
>
>
> When ts decides to response error to ua, fabricate_with_old_api(...) will be 
> called, and sometimes internal_msg_buffer_size will be set as 
> strlen(internal_msg_buffer) + 1, including the last zero byte, so the client 
> will receive a response which has a zero byte at the end of the body, should 
> we remove the last zero byte?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2877) http_load wait untill timeout when response body is zero

2014-06-05 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14018971#comment-14018971
 ] 

ASF subversion and git services commented on TS-2877:
-

Commit e564ec9b9c4b6442c7a64ed67003b6f1d69e74a5 in trafficserver's branch 
refs/heads/master from [~masaori]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e564ec9 ]

TS-2877: http_load waits until timeout when response body is zero


> http_load wait untill timeout when response body is zero
> 
>
> Key: TS-2877
> URL: https://issues.apache.org/jira/browse/TS-2877
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tools
>Reporter: Masaori Koshiba
> Fix For: 5.1.0
>
> Attachments: http_load.patch
>
>
> It look like http_load wait until timeout when a keep-alive enabled server 
> returns empty body. 
> I build http_load from master branch (commit 
> 90ff1a79015a73d7906170f05c3d36fd3127e7d1)
> For example, setup a keep-alive enabled Apache and a url which return empty 
> body. 
> h3. Apache settings
> {noformat}
> KeepAlive on
> KeepAliveTimeout 10
> {noformat}
> h3. Request by curl
> curl get response in 0.02 seconds.
> {noformat}
> $ time curl -vs http://localhost/empty
> * About to connect() to localhost port 80 (#0)
> *   Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 80 (#0)
> > GET /empty HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 
> > NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: localhost
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Date: Thu, 05 Jun 2014 06:56:23 GMT
> < Last-Modified: Wed, 04 Jun 2014 10:20:15 GMT
> < Accept-Ranges: bytes
> < Content-Length: 0
> < Content-Type: text/plain; charset=utf-8
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
> curl -vs http://localhost/empty  0.02s user 0.00s system 87% cpu 0.030 total
> {noformat}
> h3. Request by http_load
> http_load wait 10 seconds.
> {noformat}
> $ cat url.txt
> http://localhost/empty
> $ ./http_load/http_load.master -verbose -parallel 1 -fetches 1 -keep_alive 1 
> ./url.txt
> 1 fetches on 1 conns, 1 max parallel, 0 bytes, in 10.0114 seconds
> 0 mean bytes/fetch
> 0.0998858 fetches/sec, 0 bytes/sec
> msecs/connect: 0.112 mean, 0.112 max, 0.112 min
> msecs/first-response: 0.7 mean, 0.7 max, 0.7 min
> HTTP response codes:
>   code 200 -- 1
> Socket slot stats:
>   slot  -- 1 connections, 1 requests, 1 responses
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TS-2877) http_load wait untill timeout when response body is zero

2014-06-05 Thread James Peach (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach resolved TS-2877.
-

   Resolution: Fixed
Fix Version/s: 5.1.0
 Assignee: James Peach

Thanks for the patch!

> http_load wait untill timeout when response body is zero
> 
>
> Key: TS-2877
> URL: https://issues.apache.org/jira/browse/TS-2877
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tools
>Reporter: Masaori Koshiba
>Assignee: James Peach
> Fix For: 5.1.0
>
> Attachments: http_load.patch
>
>
> It look like http_load wait until timeout when a keep-alive enabled server 
> returns empty body. 
> I build http_load from master branch (commit 
> 90ff1a79015a73d7906170f05c3d36fd3127e7d1)
> For example, setup a keep-alive enabled Apache and a url which return empty 
> body. 
> h3. Apache settings
> {noformat}
> KeepAlive on
> KeepAliveTimeout 10
> {noformat}
> h3. Request by curl
> curl get response in 0.02 seconds.
> {noformat}
> $ time curl -vs http://localhost/empty
> * About to connect() to localhost port 80 (#0)
> *   Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 80 (#0)
> > GET /empty HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 
> > NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: localhost
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Date: Thu, 05 Jun 2014 06:56:23 GMT
> < Last-Modified: Wed, 04 Jun 2014 10:20:15 GMT
> < Accept-Ranges: bytes
> < Content-Length: 0
> < Content-Type: text/plain; charset=utf-8
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
> curl -vs http://localhost/empty  0.02s user 0.00s system 87% cpu 0.030 total
> {noformat}
> h3. Request by http_load
> http_load wait 10 seconds.
> {noformat}
> $ cat url.txt
> http://localhost/empty
> $ ./http_load/http_load.master -verbose -parallel 1 -fetches 1 -keep_alive 1 
> ./url.txt
> 1 fetches on 1 conns, 1 max parallel, 0 bytes, in 10.0114 seconds
> 0 mean bytes/fetch
> 0.0998858 fetches/sec, 0 bytes/sec
> msecs/connect: 0.112 mean, 0.112 max, 0.112 min
> msecs/first-response: 0.7 mean, 0.7 max, 0.7 min
> HTTP response codes:
>   code 200 -- 1
> Socket slot stats:
>   slot  -- 1 connections, 1 requests, 1 responses
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2236) fabricate_with_old_api adds zero byte at the end of the response body

2014-06-05 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14018992#comment-14018992
 ] 

ASF subversion and git services commented on TS-2236:
-

Commit 1b57f42af928f76da298c97ea24a2b50dab58bc3 in trafficserver's branch 
refs/heads/master from [~thachtran]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1b57f42 ]

TS-2236: remove trailing null in response body set by fabricate_with_old_api

I'm seeing this too whenever a remap plugin set an error response
body using TSHttpTxnErrorBodySet.  I think the bug is simply failed
to realise that ink_bvsprintf will return resulting len including
the final null.


> fabricate_with_old_api adds zero byte at the end of the response body
> -
>
> Key: TS-2236
> URL: https://issues.apache.org/jira/browse/TS-2236
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: portl4t
>Assignee: portl4t
> Fix For: sometime
>
> Attachments: TS-2236.patch
>
>
> When ts decides to response error to ua, fabricate_with_old_api(...) will be 
> called, and sometimes internal_msg_buffer_size will be set as 
> strlen(internal_msg_buffer) + 1, including the last zero byte, so the client 
> will receive a response which has a zero byte at the end of the body, should 
> we remove the last zero byte?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TS-2878) Core dump in mime_field_print

2014-06-05 Thread Sudheer Vinukonda (JIRA) 
Sudheer Vinukonda created TS-2878:
-

 Summary: Core dump in mime_field_print
 Key: TS-2878
 URL: https://issues.apache.org/jira/browse/TS-2878
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Sudheer Vinukonda


Found a new core dump on one of our production hosts with the latest master.

{code}
(gdb) 
#0  0x00366a489932 in memcpy () from /lib64/libc.so.6
#1  0x006440ec in mime_field_print (field=0x2ad0c12eb398, 
buf_start=0x2ad0ccddf6fc 
"b=4&d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--&s=l0&i=jE4n8cjO._g4wBfgSzBR; 
F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-&b=pfgj;
 Y=v=1&n=3kntebmsf6jf7&l=43m0h3.2705544@"..., buf_length=4096, 
buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at 
MIME.cc:2745
#2  0x0064422c in mime_hdr_print (mh=, 
buf_start=0x2ad0ccddf000 "POST 
/w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
 HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1, 
iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., buf_length=4096, 
buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at 
MIME.cc:2623
#3  0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010, 
hdr=0x2ad0c12eb098, 
buf=0x2ad0ccddf000 "POST 
/w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
 HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1, 
iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., bufsize=4096, 
bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
#4  0x0059c676 in print (this=, h=0x2acf6e0e8548, 
b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
#5  HttpSM::write_header_into_buffer (this=, 
h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
#6  0x0059e9bb in HttpSM::setup_server_send_request 
(this=0x2acf6e0e7dc0) at HttpSM.cc:5576
#7  0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at 
HttpSM.cc:1508
#8  0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
event=6, data=0x0) at HttpSM.cc:1437
#9  0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0, 
event=6, data=0x0) at HttpSM.cc:1255
#10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0, 
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
#11 0x2acf12d247fc in http_hook (contp=, event=, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
#12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
event=, data=) at HttpSM.cc:1362
#13 0x005a618b in HttpSM::state_http_server_open (this=0x2acf6e0e7dc0, 
event=, data=0x2ad0b88802d0) at HttpSM.cc:1643
#14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0, event=200, 
data=0x2ad0b88802d0) at HttpSM.cc:2501
#15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t=, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
#16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t=, fd=-1) at UnixNetVConnection.cc:1159
#17 0x0070d01f in UnixNetProcessor::connect_re_internal (this=, cont=, target=, 
opt=0x2acf1cd09e00, 
servername=0x2ad0b88804fc "\002") at UnixNetProcessor.cc:255
#18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw=) at ../../iocore/net/P_UnixNetProcessor.h:87
#19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw=) at HttpSM.cc:4646
#20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at 
HttpSM.cc:6975
#21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at 
HttpSM.cc:1505
#22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
event=6, data=0x0) at HttpSM.cc:1437
#23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0, 
event=6, data=0x0) at HttpSM.cc:1255
#24 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0, 
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
#25 0x2acf13dd3492 in append_own_yca_certificate (txnp=0x2acf6e0e7dc0, 
contp=, data=) at yca_plugin.cpp:266
#26 0x2acf13dd3ad3 in yca_auth_plugin_local_handler (contp=0x2ad03008d930, 
event=TS_EVENT_HTTP_OS_DNS, edata=0x2acf6e0e7dc0) at yca_plugin.cpp:961
#27 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
event=, data=) at HttpSM.cc:1362
#28 0x005a9fd2 in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at 
HttpSM.cc:6826
#29 0x00593f12 in HttpSM::do_hostdb_lookup (this=0x2acf6e0e7dc0) at 
HttpSM.cc:3915
#30 0x005aa993 in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at 
HttpSM.cc:6925
#31 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at 
HttpSM.cc:1505
#32 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
event=6, data=0x0) at HttpSM.cc:1437
#33 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0, 
event=6, data=0x0) at Http

[jira] [Commented] (TS-2878) Core dump in mime_field_print

2014-06-05 Thread Brian Geffon (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019122#comment-14019122
 ] 

Brian Geffon commented on TS-2878:
--

Can you please try the patch in TS-2766, because this is a very similar stack 
trace to what we saw.

> Core dump in mime_field_print
> -
>
> Key: TS-2878
> URL: https://issues.apache.org/jira/browse/TS-2878
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>
> Found a new core dump on one of our production hosts with the latest master.
> {code}
> (gdb) 
> #0  0x00366a489932 in memcpy () from /lib64/libc.so.6
> #1  0x006440ec in mime_field_print (field=0x2ad0c12eb398, 
> buf_start=0x2ad0ccddf6fc 
> "b=4&d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--&s=l0&i=jE4n8cjO._g4wBfgSzBR; 
> F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-&b=pfgj;
>  Y=v=1&n=3kntebmsf6jf7&l=43m0h3.2705544@"..., buf_length=4096, 
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at 
> MIME.cc:2745
> #2  0x0064422c in mime_hdr_print (mh=, 
> buf_start=0x2ad0ccddf000 "POST 
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
>  HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1, 
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., buf_length=4096, 
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at 
> MIME.cc:2623
> #3  0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010, 
> hdr=0x2ad0c12eb098, 
> buf=0x2ad0ccddf000 "POST 
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
>  HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1, 
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., bufsize=4096, 
> bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
> #4  0x0059c676 in print (this=, 
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
> #5  HttpSM::write_header_into_buffer (this=, 
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
> #6  0x0059e9bb in HttpSM::setup_server_send_request 
> (this=0x2acf6e0e7dc0) at HttpSM.cc:5576
> #7  0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at 
> HttpSM.cc:1508
> #8  0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1437
> #9  0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1255
> #10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0, 
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #11 0x2acf12d247fc in http_hook (contp=, 
> event=, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
> #12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=, data=) at HttpSM.cc:1362
> #13 0x005a618b in HttpSM::state_http_server_open 
> (this=0x2acf6e0e7dc0, event=, data=0x2ad0b88802d0) at 
> HttpSM.cc:1643
> #14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0, 
> event=200, data=0x2ad0b88802d0) at HttpSM.cc:2501
> #15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t= optimized out>, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
> #16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t= out>, fd=-1) at UnixNetVConnection.cc:1159
> #17 0x0070d01f in UnixNetProcessor::connect_re_internal (this= optimized out>, cont=, target=, 
> opt=0x2acf1cd09e00, 
> servername=0x2ad0b88804fc "\002") at UnixNetProcessor.cc:255
> #18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw= optimized out>) at ../../iocore/net/P_UnixNetProcessor.h:87
> #19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw= out>) at HttpSM.cc:4646
> #20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at 
> HttpSM.cc:6975
> #21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at 
> HttpSM.cc:1505
> #22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1437
> #23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1255
> #24 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0, 
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #25 0x2acf13dd3492 in append_own_yca_certificate (txnp=0x2acf6e0e7dc0, 
> contp=, data=) at yca_plugin.cpp:266
> #26 0x2acf13dd3ad3 in yca_auth_plugin_local_handler 
> (contp=0x2ad03008d930, event=TS_EVENT_HTTP_OS_DNS, edata=0x2acf6e0e7dc0) at 
> yca_plugin.cpp:961
> #27 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=, data=) at HttpSM.cc:1362
> #28 0x005a9fd2 in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at 
> HttpSM.cc:6826
>

[jira] [Comment Edited] (TS-2878) Core dump in mime_field_print

2014-06-05 Thread Brian Geffon (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019122#comment-14019122
 ] 

Brian Geffon edited comment on TS-2878 at 6/5/14 7:23 PM:
--

Can you please try the patch in TS-2766, because this is a very similar stack 
trace to what we saw.

Edit: nevermind I see you're saying this is latest master. Can we get a bt full?


was (Author: briang):
Can you please try the patch in TS-2766, because this is a very similar stack 
trace to what we saw.

> Core dump in mime_field_print
> -
>
> Key: TS-2878
> URL: https://issues.apache.org/jira/browse/TS-2878
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>
> Found a new core dump on one of our production hosts with the latest master.
> {code}
> (gdb) 
> #0  0x00366a489932 in memcpy () from /lib64/libc.so.6
> #1  0x006440ec in mime_field_print (field=0x2ad0c12eb398, 
> buf_start=0x2ad0ccddf6fc 
> "b=4&d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--&s=l0&i=jE4n8cjO._g4wBfgSzBR; 
> F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-&b=pfgj;
>  Y=v=1&n=3kntebmsf6jf7&l=43m0h3.2705544@"..., buf_length=4096, 
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at 
> MIME.cc:2745
> #2  0x0064422c in mime_hdr_print (mh=, 
> buf_start=0x2ad0ccddf000 "POST 
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
>  HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1, 
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., buf_length=4096, 
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at 
> MIME.cc:2623
> #3  0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010, 
> hdr=0x2ad0c12eb098, 
> buf=0x2ad0ccddf000 "POST 
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
>  HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1, 
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., bufsize=4096, 
> bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
> #4  0x0059c676 in print (this=, 
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
> #5  HttpSM::write_header_into_buffer (this=, 
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
> #6  0x0059e9bb in HttpSM::setup_server_send_request 
> (this=0x2acf6e0e7dc0) at HttpSM.cc:5576
> #7  0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at 
> HttpSM.cc:1508
> #8  0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1437
> #9  0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1255
> #10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0, 
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #11 0x2acf12d247fc in http_hook (contp=, 
> event=, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
> #12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=, data=) at HttpSM.cc:1362
> #13 0x005a618b in HttpSM::state_http_server_open 
> (this=0x2acf6e0e7dc0, event=, data=0x2ad0b88802d0) at 
> HttpSM.cc:1643
> #14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0, 
> event=200, data=0x2ad0b88802d0) at HttpSM.cc:2501
> #15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t= optimized out>, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
> #16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t= out>, fd=-1) at UnixNetVConnection.cc:1159
> #17 0x0070d01f in UnixNetProcessor::connect_re_internal (this= optimized out>, cont=, target=, 
> opt=0x2acf1cd09e00, 
> servername=0x2ad0b88804fc "\002") at UnixNetProcessor.cc:255
> #18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw= optimized out>) at ../../iocore/net/P_UnixNetProcessor.h:87
> #19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw= out>) at HttpSM.cc:4646
> #20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at 
> HttpSM.cc:6975
> #21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at 
> HttpSM.cc:1505
> #22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1437
> #23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1255
> #24 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0, 
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #25 0x2acf13dd3492 in append_own_yca_certificate (txnp=0x2acf6e0e7dc0, 
> contp=, data=) at yca_plugin.cpp:266
> #26 0x2acf13dd3ad3 in yca_auth_plugin_local_handler 
> (contp=0x2ad03008d930, event=TS_EVENT_HTTP_OS_DNS,

[jira] [Commented] (TS-2879) Remap errors and redirects should honor keep-alive

2014-06-05 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019126#comment-14019126
 ] 

ASF subversion and git services commented on TS-2879:
-

Commit 25d8a15cc3066bd74182606a440f4122fd1e99ed in trafficserver's branch 
refs/heads/master from [~briang]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=25d8a15 ]

TS-2879: Remap errors and redirects should honor keep-alive


> Remap errors and redirects should honor keep-alive
> --
>
> Key: TS-2879
> URL: https://issues.apache.org/jira/browse/TS-2879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Remap API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that when you redirect via regex_remap (or any remap plugin), or 
> if you have a remap error (such as mapping not found) it will close the 
> connection. This seems wrongs, you should probably honor the clients 
> Keep-Alive settings.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (TS-2879) Remap errors and redirects should honor keep-alive

2014-06-05 Thread Brian Geffon (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Geffon reassigned TS-2879:


Assignee: Brian Geffon

> Remap errors and redirects should honor keep-alive
> --
>
> Key: TS-2879
> URL: https://issues.apache.org/jira/browse/TS-2879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Remap API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that when you redirect via regex_remap (or any remap plugin), or 
> if you have a remap error (such as mapping not found) it will close the 
> connection. This seems wrongs, you should probably honor the clients 
> Keep-Alive settings.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TS-2879) Remap errors and redirects should honor keep-alive

2014-06-05 Thread Brian Geffon (JIRA) 
Brian Geffon created TS-2879:


 Summary: Remap errors and redirects should honor keep-alive
 Key: TS-2879
 URL: https://issues.apache.org/jira/browse/TS-2879
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Remap API
Reporter: Brian Geffon


It appears that when you redirect via regex_remap (or any remap plugin), or if 
you have a remap error (such as mapping not found) it will close the 
connection. This seems wrongs, you should probably honor the clients Keep-Alive 
settings.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2879) Remap errors and redirects should honor keep-alive

2014-06-05 Thread Brian Geffon (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Geffon updated TS-2879:
-

Fix Version/s: 5.1.0

> Remap errors and redirects should honor keep-alive
> --
>
> Key: TS-2879
> URL: https://issues.apache.org/jira/browse/TS-2879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Remap API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.1.0
>
>
> It appears that when you redirect via regex_remap (or any remap plugin), or 
> if you have a remap error (such as mapping not found) it will close the 
> connection. This seems wrongs, you should probably honor the clients 
> Keep-Alive settings.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2878) Core dump in mime_field_print

2014-06-05 Thread Sudheer Vinukonda (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019132#comment-14019132
 ] 

Sudheer Vinukonda commented on TS-2878:
---

Thanks, [~briang] - but, yes, as you noted, we already have the fix for TS-2766 
running in our version. Unfortunately, that core was lost, so, if the issue 
happens again, I will provide the complete bt.

> Core dump in mime_field_print
> -
>
> Key: TS-2878
> URL: https://issues.apache.org/jira/browse/TS-2878
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>
> Found a new core dump on one of our production hosts with the latest master.
> {code}
> (gdb) 
> #0  0x00366a489932 in memcpy () from /lib64/libc.so.6
> #1  0x006440ec in mime_field_print (field=0x2ad0c12eb398, 
> buf_start=0x2ad0ccddf6fc 
> "b=4&d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--&s=l0&i=jE4n8cjO._g4wBfgSzBR; 
> F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-&b=pfgj;
>  Y=v=1&n=3kntebmsf6jf7&l=43m0h3.2705544@"..., buf_length=4096, 
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at 
> MIME.cc:2745
> #2  0x0064422c in mime_hdr_print (mh=, 
> buf_start=0x2ad0ccddf000 "POST 
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
>  HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1, 
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., buf_length=4096, 
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at 
> MIME.cc:2623
> #3  0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010, 
> hdr=0x2ad0c12eb098, 
> buf=0x2ad0ccddf000 "POST 
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
>  HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1, 
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., bufsize=4096, 
> bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
> #4  0x0059c676 in print (this=, 
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
> #5  HttpSM::write_header_into_buffer (this=, 
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
> #6  0x0059e9bb in HttpSM::setup_server_send_request 
> (this=0x2acf6e0e7dc0) at HttpSM.cc:5576
> #7  0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at 
> HttpSM.cc:1508
> #8  0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1437
> #9  0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1255
> #10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0, 
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #11 0x2acf12d247fc in http_hook (contp=, 
> event=, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
> #12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=, data=) at HttpSM.cc:1362
> #13 0x005a618b in HttpSM::state_http_server_open 
> (this=0x2acf6e0e7dc0, event=, data=0x2ad0b88802d0) at 
> HttpSM.cc:1643
> #14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0, 
> event=200, data=0x2ad0b88802d0) at HttpSM.cc:2501
> #15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t= optimized out>, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
> #16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t= out>, fd=-1) at UnixNetVConnection.cc:1159
> #17 0x0070d01f in UnixNetProcessor::connect_re_internal (this= optimized out>, cont=, target=, 
> opt=0x2acf1cd09e00, 
> servername=0x2ad0b88804fc "\002") at UnixNetProcessor.cc:255
> #18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw= optimized out>) at ../../iocore/net/P_UnixNetProcessor.h:87
> #19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw= out>) at HttpSM.cc:4646
> #20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at 
> HttpSM.cc:6975
> #21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at 
> HttpSM.cc:1505
> #22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1437
> #23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0, 
> event=6, data=0x0) at HttpSM.cc:1255
> #24 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0, 
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #25 0x2acf13dd3492 in append_own_yca_certificate (txnp=0x2acf6e0e7dc0, 
> contp=, data=) at yca_plugin.cpp:266
> #26 0x2acf13dd3ad3 in yca_auth_plugin_local_handler 
> (contp=0x2ad03008d930, event=TS_EVENT_HTTP_OS_DNS, edata=0x2acf6e0e7dc0) at 
> yca_plugin.cpp:961
> #27 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0, 
> event=, data=)

[jira] [Resolved] (TS-2879) Remap errors and redirects should honor keep-alive

2014-06-05 Thread Brian Geffon (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Geffon resolved TS-2879.
--

Resolution: Fixed

> Remap errors and redirects should honor keep-alive
> --
>
> Key: TS-2879
> URL: https://issues.apache.org/jira/browse/TS-2879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Remap API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.1.0
>
>
> It appears that when you redirect via regex_remap (or any remap plugin), or 
> if you have a remap error (such as mapping not found) it will close the 
> connection. This seems wrongs, you should probably honor the clients 
> Keep-Alive settings.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2879) Remap errors and redirects should honor keep-alive

2014-06-05 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019127#comment-14019127
 ] 

ASF subversion and git services commented on TS-2879:
-

Commit 35f787284588b479203c3103c3590bab7fa9e95f in trafficserver's branch 
refs/heads/master from [~briang]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=35f7872 ]

TS-2879: Remap errors and redirects should honor keep-alive


> Remap errors and redirects should honor keep-alive
> --
>
> Key: TS-2879
> URL: https://issues.apache.org/jira/browse/TS-2879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Remap API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> It appears that when you redirect via regex_remap (or any remap plugin), or 
> if you have a remap error (such as mapping not found) it will close the 
> connection. This seems wrongs, you should probably honor the clients 
> Keep-Alive settings.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2776) Core dump inside openssl library

2014-06-05 Thread Sudheer Vinukonda (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14018209#comment-14018209
 ] 

Sudheer Vinukonda edited comment on TS-2776 at 6/5/14 10:17 PM:


Just fyi - the fix seems to work well. No cores since the fix and we have a few 
production hosts now running stable with 5.0 + spdy.

Note : It looks like there's more than one security vulnerability due to the 
setting SSL_MODE_RELEASE_BUFFERS. Along with CVE-2014-0198, that can result in 
a crash due to null pointer dereference, there's also a possibility of DoS 
attach due to CVE-2010-5298

Links to the CVE:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-5298
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0198



was (Author: sudheerv):
Just fyi - the fix seems to work well. No cores since the fix and we have a few 
production hosts now running stable with 5.0 + spdy.

> Core dump inside openssl library
> 
>
> Key: TS-2776
> URL: https://issues.apache.org/jira/browse/TS-2776
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY, SSL
>Reporter: Sudheer Vinukonda
>Assignee: Bryan Call
>Priority: Blocker
>  Labels: spdy, yahoo
> Fix For: 5.0.0
>
>
> During production testing of SPDY (w/ ATS compiled from master repo), noticed 
> the below core from open ssl library. This core showed up after fixing a few 
> other core dumps and memory leaks (refer TS-2742, TS-2743, TS-2750, TS-2765, 
> TS-2767 etc) and happened once so far, after running stable for 30+ hours on 
> a production host. 
> {code}
> [example_prep.sh] Checking/Moving old cores...
> [TrafficServer] using root directory '/home/y'
> [TrafficManager] ==> Cleaning up and reissuing signal #15
> [TrafficManager] ==> signal #15
> [E. Mgmt] log ==> [TrafficManager] using root directory '/home/y'
> [example_prep.sh] Checking/Moving old cores...
> [TrafficServer] using root directory '/home/y'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x329720f500)[0x2b7dff1f6500]
> /usr/lib64/libssl.so.10[0x331622b2e7]
> /usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6db57f]
> /home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x418)[0x6ef488]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x6e3ee3]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x7109ff]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x43b)[0x71122b]
> /home/y/bin/traffic_server[0x70fdaa]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b7dff1ee851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> [E. Mgmt] log ==> [TrafficManager] using root directory '/home/y'
> [example_prep.sh] Checking/Moving old cores...
> [TrafficServer] using root directory '/home/y'
> {code}
> gdb output below:
> {code}
> (gdb) bt
> #0  0x00331622b2e7 in ?? () from /usr/lib64/libssl.so.10
> #1  0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
> #2  0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693, 
> wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf= out>, needs=@0x2b7e111aec38)
> at SSLNetVConnection.cc:90
> #3  SSLNetVConnection::load_buffer_and_write (this=0x2b7f42c7ca70, 
> towrite=207693, wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, 
> buf=, needs=@0x2b7e111aec38)
> at SSLNetVConnection.cc:399
> #4  0x006ef488 in write_to_net_io (nh=0x2b7e0f89ac10, 
> vc=0x2b7f42c7ca70, thread=0x2b7e0f897010) at UnixNetVConnection.cc:527
> #5  0x006e3ee3 in NetHandler::mainNetEvent (this=0x2b7e0f89ac10, 
> event=, e=) at UnixNet.cc:400
> #6  0x007109ff in handleEvent (this=0x2b7e0f897010, e=0x31ae0d0, 
> calling_code=5) at I_Continuation.h:146
> #7  EThread::process_event (this=0x2b7e0f897010, e=0x31ae0d0, calling_code=5) 
> at UnixEThread.cc:145
> #8  0x0071122b in EThread::execute (this=0x2b7e0f897010) at 
> UnixEThread.cc:269
> #9  0x0070fdaa in spawn_thread_internal (a=0x2f8fbe0) at Thread.cc:88
> #10 0x2b7dff1ee851 in start_thread () from /lib64/libpthread.so.0
> #11 0x003296ee890d in clone () from /lib64/libc.so.6
> (gdb) up
> #1  0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
> (gdb) up
> #2  0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693, 
> wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf= out>, needs=@0x2b7e111aec38)
> at SSLNetVConnection.cc:90
> 90SSLNetVConnection.cc: No such file or directory.
>   in SSLNetVConnection.cc
> (gdb) 
> {code}



--
This message was