[jira] [Commented] (TS-2825) Segmentation fault on POST request transformation

2014-06-19 Thread portl4t (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037003#comment-14037003
 ] 

portl4t commented on TS-2825:
-

I found that ATS does not support chunked post request transformation well, 
which has been described in HttpSM::state_request_wait_for_transform_read(...):
...
 else {
  // No content length from the post.  This is a no go
  //  since http spec requires content length when
  //  sending a request message body.  Change the event
  //  to an error and fall through
  event = VC_EVENT_ERROR;
  Log::error(Request transformation failed to set content length);
} 

As the VC_EVENT_ERROR event arise, the  tunnel will be killed, then the 
producer UA will invoke do_io_close which cause client_vc will be set to NULL, 
after that ATS will try to send error response to UA, so it will crash.

Should we just fix the crash or refine chunked post transformation?

 Segmentation fault on POST request transformation
 -

 Key: TS-2825
 URL: https://issues.apache.org/jira/browse/TS-2825
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, HTTP, Lua, Plugins, TS API
Reporter: Pasquale Puzio
Assignee: Kit Chan
Priority: Critical
 Fix For: sometime


 I'm trying to write a simple encryption/decryption plugin for Apache Traffic 
 Server. The plugin should transform requests/responses in order to 
 encrypt/decrypt them. I decided to write the plugin in LUA (using the ts-lua 
 plugin available here https://github.com/portl4t/ts-lua)
 function encrypt(data, eos)
 if (data == '') then
 return data, eos
 end
 if (eos == 1) then
 ts.debug('End of Stream')
 end
 return data, eos
 end
 function do_remap()
 ts.debug('do_remap')
 if (ts.client_request.get_method() == 'POST') then
 ts.hook(TS_LUA_REQUEST_TRANSFORM, encrypt)
 end
 ts.http.resp_cache_transformed(0)
 ts.http.resp_cache_untransformed(0)
 return 0
 end
 Everything works fine for GET and DELETE requests, but when I send a POST 
 chunked-encoded request, ATS crashes almost every time.
 if I don't activate the request transformation hook, the chunked request is 
 forwarded perfectly. Most of the time, if one request is forwarded 
 succesfully, the one after crashes.
 Here is the stack trace:
 [May 20 13:16:28.105] Server {0x7f045a1c1700} DEBUG: (http_redirect) 
 [HttpSM::do_redirect]
 [May 20 13:16:28.105] Server {0x7f045a1c1700} DEBUG: (http_redirect) 
 [HttpTunnel::deallocate_postdata_copy_buffers]
 NOTE: Traffic Server received Sig 11: Segmentation fault
 bin/traffic_server - STACK TRACE: 
 /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f045cd29cb0]
 bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x171)[0x5c274f]
 bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x883)[0x5c24cf]
 bin/traffic_server(_ZN6HttpSM23do_api_callout_internalEv+0x1b7)[0x5ceaef]
 bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x26)[0x5dc18e]
 bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x12f9)[0x5d6a19]
 bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ba)[0x5d5718]
 bin/traffic_server(_ZN6HttpSM36state_common_wait_for_transform_readEP17HttpTransformInfoMS_FiiPvEiS2_+0x39b)[0x5c1a11]
 bin/traffic_server(_ZN6HttpSM37state_request_wait_for_transform_readEiPv+0x1e1)[0x5c1483]
 bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x333)[0x5c5eeb]
 bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4f06b2]
 bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x2f6)[0x538d2a]
 bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4f06b2]
 bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x11e)[0x7537e2]
 bin/traffic_server(_ZN7EThread7executeEv+0xc9)[0x753a27]
 bin/traffic_server[0x752ca7]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f045cd21e9a]
 /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f045c0383fd]
 Segmentation fault (core dumped)
 I've already tried to use one of the example plugins for request 
 transformation and I still have the same problem. The only way to make the 
 problem disappear is to avoid request transformation.
 Is there something wrong in the way I'm transforming requests? What does this 
 segmentation fault depend on?
 Thanks



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

[jira] [Comment Edited] (TS-2825) Segmentation fault on POST request transformation

2014-06-19 Thread portl4t (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037003#comment-14037003
 ] 

portl4t edited comment on TS-2825 at 6/19/14 6:08 AM:
--

I found that ATS does not support chunked post request transformation well, 
which has been described in HttpSM::state_request_wait_for_transform_read(...):
{code}
...
} else {
  // No content length from the post.  This is a no go
  //  since http spec requires content length when
  //  sending a request message body.  Change the event
  //  to an error and fall through
  event = VC_EVENT_ERROR;
  Log::error(Request transformation failed to set content length);
} 
// FALLTHROUGH
  default:
state_common_wait_for_transform_read(post_transform_info, 
HttpSM::tunnel_handler_post, event, data);
break;
  }
{code}
As the VC_EVENT_ERROR event arise, the  tunnel will be killed, then the 
producer UA will invoke do_io_close which cause client_vc will be set to NULL, 
after that ATS will try to send error response to UA, so it will crash.

Should we just fix the crash or refine chunked post transformation?


was (Author: portl4t):
I found that ATS does not support chunked post request transformation well, 
which has been described in HttpSM::state_request_wait_for_transform_read(...):
...
 else {
  // No content length from the post.  This is a no go
  //  since http spec requires content length when
  //  sending a request message body.  Change the event
  //  to an error and fall through
  event = VC_EVENT_ERROR;
  Log::error(Request transformation failed to set content length);
} 

As the VC_EVENT_ERROR event arise, the  tunnel will be killed, then the 
producer UA will invoke do_io_close which cause client_vc will be set to NULL, 
after that ATS will try to send error response to UA, so it will crash.

Should we just fix the crash or refine chunked post transformation?

 Segmentation fault on POST request transformation
 -

 Key: TS-2825
 URL: https://issues.apache.org/jira/browse/TS-2825
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, HTTP, Lua, Plugins, TS API
Reporter: Pasquale Puzio
Assignee: Kit Chan
Priority: Critical
 Fix For: sometime


 I'm trying to write a simple encryption/decryption plugin for Apache Traffic 
 Server. The plugin should transform requests/responses in order to 
 encrypt/decrypt them. I decided to write the plugin in LUA (using the ts-lua 
 plugin available here https://github.com/portl4t/ts-lua)
 function encrypt(data, eos)
 if (data == '') then
 return data, eos
 end
 if (eos == 1) then
 ts.debug('End of Stream')
 end
 return data, eos
 end
 function do_remap()
 ts.debug('do_remap')
 if (ts.client_request.get_method() == 'POST') then
 ts.hook(TS_LUA_REQUEST_TRANSFORM, encrypt)
 end
 ts.http.resp_cache_transformed(0)
 ts.http.resp_cache_untransformed(0)
 return 0
 end
 Everything works fine for GET and DELETE requests, but when I send a POST 
 chunked-encoded request, ATS crashes almost every time.
 if I don't activate the request transformation hook, the chunked request is 
 forwarded perfectly. Most of the time, if one request is forwarded 
 succesfully, the one after crashes.
 Here is the stack trace:
 [May 20 13:16:28.105] Server {0x7f045a1c1700} DEBUG: (http_redirect) 
 [HttpSM::do_redirect]
 [May 20 13:16:28.105] Server {0x7f045a1c1700} DEBUG: (http_redirect) 
 [HttpTunnel::deallocate_postdata_copy_buffers]
 NOTE: Traffic Server received Sig 11: Segmentation fault
 bin/traffic_server - STACK TRACE: 
 /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f045cd29cb0]
 bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x171)[0x5c274f]
 bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x883)[0x5c24cf]
 bin/traffic_server(_ZN6HttpSM23do_api_callout_internalEv+0x1b7)[0x5ceaef]
 bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x26)[0x5dc18e]
 bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x12f9)[0x5d6a19]
 bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ba)[0x5d5718]
 bin/traffic_server(_ZN6HttpSM36state_common_wait_for_transform_readEP17HttpTransformInfoMS_FiiPvEiS2_+0x39b)[0x5c1a11]
 bin/traffic_server(_ZN6HttpSM37state_request_wait_for_transform_readEiPv+0x1e1)[0x5c1483]
 bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x333)[0x5c5eeb]
 bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4f06b2]
 bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x2f6)[0x538d2a]
 bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4f06b2]
 bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x11e)[0x7537e2]

[jira] [Commented] (TS-2889) Crash in FetchSM related to spdy FetchSM changes in 5.0.x

2014-06-19 Thread Kit Chan (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037012#comment-14037012
 ] 

Kit Chan commented on TS-2889:
--

Tested. Latest patch worked well with my ESI plugin use case.

 Crash in FetchSM related to spdy FetchSM changes in 5.0.x
 -

 Key: TS-2889
 URL: https://issues.apache.org/jira/browse/TS-2889
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, SPDY
Affects Versions: 5.0.0
Reporter: Brian Geffon
Assignee: Brian Geffon
 Fix For: 5.1.0

 Attachments: ts2889.diff


 I'm seeing a crash in the FetchSM on 5.0.x, this is surely because of the 
 changes that were made to the FetchSM as a result of SPDY. 
 Sample bt:
 #0  0x00377c632925 in raise () from /lib64/libc.so.6
 #1  0x00377c634105 in abort () from /lib64/libc.so.6
 #2  0x2b09b0693ef0 in ink_die_die_die (retval=1) at ink_error.cc:43
 #3  0x2b09b0693fbd in ink_fatal_va(int, const char *, typedef 
 __va_list_tag __va_list_tag *) (return_code=1, 
 message_format=0x2b09b06a1358 %s:%d: failed assert `%s`, 
 ap=0x2b09b8806710) at ink_error.cc:65
 #4  0x2b09b0694086 in ink_fatal (return_code=1, 
 message_format=0x2b09b06a1358 %s:%d: failed assert `%s`)
 at ink_error.cc:73
 #5  0x2b09b0692d40 in _ink_assert (expression=0x761f2f header_done, 
 file=0x761ede FetchSM.cc, line=160) at ink_assert.cc:37
 #6  0x004fa5c0 in FetchSM::check_chunked (this=0x2b09f8012240)
 at FetchSM.cc:160
 #7  0x004fac82 in FetchSM::get_info_from_buffer (this=0x2b09f8012240, 
 the_reader=0x2b09f4004818) at FetchSM.cc:313
 #8  0x004fb18b in FetchSM::process_fetch_read (this=0x2b09f8012240, 
 event=104) at FetchSM.cc:402
 #9  0x004fb42d in FetchSM::fetch_handler (this=0x2b09f8012240, 
 event=104, edata=0x2b09f8002768) at FetchSM.cc:449
 #10 0x004fc43e in Continuation::handleEvent (this=0x2b09f8012240, 
 event=104, data=0x2b09f8002768)
 at ../iocore/eventsystem/I_Continuation.h:146
 ---Type return to continue, or q return to quit---
 #11 0x00537f2e in PluginVC::process_read_side (this=0x2b09f8002670, 
 other_side_call=false) at PluginVC.cc:637
 #12 0x00536856 in PluginVC::main_handler (this=0x2b09f8002670, 
 event=1, data=0x2b0a340293e0) at PluginVC.cc:208
 #13 0x004fc43e in Continuation::handleEvent (this=0x2b09f8002670, 
 event=1, data=0x2b0a340293e0) at 
 ../iocore/eventsystem/I_Continuation.h:146
 #14 0x0075d2e6 in EThread::process_event (this=0x2b09b23cc010, 
 e=0x2b0a340293e0, calling_code=1) at UnixEThread.cc:145
 #15 0x0075d4b4 in EThread::execute (this=0x2b09b23cc010)
 at UnixEThread.cc:196
 #16 0x0075c844 in spawn_thread_internal (a=0x1428b10) at Thread.cc:88
 #17 0x00377ce079d1 in start_thread () from /lib64/libpthread.so.0



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

[jira] [Updated] (TS-2134) SRV lookup does not handle failover correctly

2014-06-19 Thread Thach Tran (JIRA) 

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

Thach Tran updated TS-2134:
---

Attachment: ts2134.patch

I have been using this patch in our setup for some time and it seems to handle 
the SRV failover correctly as far as I can tell.

Could someone help reviewing this since I'm not too sure on some of the details 
regarding how DNS SRV and hostdb are supposed to work in Traffic Server.

 SRV lookup does not handle failover correctly
 -

 Key: TS-2134
 URL: https://issues.apache.org/jira/browse/TS-2134
 Project: Traffic Server
  Issue Type: Bug
  Components: DNS, HTTP
Reporter: Thach Tran
 Fix For: sometime

 Attachments: ats.log, ts2134.patch


 I'm seeing an issue with SRV lookup in ATS in which the proxy doesn't fail 
 over to alternative origins once the first choice is marked as down.
 To reproduce this, I'm running dnsmasq as a local resolver to serve up the 
 test SRV records. My configuration is as follows.
 h4. records.config
 CONFIG proxy.config.dns.nameservers STRING 127.0.0.1
 CONFIG proxy.config.dns.resolv_conf STRING NULL
 CONFIG proxy.config.srv_enabled INT 1
 h4. remap.config
 regex_remap http://.*:8080/ https://noexample.com/
 h4. dnsmasq.conf (srv records config)
 srv-host=_http._tcp.noexample.com,abc.com,443,0,100
 srv-host=_http._tcp.noexample.com,google.com,443,1,100
 The intention is since the srv lookup for _http._tcp.noexample.com returns 
 abc.com:443 and google.com:443 with abc.com:443 being the one with higher 
 priority, the proxy should try that first and once the connection to 
 abc.com:443 is marked as down (up to 6 retries by default), google.com:443 
 should be tried next and the connection should succeed then.
 However, testing with the following curl command multiple times still gives 
 back 502.
 $ curl -v http://localhost:8080/
 Debug log seems to suggest it always attempts abc.com:443.



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

[jira] [Updated] (TS-2134) SRV lookup does not handle failover correctly

2014-06-19 Thread Leif Hedstrom (JIRA) 

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

Leif Hedstrom updated TS-2134:
--

Fix Version/s: (was: sometime)
   5.1.0

 SRV lookup does not handle failover correctly
 -

 Key: TS-2134
 URL: https://issues.apache.org/jira/browse/TS-2134
 Project: Traffic Server
  Issue Type: Bug
  Components: DNS, HTTP
Reporter: Thach Tran
  Labels: review
 Fix For: 5.1.0

 Attachments: ats.log, ts2134.patch


 I'm seeing an issue with SRV lookup in ATS in which the proxy doesn't fail 
 over to alternative origins once the first choice is marked as down.
 To reproduce this, I'm running dnsmasq as a local resolver to serve up the 
 test SRV records. My configuration is as follows.
 h4. records.config
 CONFIG proxy.config.dns.nameservers STRING 127.0.0.1
 CONFIG proxy.config.dns.resolv_conf STRING NULL
 CONFIG proxy.config.srv_enabled INT 1
 h4. remap.config
 regex_remap http://.*:8080/ https://noexample.com/
 h4. dnsmasq.conf (srv records config)
 srv-host=_http._tcp.noexample.com,abc.com,443,0,100
 srv-host=_http._tcp.noexample.com,google.com,443,1,100
 The intention is since the srv lookup for _http._tcp.noexample.com returns 
 abc.com:443 and google.com:443 with abc.com:443 being the one with higher 
 priority, the proxy should try that first and once the connection to 
 abc.com:443 is marked as down (up to 6 retries by default), google.com:443 
 should be tried next and the connection should succeed then.
 However, testing with the following curl command multiple times still gives 
 back 502.
 $ curl -v http://localhost:8080/
 Debug log seems to suggest it always attempts abc.com:443.



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

[jira] [Created] (TS-2893) Add support for ECDSA certificates

2014-06-19 Thread Bryan Call (JIRA) 
Bryan Call created TS-2893:
--

 Summary: Add support for ECDSA certificates 
 Key: TS-2893
 URL: https://issues.apache.org/jira/browse/TS-2893
 Project: Traffic Server
  Issue Type: Improvement
  Components: SSL
Reporter: Bryan Call


Add the ability to deliver different certificates to the client depending on 
the cipher list advertised by the client.



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

[jira] [Updated] (TS-2689) Traffic Server Segmentation Fault(cacheurl plugin)

2014-06-19 Thread Phil Sorber (JIRA) 

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

Phil Sorber updated TS-2689:


Affects Version/s: 5.0.0

 Traffic Server Segmentation Fault(cacheurl plugin)
 --

 Key: TS-2689
 URL: https://issues.apache.org/jira/browse/TS-2689
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 5.0.0
Reporter: seri,Kim
Assignee: Justin Laue
  Labels: crash
 Fix For: 5.1.0


 I used latest cacheurl plugin!!
 {code}
 [TrafficServer] using root directory '/opt/Testa/ATS/4.2.0-v7'
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server - STACK TRACE:
 /lib64/libpthread.so.0[0x33ff40f710]
 /opt/Testa/ATS/4.2.0-v7/libexec/cacheurl.so(pr_list::~pr_list()+0x30)[0x2b15bb0b7346]
 /opt/Testa/ATS/4.2.0-v7/libexec/cacheurl.so(TSRemapDeleteInstance+0x4a)[0x2b15bb0b71e5]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(url_mapping::delete_instance(unsigned
  int)+0x65)[0x5b8e8b]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(url_mapping::~url_mapping()+0xe3)[0x5b8f71]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::Clear()+0x2f)[0x5ba701]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::~Trie()+0x23)[0x5b9eed]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::~Trie()+0x18)[0x5b9f1c]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlMappingPathIndex::~UrlMappingPathIndex()+0x54)[0x5b95e4]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlMappingPathIndex::~UrlMappingPathIndex()+0x18)[0x5b9696]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::_destroyTable(Tcl_HashTable*)+0x65)[0x5af957]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::DestroyStore(UrlRewrite::MappingsStore)+0x26)[0x5b2062]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::~UrlRewrite()+0x45)[0x5af601]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(DeleterContinuationUrlRewrite::dieEvent(int,
  void*)+0x36)[0x52480a]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Continuation::handleEvent(int, 
 void*)+0x6c)[0x4e5b70]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(EThread::process_event(Event*, 
 int)+0xc8)[0x6d2186]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(EThread::execute()+0x1ed)[0x6d24a1]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server[0x6d1770]
 /lib64/libpthread.so.0[0x33ff4079d1]
 /lib64/libc.so.6(clone+0x6d)[0x33ff0e8b6d]
 {code}



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

[jira] [Updated] (TS-2689) Traffic Server Segmentation Fault(cacheurl plugin)

2014-06-19 Thread Phil Sorber (JIRA) 

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

Phil Sorber updated TS-2689:


Fix Version/s: (was: sometime)
   5.1.0

 Traffic Server Segmentation Fault(cacheurl plugin)
 --

 Key: TS-2689
 URL: https://issues.apache.org/jira/browse/TS-2689
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 5.0.0
Reporter: seri,Kim
Assignee: Justin Laue
  Labels: crash
 Fix For: 5.1.0


 I used latest cacheurl plugin!!
 {code}
 [TrafficServer] using root directory '/opt/Testa/ATS/4.2.0-v7'
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server - STACK TRACE:
 /lib64/libpthread.so.0[0x33ff40f710]
 /opt/Testa/ATS/4.2.0-v7/libexec/cacheurl.so(pr_list::~pr_list()+0x30)[0x2b15bb0b7346]
 /opt/Testa/ATS/4.2.0-v7/libexec/cacheurl.so(TSRemapDeleteInstance+0x4a)[0x2b15bb0b71e5]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(url_mapping::delete_instance(unsigned
  int)+0x65)[0x5b8e8b]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(url_mapping::~url_mapping()+0xe3)[0x5b8f71]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::Clear()+0x2f)[0x5ba701]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::~Trie()+0x23)[0x5b9eed]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::~Trie()+0x18)[0x5b9f1c]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlMappingPathIndex::~UrlMappingPathIndex()+0x54)[0x5b95e4]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlMappingPathIndex::~UrlMappingPathIndex()+0x18)[0x5b9696]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::_destroyTable(Tcl_HashTable*)+0x65)[0x5af957]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::DestroyStore(UrlRewrite::MappingsStore)+0x26)[0x5b2062]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::~UrlRewrite()+0x45)[0x5af601]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(DeleterContinuationUrlRewrite::dieEvent(int,
  void*)+0x36)[0x52480a]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Continuation::handleEvent(int, 
 void*)+0x6c)[0x4e5b70]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(EThread::process_event(Event*, 
 int)+0xc8)[0x6d2186]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(EThread::execute()+0x1ed)[0x6d24a1]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server[0x6d1770]
 /lib64/libpthread.so.0[0x33ff4079d1]
 /lib64/libc.so.6(clone+0x6d)[0x33ff0e8b6d]
 {code}



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

[jira] [Commented] (TS-2689) Traffic Server Segmentation Fault(cacheurl plugin)

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

[ 
https://issues.apache.org/jira/browse/TS-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038042#comment-14038042
 ] 

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

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

TS-2689: Remove extraneous TSfree that caused segfault


 Traffic Server Segmentation Fault(cacheurl plugin)
 --

 Key: TS-2689
 URL: https://issues.apache.org/jira/browse/TS-2689
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 5.0.0
Reporter: seri,Kim
Assignee: Justin Laue
  Labels: crash
 Fix For: 5.1.0


 I used latest cacheurl plugin!!
 {code}
 [TrafficServer] using root directory '/opt/Testa/ATS/4.2.0-v7'
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server - STACK TRACE:
 /lib64/libpthread.so.0[0x33ff40f710]
 /opt/Testa/ATS/4.2.0-v7/libexec/cacheurl.so(pr_list::~pr_list()+0x30)[0x2b15bb0b7346]
 /opt/Testa/ATS/4.2.0-v7/libexec/cacheurl.so(TSRemapDeleteInstance+0x4a)[0x2b15bb0b71e5]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(url_mapping::delete_instance(unsigned
  int)+0x65)[0x5b8e8b]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(url_mapping::~url_mapping()+0xe3)[0x5b8f71]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::Clear()+0x2f)[0x5ba701]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::~Trie()+0x23)[0x5b9eed]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::~Trie()+0x18)[0x5b9f1c]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlMappingPathIndex::~UrlMappingPathIndex()+0x54)[0x5b95e4]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlMappingPathIndex::~UrlMappingPathIndex()+0x18)[0x5b9696]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::_destroyTable(Tcl_HashTable*)+0x65)[0x5af957]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::DestroyStore(UrlRewrite::MappingsStore)+0x26)[0x5b2062]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::~UrlRewrite()+0x45)[0x5af601]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(DeleterContinuationUrlRewrite::dieEvent(int,
  void*)+0x36)[0x52480a]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Continuation::handleEvent(int, 
 void*)+0x6c)[0x4e5b70]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(EThread::process_event(Event*, 
 int)+0xc8)[0x6d2186]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(EThread::execute()+0x1ed)[0x6d24a1]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server[0x6d1770]
 /lib64/libpthread.so.0[0x33ff4079d1]
 /lib64/libc.so.6(clone+0x6d)[0x33ff0e8b6d]
 {code}



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

[jira] [Resolved] (TS-2689) Traffic Server Segmentation Fault(cacheurl plugin)

2014-06-19 Thread Phil Sorber (JIRA) 

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

Phil Sorber resolved TS-2689.
-

Resolution: Fixed

 Traffic Server Segmentation Fault(cacheurl plugin)
 --

 Key: TS-2689
 URL: https://issues.apache.org/jira/browse/TS-2689
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 5.0.0
Reporter: seri,Kim
Assignee: Justin Laue
  Labels: crash
 Fix For: 5.1.0


 I used latest cacheurl plugin!!
 {code}
 [TrafficServer] using root directory '/opt/Testa/ATS/4.2.0-v7'
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server - STACK TRACE:
 /lib64/libpthread.so.0[0x33ff40f710]
 /opt/Testa/ATS/4.2.0-v7/libexec/cacheurl.so(pr_list::~pr_list()+0x30)[0x2b15bb0b7346]
 /opt/Testa/ATS/4.2.0-v7/libexec/cacheurl.so(TSRemapDeleteInstance+0x4a)[0x2b15bb0b71e5]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(url_mapping::delete_instance(unsigned
  int)+0x65)[0x5b8e8b]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(url_mapping::~url_mapping()+0xe3)[0x5b8f71]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::Clear()+0x2f)[0x5ba701]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::~Trie()+0x23)[0x5b9eed]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Trieurl_mapping::~Trie()+0x18)[0x5b9f1c]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlMappingPathIndex::~UrlMappingPathIndex()+0x54)[0x5b95e4]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlMappingPathIndex::~UrlMappingPathIndex()+0x18)[0x5b9696]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::_destroyTable(Tcl_HashTable*)+0x65)[0x5af957]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::DestroyStore(UrlRewrite::MappingsStore)+0x26)[0x5b2062]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(UrlRewrite::~UrlRewrite()+0x45)[0x5af601]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(DeleterContinuationUrlRewrite::dieEvent(int,
  void*)+0x36)[0x52480a]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(Continuation::handleEvent(int, 
 void*)+0x6c)[0x4e5b70]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(EThread::process_event(Event*, 
 int)+0xc8)[0x6d2186]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server(EThread::execute()+0x1ed)[0x6d24a1]
 /opt/Testa/ATS/4.2.0-v7/bin/traffic_server[0x6d1770]
 /lib64/libpthread.so.0[0x33ff4079d1]
 /lib64/libc.so.6(clone+0x6d)[0x33ff0e8b6d]
 {code}



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