[jira] [Commented] (TS-2911) Custom Thread Pools
[ https://issues.apache.org/jira/browse/TS-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14220733#comment-14220733 ] Luca Rea commented on TS-2911: -- This seems to be much related to threads affinity than to control number of threads per listener, isn't it? Custom Thread Pools --- Key: TS-2911 URL: https://issues.apache.org/jira/browse/TS-2911 Project: Traffic Server Issue Type: New Feature Components: Core, Performance Reporter: Luca Rea Request feature to support adding new thread pools and assign them to groups of inbound listeners and oubound parents or domains -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-518) Close UA connection early if the origin sent Connection close:, there's a bad Content-Length header, and the UA connection has Keep-Alive.
[ https://issues.apache.org/jira/browse/TS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-518: -- Fix Version/s: (was: 5.2.0) 5.3.0 Close UA connection early if the origin sent Connection close:, there's a bad Content-Length header, and the UA connection has Keep-Alive. -- Key: TS-518 URL: https://issues.apache.org/jira/browse/TS-518 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Susan Hinrichs Fix For: 5.3.0 In a very special case, we could improve the user experience by forcefully closing the connection early. The case is 1) The origin server sends a Content-Length: header that is wrong, where the CL: value exceeds the actually body size. 2) The origin server either sends a Connection: close, or it uses HTTP/1.0 without keep-alive. 3) The client (and TS) uses Keep-Alive to the UA. In this case, we can end up stalling the UA until either the UA or the TS connection times out. It might make sense to prematurely disconnect the client when this case is detected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-518) Close UA connection early if the origin sent Connection close:, there's a bad Content-Length header, and the UA connection has Keep-Alive.
[ https://issues.apache.org/jira/browse/TS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14220929#comment-14220929 ] Susan Hinrichs commented on TS-518: --- Moving back to 5.3.0. I strongly suspect this is fixed in 5.2.0, but I need to set up a test to verify. Close UA connection early if the origin sent Connection close:, there's a bad Content-Length header, and the UA connection has Keep-Alive. -- Key: TS-518 URL: https://issues.apache.org/jira/browse/TS-518 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Susan Hinrichs Fix For: 5.3.0 In a very special case, we could improve the user experience by forcefully closing the connection early. The case is 1) The origin server sends a Content-Length: header that is wrong, where the CL: value exceeds the actually body size. 2) The origin server either sends a Connection: close, or it uses HTTP/1.0 without keep-alive. 3) The client (and TS) uses Keep-Alive to the UA. In this case, we can end up stalling the UA until either the UA or the TS connection times out. It might make sense to prematurely disconnect the client when this case is detected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3191) Confusion with HTTP_TUNNEL_STATIC_PRODUCER
[ https://issues.apache.org/jira/browse/TS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14220945#comment-14220945 ] ASF subversion and git services commented on TS-3191: - Commit 3c8cb52d450612b37915abc17c517675a6854ac8 in trafficserver's branch refs/heads/master from [~shinrich] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3c8cb52 ] TS-3191: Add logic to better handle collisions between static producers. Confusion with HTTP_TUNNEL_STATIC_PRODUCER -- Key: TS-3191 URL: https://issues.apache.org/jira/browse/TS-3191 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 In the HttpTunnel processing, normally a producer has a VC associated with it. The VC is used to lookup the producer via the HttpTunnel::get_producer method out of the HttpTunnel producer array. All is well and good, but in the case of a static producer, there is no vc. Rather the constant HTTP_TUNNEL_STATIC_PRODUCER is used in lieu of the vc. If there is only only one static producer all is still well, get_producer will return the one producer associated with HTTP_TUNNEL_STATIC_PRODUCER. But if there is more than one static producer involved with the tunnel, get_producer() will only return one producer. Both static consumers will only interact with one of the static producers and things will go down hill from here. I ran into this case while chasing down crashes via TS-3105, so this situation does come up in the wild. I fixed it by clearing out the tunnel before starting a static producer and making some other checks along the way. We could also avoid some calls to get_producer since it many cases, the caller already has the producer in question, but the callee ends up looking up that value again via the VC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3191) Confusion with HTTP_TUNNEL_STATIC_PRODUCER
[ https://issues.apache.org/jira/browse/TS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs resolved TS-3191. Resolution: Fixed Confusion with HTTP_TUNNEL_STATIC_PRODUCER -- Key: TS-3191 URL: https://issues.apache.org/jira/browse/TS-3191 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 In the HttpTunnel processing, normally a producer has a VC associated with it. The VC is used to lookup the producer via the HttpTunnel::get_producer method out of the HttpTunnel producer array. All is well and good, but in the case of a static producer, there is no vc. Rather the constant HTTP_TUNNEL_STATIC_PRODUCER is used in lieu of the vc. If there is only only one static producer all is still well, get_producer will return the one producer associated with HTTP_TUNNEL_STATIC_PRODUCER. But if there is more than one static producer involved with the tunnel, get_producer() will only return one producer. Both static consumers will only interact with one of the static producers and things will go down hill from here. I ran into this case while chasing down crashes via TS-3105, so this situation does come up in the wild. I fixed it by clearing out the tunnel before starting a static producer and making some other checks along the way. We could also avoid some calls to get_producer since it many cases, the caller already has the producer in question, but the callee ends up looking up that value again via the VC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3105) Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond
[ https://issues.apache.org/jira/browse/TS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-3105. -- Resolution: Fixed The four sub-issues that we created out of this bug have had fixes committed to 5.2.0. Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond Key: TS-3105 URL: https://issues.apache.org/jira/browse/TS-3105 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 Attachments: ts-3073-and-3084-and-3105-and-3155-against-510-15.patch, ts-3105-master-7.patch, ts-3105-master-9.patch These two patches were run in a production environment on top of 5.0.1 without problem for several weeks. Now running with these patches on top of 5.1 causes either an assert or a segfault. Another person has reported the same segfault when running master in a production environment. In the assert, the handler_state of the producers is 0 (UNKNOWN) rather than a terminal state which is expected. I'm assuming either we are being directed into the terminal state from a connection that terminates too quickly. Or an event has hung around for too long and is being executed against the state machine after it has been recycled. The event is HTTP_TUNNEL_EVENT_DONE The assert stack trace is FATAL: HttpSM.cc:2632: failed assert `0` /z/bin/traffic_server - STACK TRACE: /z/lib/libtsutil.so.5(+0x25197)[0x2b8bd08dc197] /z/lib/libtsutil.so.5(+0x23def)[0x2b8bd08dadef] /z/bin/traffic_server(HttpSM::tunnel_handler_post_or_put(HttpTunnelProducer*)+0xcd)[0x5982ad] /z/bin/traffic_server(HttpSM::tunnel_handler_post(int, void*)+0x86)[0x5a32d6] /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5a1e18] /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0xee)[0x5dd6ae] /z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, EThread*)+0x136e)[0x721d1e] /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x28c)[0x7162fc] /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] /z/bin/traffic_server(EThread::execute()+0x4fc)[0x7458ac] /z/bin/traffic_server[0x7440ca] /lib64/libpthread.so.0(+0x7034)[0x2b8bd1ee4034] /lib64/libc.so.6(clone+0x6d)[0x2b8bd2c2875d] The segfault stack trace is /z/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf280)[0x2abccd0d8280] /z/bin/traffic_server(HttpSM::tunnel_handler_ua(int, HttpTunnelConsumer*)+0x122)[0x591462] /z/bin/traffic_server(HttpTunnel::consumer_handler(int, HttpTunnelConsumer*)+0x9e)[0x5dd15e] /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x117)[0x5dd6d7] /z/bin/traffic_server(UnixNetVConnection::mainEvent(int, Event*)+0x3f0)[0x725190] /z/bin/traffic_server(InactivityCop::check_inactivity(int, Event*)+0x275)[0x716b75] /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] /z/bin/traffic_server(EThread::execute()+0x2fb)[0x7456ab] /z/bin/traffic_server[0x7440ca] /lib64/libpthread.so.0(+0x7034)[0x2abccd0d0034] /lib64/libc.so.6(clone+0x6d)[0x2abccde1475d] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3191) Confusion with HTTP_TUNNEL_STATIC_PRODUCER
[ https://issues.apache.org/jira/browse/TS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14220959#comment-14220959 ] ASF GitHub Bot commented on TS-3191: Github user shinrich closed the pull request at: https://github.com/apache/trafficserver/pull/145 Confusion with HTTP_TUNNEL_STATIC_PRODUCER -- Key: TS-3191 URL: https://issues.apache.org/jira/browse/TS-3191 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 In the HttpTunnel processing, normally a producer has a VC associated with it. The VC is used to lookup the producer via the HttpTunnel::get_producer method out of the HttpTunnel producer array. All is well and good, but in the case of a static producer, there is no vc. Rather the constant HTTP_TUNNEL_STATIC_PRODUCER is used in lieu of the vc. If there is only only one static producer all is still well, get_producer will return the one producer associated with HTTP_TUNNEL_STATIC_PRODUCER. But if there is more than one static producer involved with the tunnel, get_producer() will only return one producer. Both static consumers will only interact with one of the static producers and things will go down hill from here. I ran into this case while chasing down crashes via TS-3105, so this situation does come up in the wild. I fixed it by clearing out the tunnel before starting a static producer and making some other checks along the way. We could also avoid some calls to get_producer since it many cases, the caller already has the producer in question, but the callee ends up looking up that value again via the VC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3191) Confusion with HTTP_TUNNEL_STATIC_PRODUCER
[ https://issues.apache.org/jira/browse/TS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14220958#comment-14220958 ] ASF GitHub Bot commented on TS-3191: Github user shinrich commented on the pull request: https://github.com/apache/trafficserver/pull/145#issuecomment-63975572 We ended up leaving in the kill_tunnel in HttpSM::kill_this(). TS-1527 is fixed by this addition as well as the issue I was seeing here. The possibility of double do_io_closes() is disturbing, but that seems to happen elsewhere as well. If it is in the same invocation stream it is safe (just resetting the close flag). Should be investigated in more depth though. Based on what we were seeing in production and the little bit of gdb investigation that Alan did, the keep_alive connections are not affected, but again, we should investigate in more detail and perhaps add a test case to the integration test set to verify that shutting down the SM does not destroy the keep alive connections. Confusion with HTTP_TUNNEL_STATIC_PRODUCER -- Key: TS-3191 URL: https://issues.apache.org/jira/browse/TS-3191 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 In the HttpTunnel processing, normally a producer has a VC associated with it. The VC is used to lookup the producer via the HttpTunnel::get_producer method out of the HttpTunnel producer array. All is well and good, but in the case of a static producer, there is no vc. Rather the constant HTTP_TUNNEL_STATIC_PRODUCER is used in lieu of the vc. If there is only only one static producer all is still well, get_producer will return the one producer associated with HTTP_TUNNEL_STATIC_PRODUCER. But if there is more than one static producer involved with the tunnel, get_producer() will only return one producer. Both static consumers will only interact with one of the static producers and things will go down hill from here. I ran into this case while chasing down crashes via TS-3105, so this situation does come up in the wild. I fixed it by clearing out the tunnel before starting a static producer and making some other checks along the way. We could also avoid some calls to get_producer since it many cases, the caller already has the producer in question, but the callee ends up looking up that value again via the VC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3100) Extend the tr-pass window to allow malformed HTTP commands to be blind tunneled
[ https://issues.apache.org/jira/browse/TS-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3100: --- Attachment: ts-3100.diff Extend the tr-pass window to allow malformed HTTP commands to be blind tunneled --- Key: TS-3100 URL: https://issues.apache.org/jira/browse/TS-3100 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.3.0 Attachments: ts-3100.diff Some servers abuse the HTTP protocol to implement services. ATS certainly should not cache responses from malformed GET, POST, etc, it should get out of the way if possible and pass the traffic along if the customer has marked the port with tr-pass. As the code is currently written, it will make the tr-pass blind tunnel decision if the initial request does not parse. But if the initial request does parse but the specification violation occurs later, the tr-pass decision is not revisited. One ISP using ATS has reported the following scenarios. The client sends a well formed GET request. Then after the double carriage return line feeds, it sends some additional text. The server interprets this as additional requests for information. Since the GET request was well formed, the connection is put on the HTTP path and the extra data after the carriage return line feeds is stripped before it is passed along to the server. At a minimum, I want to revisit tr-pass decision after the header has been parsed and the carriage return line feeds have been read in the GET case. If the connection is not set to pipeline requests and there is more data in the buffer, pass the connection on to be blind tunneled. I plan to review the POST and PUT paths for other early options for tr-pass evaluations too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2911) Custom Thread Pools
[ https://issues.apache.org/jira/browse/TS-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221004#comment-14221004 ] Phil Sorber commented on TS-2911: - Yes, and cache thrashing, and context switches, and memory access. Custom Thread Pools --- Key: TS-2911 URL: https://issues.apache.org/jira/browse/TS-2911 Project: Traffic Server Issue Type: New Feature Components: Core, Performance Reporter: Luca Rea Request feature to support adding new thread pools and assign them to groups of inbound listeners and oubound parents or domains -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2911) Custom Thread Pools
[ https://issues.apache.org/jira/browse/TS-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221021#comment-14221021 ] Luca Rea commented on TS-2911: -- Ok, I'm in your hands :) Custom Thread Pools --- Key: TS-2911 URL: https://issues.apache.org/jira/browse/TS-2911 Project: Traffic Server Issue Type: New Feature Components: Core, Performance Reporter: Luca Rea Request feature to support adding new thread pools and assign them to groups of inbound listeners and oubound parents or domains -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2911) Custom Thread Pools
[ https://issues.apache.org/jira/browse/TS-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221107#comment-14221107 ] Leif Hedstrom commented on TS-2911: --- When we discussed this earlier this week, one thought was that this request generally feels more like a prioritization request. Something like if the box is under pressure, prefer requests to / from this set of clients or servers over others, where pressure is undefined now, but e.g. Network saturation, CPU utilization (seems unlikely), RAM etc. Also, better control over things like cache, connection counts to origin etc. would also help I think. Custom Thread Pools --- Key: TS-2911 URL: https://issues.apache.org/jira/browse/TS-2911 Project: Traffic Server Issue Type: New Feature Components: Core, Performance Reporter: Luca Rea Request feature to support adding new thread pools and assign them to groups of inbound listeners and oubound parents or domains -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2680) Occasional crash in HdrHeap
[ https://issues.apache.org/jira/browse/TS-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221141#comment-14221141 ] Peter Walsh commented on TS-2680: - Hello, Yes we are planning on upgrading soon, I will see if this problem goes away. Occasional crash in HdrHeap --- Key: TS-2680 URL: https://issues.apache.org/jira/browse/TS-2680 Project: Traffic Server Issue Type: Bug Reporter: Peter Walsh Labels: crash Fix For: sometime Every few days we are seeing a crash in HdrHeap. We have not been able to reproduce in test environments, but will attach additional information when we do. NOTE: Traffic Server received Sig 11: Segmentation fault /usr/local/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0[0x3583c0eca0] /usr/local/bin/traffic_server(HdrHeap::attach_block(IOBufferBlock*, char const*)+0x80)[0x5c13f0] /usr/local/bin/traffic_server(HTTPHdr::parse_resp(HTTPParser*, IOBufferReader*, int*, bool)+0x15d)[0x5c15fd] /usr/local/bin/traffic_server(HttpSM::state_read_server_response_header(int, void*)+0x138)[0x52eea8] /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xdc)[0x530fec] /usr/local/bin/traffic_server[0x69415b] /usr/local/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x479)[0x68a2c9] /usr/local/bin/traffic_server(EThread::process_event(Event*, int)+0x22f)[0x6b9bbf] /usr/local/bin/traffic_server(EThread::execute()+0x5bc)[0x6ba4cc] /usr/local/bin/traffic_server[0x6b900e] /lib64/libpthread.so.0[0x3583c0683d] /lib64/libc.so.6(clone+0x6d)[0x35834d526d] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2911) Custom Thread Pools
[ https://issues.apache.org/jira/browse/TS-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221324#comment-14221324 ] Phil Sorber commented on TS-2911: - So where does this leave us in regards to this ticket? Are there features here to implement that are compatible with our future road map for NUMA? Custom Thread Pools --- Key: TS-2911 URL: https://issues.apache.org/jira/browse/TS-2911 Project: Traffic Server Issue Type: New Feature Components: Core, Performance Reporter: Luca Rea Request feature to support adding new thread pools and assign them to groups of inbound listeners and oubound parents or domains -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3108) Add port matching condition to header_rewrite
[
https://issues.apache.org/jira/browse/TS-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221473#comment-14221473
]
Phil Sorber commented on TS-3108:
-
[~jpe...@apache.org] make the following observations:
{quote}
I think SERVER-PORT would be clearer ... also it would not take long to add
CLIENT-PORT and SERVER-IP, so make it symmetric :)
{quote}
Add port matching condition to header_rewrite
-
Key: TS-3108
URL: https://issues.apache.org/jira/browse/TS-3108
Project: Traffic Server
Issue Type: New Feature
Reporter: Phil Sorber
Assignee: Phil Sorber
Priority: Critical
Fix For: 5.2.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3108) Add port matching condition to header_rewrite
[
https://issues.apache.org/jira/browse/TS-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221473#comment-14221473
]
Phil Sorber edited comment on TS-3108 at 11/21/14 9:59 PM:
---
[~jpe...@apache.org] made the following observations:
{quote}
I think SERVER-PORT would be clearer ... also it would not take long to add
CLIENT-PORT and SERVER-IP, so make it symmetric :)
{quote}
was (Author: psudaemon):
[~jpe...@apache.org] make the following observations:
{quote}
I think SERVER-PORT would be clearer ... also it would not take long to add
CLIENT-PORT and SERVER-IP, so make it symmetric :)
{quote}
Add port matching condition to header_rewrite
-
Key: TS-3108
URL: https://issues.apache.org/jira/browse/TS-3108
Project: Traffic Server
Issue Type: New Feature
Reporter: Phil Sorber
Assignee: Phil Sorber
Priority: Critical
Fix For: 5.2.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3205) ASAN complaints on config reload freeing malloc'ed memory with delete[]
[ https://issues.apache.org/jira/browse/TS-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3205: -- Fix Version/s: 5.2.0 ASAN complaints on config reload freeing malloc'ed memory with delete[] --- Key: TS-3205 URL: https://issues.apache.org/jira/browse/TS-3205 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Fix For: 5.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3205) ASAN complaints on config reload freeing malloc'ed memory with delete[]
Leif Hedstrom created TS-3205: - Summary: ASAN complaints on config reload freeing malloc'ed memory with delete[] Key: TS-3205 URL: https://issues.apache.org/jira/browse/TS-3205 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3205) ASAN complaints on config reload freeing malloc'ed memory with delete[]
[ https://issues.apache.org/jira/browse/TS-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-3205: - Assignee: Leif Hedstrom ASAN complaints on config reload freeing malloc'ed memory with delete[] --- Key: TS-3205 URL: https://issues.apache.org/jira/browse/TS-3205 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: ASAN Fix For: 5.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3205) ASAN complaints on config reload freeing malloc'ed memory with delete[]
[ https://issues.apache.org/jira/browse/TS-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3205: -- Labels: ASAN (was: ) ASAN complaints on config reload freeing malloc'ed memory with delete[] --- Key: TS-3205 URL: https://issues.apache.org/jira/browse/TS-3205 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Labels: ASAN Fix For: 5.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3205) ASAN complaints on config reload freeing malloc'ed memory with delete[]
[ https://issues.apache.org/jira/browse/TS-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221596#comment-14221596 ] ASF subversion and git services commented on TS-3205: - Commit c135dbf1bb58a4b15c18e898e8706abbc7c6436d in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c135dbf ] TS-3205 ASAN complaints on config reload freeing malloc'ed memory with delete[] ASAN complaints on config reload freeing malloc'ed memory with delete[] --- Key: TS-3205 URL: https://issues.apache.org/jira/browse/TS-3205 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: ASAN Fix For: 5.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3206) CK does not seem to honor the --enable-ccache option
Leif Hedstrom created TS-3206: - Summary: CK does not seem to honor the --enable-ccache option Key: TS-3206 URL: https://issues.apache.org/jira/browse/TS-3206 Project: Traffic Server Issue Type: Bug Components: CK Reporter: Leif Hedstrom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3206) CK does not seem to honor the --enable-ccache option
[ https://issues.apache.org/jira/browse/TS-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3206: -- Fix Version/s: 5.3.0 CK does not seem to honor the --enable-ccache option Key: TS-3206 URL: https://issues.apache.org/jira/browse/TS-3206 Project: Traffic Server Issue Type: Bug Components: CK Reporter: Leif Hedstrom Assignee: Phil Sorber Fix For: 5.3.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3206) CK does not seem to honor the --enable-ccache option
[ https://issues.apache.org/jira/browse/TS-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3206: -- Assignee: Phil Sorber CK does not seem to honor the --enable-ccache option Key: TS-3206 URL: https://issues.apache.org/jira/browse/TS-3206 Project: Traffic Server Issue Type: Bug Components: CK Reporter: Leif Hedstrom Assignee: Phil Sorber Fix For: 5.3.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3207) _xstrdup incorrectly calls ink_strlcpy with zero length strings
[ https://issues.apache.org/jira/browse/TS-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3207: -- Fix Version/s: 5.2.0 _xstrdup incorrectly calls ink_strlcpy with zero length strings Key: TS-3207 URL: https://issues.apache.org/jira/browse/TS-3207 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Brian Geffon Fix For: 5.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3207) _xstrdup incorrectly calls ink_strlcpy with zero length strings
[ https://issues.apache.org/jira/browse/TS-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3207: -- Assignee: Brian Geffon _xstrdup incorrectly calls ink_strlcpy with zero length strings Key: TS-3207 URL: https://issues.apache.org/jira/browse/TS-3207 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Brian Geffon Fix For: 5.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3207) _xstrdup incorrectly calls ink_strlcpy with zero length strings
Leif Hedstrom created TS-3207: - Summary: _xstrdup incorrectly calls ink_strlcpy with zero length strings Key: TS-3207 URL: https://issues.apache.org/jira/browse/TS-3207 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3207) _xstrdup incorrectly calls ink_strlcpy with zero length strings
[ https://issues.apache.org/jira/browse/TS-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221734#comment-14221734 ] ASF subversion and git services commented on TS-3207: - Commit a6fb93a3deb69844cf08ee8775c7d68d30dabd68 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a6fb93a ] Added TS-3207. _xstrdup incorrectly calls ink_strlcpy with zero length strings Key: TS-3207 URL: https://issues.apache.org/jira/browse/TS-3207 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Brian Geffon Fix For: 5.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3207) _xstrdup incorrectly calls ink_strlcpy with zero length strings
[ https://issues.apache.org/jira/browse/TS-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom closed TS-3207. - Resolution: Fixed _xstrdup incorrectly calls ink_strlcpy with zero length strings Key: TS-3207 URL: https://issues.apache.org/jira/browse/TS-3207 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Brian Geffon Fix For: 5.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3208) clang warnings on || 1
[
https://issues.apache.org/jira/browse/TS-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3208:
--
Backport to Version: 5.2.0
clang warnings on || 1
--
Key: TS-3208
URL: https://issues.apache.org/jira/browse/TS-3208
Project: Traffic Server
Issue Type: Bug
Components: Management API
Reporter: Leif Hedstrom
Fix For: 5.3.0
{code}
CoreAPI.cc:368:187: warning: use of logical '||' with constant operand
[-Wconstant-logical-operand]
if ((threads).n) for (pid_t *qq__threadid = (pid_t*)0, threadid =
(threads).v[0]; ((uintptr_t)(qq__threadid) (threads).length())
((threadid = (threads).v[(intptr_t)qq__threadid]) || 1); qq__threadid =
(pid_t*)(((intptr_t)qq__threadid) + 1)) {
^ ~
CoreAPI.cc:368:187: note: use '|' for a bitwise operation
if ((threads).n) for (pid_t *qq__threadid = (pid_t*)0, threadid =
(threads).v[0]; ((uintptr_t)(qq__threadid) (threads).length())
((threadid = (threads).v[(intptr_t)qq__threadid]) || 1); qq__threadid =
(pid_t*)(((intptr_t)qq__threadid) + 1)) {
^~
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3209) clang warnings compiling the secure-link example plugin
Leif Hedstrom created TS-3209: - Summary: clang warnings compiling the secure-link example plugin Key: TS-3209 URL: https://issues.apache.org/jira/browse/TS-3209 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3209) clang warnings compiling the secure-link example plugin
[
https://issues.apache.org/jira/browse/TS-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-3209:
-
Assignee: Leif Hedstrom
clang warnings compiling the secure-link example plugin
---
Key: TS-3209
URL: https://issues.apache.org/jira/browse/TS-3209
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.3.0
{code}
CC secure-link/secure-link.lo
secure-link/secure-link.c:69:1973: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
if(__extension__ ({ size_t __s1_len, __s2_len;
(__builtin_constant_p (ptr) __builtin_constant_p (st) (__s1_len =
strlen (ptr), __s2_len = strlen (st), (!((size_t)(const void *)((ptr) + 1)
- (size_t)(const void *)(ptr) == 1) || __s1_len = 4) (!((size_t)(const
void *)((st) + 1) - (size_t)(const void *)(st) == 1) || __s2_len = 4)) ?
__builtin_strcmp (ptr, st) : (__builtin_constant_p (ptr) ((size_t)(const
void *)((ptr) + 1) - (size_t)(const void *)(ptr) == 1) (__s1_len = strlen
(ptr), __s1_len 4) ? (__builtin_constant_p (st) ((size_t)(const void
*)((st) + 1) - (size_t)(const void *)(st) == 1) ? __builtin_strcmp (ptr,
st) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *)
(const char *) (st); int __result = (((const unsigned char *) (const char
*) (ptr))[0] - __s2[0]); if (__s1_len 0 __result == 0) { __result =
(((const unsigned char *) (const char *) (ptr))[1] - __s2[1]); if (__s1_len
1 __result == 0) { __result = (((const unsigned char *) (const char *)
(ptr))[2] - __s2[2]); if (__s1_len 2 __result == 0) __result = (((const
unsigned char *) (const char *) (ptr))[3] - __s2[3]); } } __result; }))) :
(__builtin_constant_p (st) ((size_t)(const void *)((st) + 1) -
(size_t)(const void *)(st) == 1) (__s2_len = strlen (st), __s2_len
4) ? (__builtin_constant_p (ptr) ((size_t)(const void *)((ptr) + 1) -
(size_t)(const void *)(ptr) == 1) ? __builtin_strcmp (ptr, st) : (-
(__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
char *) (ptr); int __result = (((const unsigned char *) (const char *)
(st))[0] - __s2[0]); if (__s2_len 0 __result == 0) { __result =
(((const unsigned char *) (const char *) (st))[1] - __s2[1]); if (__s2_len
1 __result == 0) { __result = (((const unsigned char *) (const char *)
(st))[2] - __s2[2]); if (__s2_len 2 __result == 0) __result = (((const
unsigned char *) (const char *) (st))[3] - __s2[3]); } } __result; } :
__builtin_strcmp (ptr, st; }) == 0) {
^ ~
secure-link/secure-link.c:71:1980: warning: array index 3 is past the end of
the array (which contains 3 elements)
[jira] [Updated] (TS-3209) clang warnings compiling the secure-link example plugin
[
https://issues.apache.org/jira/browse/TS-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3209:
--
Description:
{code}
CC secure-link/secure-link.lo
secure-link/secure-link.c:69:1973: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
if(__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p
(ptr) __builtin_constant_p (st) (__s1_len = strlen (ptr), __s2_len =
strlen (st), (!((size_t)(const void *)((ptr) + 1) - (size_t)(const void
*)(ptr) == 1) || __s1_len = 4) (!((size_t)(const void *)((st) + 1) -
(size_t)(const void *)(st) == 1) || __s2_len = 4)) ? __builtin_strcmp (ptr,
st) : (__builtin_constant_p (ptr) ((size_t)(const void *)((ptr) + 1) -
(size_t)(const void *)(ptr) == 1) (__s1_len = strlen (ptr), __s1_len 4) ?
(__builtin_constant_p (st) ((size_t)(const void *)((st) + 1) -
(size_t)(const void *)(st) == 1) ? __builtin_strcmp (ptr, st) :
(__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
char *) (st); int __result = (((const unsigned char *) (const char *)
(ptr))[0] - __s2[0]); if (__s1_len 0 __result == 0) { __result = (((const
unsigned char *) (const char *) (ptr))[1] - __s2[1]); if (__s1_len 1
__result == 0) { __result = (((const unsigned char *) (const char *) (ptr))[2]
- __s2[2]); if (__s1_len 2 __result == 0) __result = (((const unsigned
char *) (const char *) (ptr))[3] - __s2[3]); } } __result; }))) :
(__builtin_constant_p (st) ((size_t)(const void *)((st) + 1) -
(size_t)(const void *)(st) == 1) (__s2_len = strlen (st), __s2_len 4)
? (__builtin_constant_p (ptr) ((size_t)(const void *)((ptr) + 1) -
(size_t)(const void *)(ptr) == 1) ? __builtin_strcmp (ptr, st) : (-
(__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
char *) (ptr); int __result = (((const unsigned char *) (const char *)
(st))[0] - __s2[0]); if (__s2_len 0 __result == 0) { __result = (((const
unsigned char *) (const char *) (st))[1] - __s2[1]); if (__s2_len 1
__result == 0) { __result = (((const unsigned char *) (const char *) (st))[2]
- __s2[2]); if (__s2_len 2 __result == 0) __result = (((const unsigned
char *) (const char *) (st))[3] - __s2[3]); } } __result; } :
__builtin_strcmp (ptr, st; }) == 0) {
^ ~
secure-link/secure-link.c:71:1980: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
} else if(__extension__ ({ size_t __s1_len, __s2_len;
(__builtin_constant_p (ptr) __builtin_constant_p (ex) (__s1_len =
strlen (ptr), __s2_len = strlen (ex), (!((size_t)(const void *)((ptr) + 1) -
(size_t)(const void *)(ptr) == 1) || __s1_len = 4) (!((size_t)(const void
*)((ex) + 1) - (size_t)(const void *)(ex) == 1) || __s2_len = 4)) ?
__builtin_strcmp (ptr, ex) : (__builtin_constant_p (ptr) ((size_t)(const
void *)((ptr) + 1) - (size_t)(const
[jira] [Updated] (TS-3209) clang warnings compiling the secure-link example plugin
[
https://issues.apache.org/jira/browse/TS-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3209:
--
Fix Version/s: 5.3.0
clang warnings compiling the secure-link example plugin
---
Key: TS-3209
URL: https://issues.apache.org/jira/browse/TS-3209
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Leif Hedstrom
Fix For: 5.3.0
{code}
CC secure-link/secure-link.lo
secure-link/secure-link.c:69:1973: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
if(__extension__ ({ size_t __s1_len, __s2_len;
(__builtin_constant_p (ptr) __builtin_constant_p (st) (__s1_len =
strlen (ptr), __s2_len = strlen (st), (!((size_t)(const void *)((ptr) + 1)
- (size_t)(const void *)(ptr) == 1) || __s1_len = 4) (!((size_t)(const
void *)((st) + 1) - (size_t)(const void *)(st) == 1) || __s2_len = 4)) ?
__builtin_strcmp (ptr, st) : (__builtin_constant_p (ptr) ((size_t)(const
void *)((ptr) + 1) - (size_t)(const void *)(ptr) == 1) (__s1_len = strlen
(ptr), __s1_len 4) ? (__builtin_constant_p (st) ((size_t)(const void
*)((st) + 1) - (size_t)(const void *)(st) == 1) ? __builtin_strcmp (ptr,
st) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *)
(const char *) (st); int __result = (((const unsigned char *) (const char
*) (ptr))[0] - __s2[0]); if (__s1_len 0 __result == 0) { __result =
(((const unsigned char *) (const char *) (ptr))[1] - __s2[1]); if (__s1_len
1 __result == 0) { __result = (((const unsigned char *) (const char *)
(ptr))[2] - __s2[2]); if (__s1_len 2 __result == 0) __result = (((const
unsigned char *) (const char *) (ptr))[3] - __s2[3]); } } __result; }))) :
(__builtin_constant_p (st) ((size_t)(const void *)((st) + 1) -
(size_t)(const void *)(st) == 1) (__s2_len = strlen (st), __s2_len
4) ? (__builtin_constant_p (ptr) ((size_t)(const void *)((ptr) + 1) -
(size_t)(const void *)(ptr) == 1) ? __builtin_strcmp (ptr, st) : (-
(__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
char *) (ptr); int __result = (((const unsigned char *) (const char *)
(st))[0] - __s2[0]); if (__s2_len 0 __result == 0) { __result =
(((const unsigned char *) (const char *) (st))[1] - __s2[1]); if (__s2_len
1 __result == 0) { __result = (((const unsigned char *) (const char *)
(st))[2] - __s2[2]); if (__s2_len 2 __result == 0) __result = (((const
unsigned char *) (const char *) (st))[3] - __s2[3]); } } __result; } :
__builtin_strcmp (ptr, st; }) == 0) {
^ ~
secure-link/secure-link.c:71:1980: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
} else
[jira] [Updated] (TS-3209) clang warnings compiling the secure-link example plugin
[
https://issues.apache.org/jira/browse/TS-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3209:
--
Assignee: (was: Leif Hedstrom)
clang warnings compiling the secure-link example plugin
---
Key: TS-3209
URL: https://issues.apache.org/jira/browse/TS-3209
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Leif Hedstrom
Fix For: 5.3.0
{code}
CC secure-link/secure-link.lo
secure-link/secure-link.c:69:1973: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
if(__extension__ ({ size_t __s1_len, __s2_len;
(__builtin_constant_p (ptr) __builtin_constant_p (st) (__s1_len =
strlen (ptr), __s2_len = strlen (st), (!((size_t)(const void *)((ptr) + 1)
- (size_t)(const void *)(ptr) == 1) || __s1_len = 4) (!((size_t)(const
void *)((st) + 1) - (size_t)(const void *)(st) == 1) || __s2_len = 4)) ?
__builtin_strcmp (ptr, st) : (__builtin_constant_p (ptr) ((size_t)(const
void *)((ptr) + 1) - (size_t)(const void *)(ptr) == 1) (__s1_len = strlen
(ptr), __s1_len 4) ? (__builtin_constant_p (st) ((size_t)(const void
*)((st) + 1) - (size_t)(const void *)(st) == 1) ? __builtin_strcmp (ptr,
st) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *)
(const char *) (st); int __result = (((const unsigned char *) (const char
*) (ptr))[0] - __s2[0]); if (__s1_len 0 __result == 0) { __result =
(((const unsigned char *) (const char *) (ptr))[1] - __s2[1]); if (__s1_len
1 __result == 0) { __result = (((const unsigned char *) (const char *)
(ptr))[2] - __s2[2]); if (__s1_len 2 __result == 0) __result = (((const
unsigned char *) (const char *) (ptr))[3] - __s2[3]); } } __result; }))) :
(__builtin_constant_p (st) ((size_t)(const void *)((st) + 1) -
(size_t)(const void *)(st) == 1) (__s2_len = strlen (st), __s2_len
4) ? (__builtin_constant_p (ptr) ((size_t)(const void *)((ptr) + 1) -
(size_t)(const void *)(ptr) == 1) ? __builtin_strcmp (ptr, st) : (-
(__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
char *) (ptr); int __result = (((const unsigned char *) (const char *)
(st))[0] - __s2[0]); if (__s2_len 0 __result == 0) { __result =
(((const unsigned char *) (const char *) (st))[1] - __s2[1]); if (__s2_len
1 __result == 0) { __result = (((const unsigned char *) (const char *)
(st))[2] - __s2[2]); if (__s2_len 2 __result == 0) __result = (((const
unsigned char *) (const char *) (st))[3] - __s2[3]); } } __result; } :
__builtin_strcmp (ptr, st; }) == 0) {
^ ~
secure-link/secure-link.c:71:1980: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
}
[jira] [Updated] (TS-3209) clang warnings compiling the secure-link example plugin
[
https://issues.apache.org/jira/browse/TS-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3209:
--
Backport to Version: 5.2.0
clang warnings compiling the secure-link example plugin
---
Key: TS-3209
URL: https://issues.apache.org/jira/browse/TS-3209
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Leif Hedstrom
Fix For: 5.3.0
{code}
CC secure-link/secure-link.lo
secure-link/secure-link.c:69:1973: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
if(__extension__ ({ size_t __s1_len, __s2_len;
(__builtin_constant_p (ptr) __builtin_constant_p (st) (__s1_len =
strlen (ptr), __s2_len = strlen (st), (!((size_t)(const void *)((ptr) + 1)
- (size_t)(const void *)(ptr) == 1) || __s1_len = 4) (!((size_t)(const
void *)((st) + 1) - (size_t)(const void *)(st) == 1) || __s2_len = 4)) ?
__builtin_strcmp (ptr, st) : (__builtin_constant_p (ptr) ((size_t)(const
void *)((ptr) + 1) - (size_t)(const void *)(ptr) == 1) (__s1_len = strlen
(ptr), __s1_len 4) ? (__builtin_constant_p (st) ((size_t)(const void
*)((st) + 1) - (size_t)(const void *)(st) == 1) ? __builtin_strcmp (ptr,
st) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *)
(const char *) (st); int __result = (((const unsigned char *) (const char
*) (ptr))[0] - __s2[0]); if (__s1_len 0 __result == 0) { __result =
(((const unsigned char *) (const char *) (ptr))[1] - __s2[1]); if (__s1_len
1 __result == 0) { __result = (((const unsigned char *) (const char *)
(ptr))[2] - __s2[2]); if (__s1_len 2 __result == 0) __result = (((const
unsigned char *) (const char *) (ptr))[3] - __s2[3]); } } __result; }))) :
(__builtin_constant_p (st) ((size_t)(const void *)((st) + 1) -
(size_t)(const void *)(st) == 1) (__s2_len = strlen (st), __s2_len
4) ? (__builtin_constant_p (ptr) ((size_t)(const void *)((ptr) + 1) -
(size_t)(const void *)(ptr) == 1) ? __builtin_strcmp (ptr, st) : (-
(__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
char *) (ptr); int __result = (((const unsigned char *) (const char *)
(st))[0] - __s2[0]); if (__s2_len 0 __result == 0) { __result =
(((const unsigned char *) (const char *) (st))[1] - __s2[1]); if (__s2_len
1 __result == 0) { __result = (((const unsigned char *) (const char *)
(st))[2] - __s2[2]); if (__s2_len 2 __result == 0) __result = (((const
unsigned char *) (const char *) (st))[3] - __s2[3]); } } __result; } :
__builtin_strcmp (ptr, st; }) == 0) {
^ ~
secure-link/secure-link.c:71:1980: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
} else
[jira] [Resolved] (TS-3205) ASAN complaints on config reload freeing malloc'ed memory with delete[]
[ https://issues.apache.org/jira/browse/TS-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-3205. --- Resolution: Fixed ASAN complaints on config reload freeing malloc'ed memory with delete[] --- Key: TS-3205 URL: https://issues.apache.org/jira/browse/TS-3205 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: ASAN Fix For: 5.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3053) enable-linux-native-aio crash
[
https://issues.apache.org/jira/browse/TS-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221763#comment-14221763
]
bettydramit commented on TS-3053:
-
why close this issue?
enable-linux-native-aio crash
-
Key: TS-3053
URL: https://issues.apache.org/jira/browse/TS-3053
Project: Traffic Server
Issue Type: Bug
Reporter: Qiang Li
configure with --enable-linux-native-aio it will crash sometime
{code}
(gdb) bt
#0 enqueue (op=0x2aaae465ecc0) at ../../lib/ts/List.h:290
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
#2 0x006ca458 in CacheVC::handleRead (this=0x2aaae465eb40) at
Cache.cc:2756
#3 0x006ef52e in Cache::open_read (this=value optimized out,
cont=0x2aaaf0101a30, key=value optimized out, request=0x2aaaf0100708,
params=0x2aaaf01000e0, type=value optimized out,
hostname=0x2aaaf0240073
cdn.u1.huluxia.comhttpg1/M00/0C/8D/wKgBB1QAtUOAXXj-AAARZtl9MXk020.jpg_160x160.jpegcdn.u1.huluxia.com\377,
host_len=18)
at CacheRead.cc:136
#4 0x006ccf6d in open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1083
#5 CacheProcessor::open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3600
#6 0x00588d94 in do_cache_open_read (this=value optimized out,
url=value optimized out, hdr=value optimized out,
params=value optimized out, pin_in_cache=value optimized out) at
HttpCacheSM.cc:216
#7 HttpCacheSM::open_read (this=value optimized out, url=value optimized
out, hdr=value optimized out, params=value optimized out,
pin_in_cache=value optimized out) at HttpCacheSM.cc:248
#8 0x005961e3 in HttpSM::do_cache_lookup_and_read
(this=0x2aaaf010) at HttpSM.cc:4330
#9 0x005af784 in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6992
#10 0x005a8ec2 in HttpSM::handle_api_return (this=0x2aaaf010) at
HttpSM.cc:1509
#11 0x005a95c0 in HttpSM::state_api_callout (this=0x2aaaf010,
event=0, data=0x0) at HttpSM.cc:1441
#12 0x005af26a in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6882
#13 0x0059563e in HttpSM::state_remap_request (this=0x2aaaf010,
event=63002) at HttpSM.cc:3826
#14 0x005ac598 in HttpSM::main_handler (this=0x2aaaf010,
event=63002, data=0x0) at HttpSM.cc:2546
#15 0x00605c3a in handleEvent (this=0x2aaacc548000, event=1,
e=0x2aaaf024ed20) at ../../../iocore/eventsystem/I_Continuation.h:146
#16 RemapPlugins::run_remap (this=0x2aaacc548000, event=1, e=0x2aaaf024ed20)
at RemapPlugins.cc:180
#17 0x0074656f in handleEvent (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at I_Continuation.h:146
#18 EThread::process_event (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at UnixEThread.cc:144
#19 0x00746edb in EThread::execute (this=0x2afd7171f010) at
UnixEThread.cc:195
#20 0x0074590a in spawn_thread_internal (a=0x1b86300) at Thread.cc:88
#21 0x2afd68f2e9d1 in start_thread () from /lib64/libpthread.so.0
#22 0x2afd69f24b6d in clone () from /lib64/libc.so.6
(gdb) f 1
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
611 t-diskHandler-ready_list.enqueue(op);
(gdb) p t-diskHandler
$1 = (DiskHandler *) 0x0
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3053) enable-linux-native-aio crash
[
https://issues.apache.org/jira/browse/TS-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221784#comment-14221784
]
Leif Hedstrom commented on TS-3053:
---
We believe it's a duplicate of another bug.
enable-linux-native-aio crash
-
Key: TS-3053
URL: https://issues.apache.org/jira/browse/TS-3053
Project: Traffic Server
Issue Type: Bug
Reporter: Qiang Li
configure with --enable-linux-native-aio it will crash sometime
{code}
(gdb) bt
#0 enqueue (op=0x2aaae465ecc0) at ../../lib/ts/List.h:290
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
#2 0x006ca458 in CacheVC::handleRead (this=0x2aaae465eb40) at
Cache.cc:2756
#3 0x006ef52e in Cache::open_read (this=value optimized out,
cont=0x2aaaf0101a30, key=value optimized out, request=0x2aaaf0100708,
params=0x2aaaf01000e0, type=value optimized out,
hostname=0x2aaaf0240073
cdn.u1.huluxia.comhttpg1/M00/0C/8D/wKgBB1QAtUOAXXj-AAARZtl9MXk020.jpg_160x160.jpegcdn.u1.huluxia.com\377,
host_len=18)
at CacheRead.cc:136
#4 0x006ccf6d in open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1083
#5 CacheProcessor::open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3600
#6 0x00588d94 in do_cache_open_read (this=value optimized out,
url=value optimized out, hdr=value optimized out,
params=value optimized out, pin_in_cache=value optimized out) at
HttpCacheSM.cc:216
#7 HttpCacheSM::open_read (this=value optimized out, url=value optimized
out, hdr=value optimized out, params=value optimized out,
pin_in_cache=value optimized out) at HttpCacheSM.cc:248
#8 0x005961e3 in HttpSM::do_cache_lookup_and_read
(this=0x2aaaf010) at HttpSM.cc:4330
#9 0x005af784 in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6992
#10 0x005a8ec2 in HttpSM::handle_api_return (this=0x2aaaf010) at
HttpSM.cc:1509
#11 0x005a95c0 in HttpSM::state_api_callout (this=0x2aaaf010,
event=0, data=0x0) at HttpSM.cc:1441
#12 0x005af26a in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6882
#13 0x0059563e in HttpSM::state_remap_request (this=0x2aaaf010,
event=63002) at HttpSM.cc:3826
#14 0x005ac598 in HttpSM::main_handler (this=0x2aaaf010,
event=63002, data=0x0) at HttpSM.cc:2546
#15 0x00605c3a in handleEvent (this=0x2aaacc548000, event=1,
e=0x2aaaf024ed20) at ../../../iocore/eventsystem/I_Continuation.h:146
#16 RemapPlugins::run_remap (this=0x2aaacc548000, event=1, e=0x2aaaf024ed20)
at RemapPlugins.cc:180
#17 0x0074656f in handleEvent (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at I_Continuation.h:146
#18 EThread::process_event (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at UnixEThread.cc:144
#19 0x00746edb in EThread::execute (this=0x2afd7171f010) at
UnixEThread.cc:195
#20 0x0074590a in spawn_thread_internal (a=0x1b86300) at Thread.cc:88
#21 0x2afd68f2e9d1 in start_thread () from /lib64/libpthread.so.0
#22 0x2afd69f24b6d in clone () from /lib64/libc.so.6
(gdb) f 1
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
611 t-diskHandler-ready_list.enqueue(op);
(gdb) p t-diskHandler
$1 = (DiskHandler *) 0x0
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3053) enable-linux-native-aio crash
[
https://issues.apache.org/jira/browse/TS-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221784#comment-14221784
]
Leif Hedstrom edited comment on TS-3053 at 11/22/14 3:05 AM:
-
We believe it's a duplicate of another bug. You are still seeing this with the
latest master tree ?
was (Author: zwoop):
We believe it's a duplicate of another bug.
enable-linux-native-aio crash
-
Key: TS-3053
URL: https://issues.apache.org/jira/browse/TS-3053
Project: Traffic Server
Issue Type: Bug
Reporter: Qiang Li
configure with --enable-linux-native-aio it will crash sometime
{code}
(gdb) bt
#0 enqueue (op=0x2aaae465ecc0) at ../../lib/ts/List.h:290
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
#2 0x006ca458 in CacheVC::handleRead (this=0x2aaae465eb40) at
Cache.cc:2756
#3 0x006ef52e in Cache::open_read (this=value optimized out,
cont=0x2aaaf0101a30, key=value optimized out, request=0x2aaaf0100708,
params=0x2aaaf01000e0, type=value optimized out,
hostname=0x2aaaf0240073
cdn.u1.huluxia.comhttpg1/M00/0C/8D/wKgBB1QAtUOAXXj-AAARZtl9MXk020.jpg_160x160.jpegcdn.u1.huluxia.com\377,
host_len=18)
at CacheRead.cc:136
#4 0x006ccf6d in open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1083
#5 CacheProcessor::open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3600
#6 0x00588d94 in do_cache_open_read (this=value optimized out,
url=value optimized out, hdr=value optimized out,
params=value optimized out, pin_in_cache=value optimized out) at
HttpCacheSM.cc:216
#7 HttpCacheSM::open_read (this=value optimized out, url=value optimized
out, hdr=value optimized out, params=value optimized out,
pin_in_cache=value optimized out) at HttpCacheSM.cc:248
#8 0x005961e3 in HttpSM::do_cache_lookup_and_read
(this=0x2aaaf010) at HttpSM.cc:4330
#9 0x005af784 in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6992
#10 0x005a8ec2 in HttpSM::handle_api_return (this=0x2aaaf010) at
HttpSM.cc:1509
#11 0x005a95c0 in HttpSM::state_api_callout (this=0x2aaaf010,
event=0, data=0x0) at HttpSM.cc:1441
#12 0x005af26a in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6882
#13 0x0059563e in HttpSM::state_remap_request (this=0x2aaaf010,
event=63002) at HttpSM.cc:3826
#14 0x005ac598 in HttpSM::main_handler (this=0x2aaaf010,
event=63002, data=0x0) at HttpSM.cc:2546
#15 0x00605c3a in handleEvent (this=0x2aaacc548000, event=1,
e=0x2aaaf024ed20) at ../../../iocore/eventsystem/I_Continuation.h:146
#16 RemapPlugins::run_remap (this=0x2aaacc548000, event=1, e=0x2aaaf024ed20)
at RemapPlugins.cc:180
#17 0x0074656f in handleEvent (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at I_Continuation.h:146
#18 EThread::process_event (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at UnixEThread.cc:144
#19 0x00746edb in EThread::execute (this=0x2afd7171f010) at
UnixEThread.cc:195
#20 0x0074590a in spawn_thread_internal (a=0x1b86300) at Thread.cc:88
#21 0x2afd68f2e9d1 in start_thread () from /lib64/libpthread.so.0
#22 0x2afd69f24b6d in clone () from /lib64/libc.so.6
(gdb) f 1
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
611 t-diskHandler-ready_list.enqueue(op);
(gdb) p t-diskHandler
$1 = (DiskHandler *) 0x0
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3053) enable-linux-native-aio crash
[
https://issues.apache.org/jira/browse/TS-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221786#comment-14221786
]
bettydramit commented on TS-3053:
-
OK.. which one ts-2537 or ts-2676?
enable-linux-native-aio crash
-
Key: TS-3053
URL: https://issues.apache.org/jira/browse/TS-3053
Project: Traffic Server
Issue Type: Bug
Reporter: Qiang Li
configure with --enable-linux-native-aio it will crash sometime
{code}
(gdb) bt
#0 enqueue (op=0x2aaae465ecc0) at ../../lib/ts/List.h:290
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
#2 0x006ca458 in CacheVC::handleRead (this=0x2aaae465eb40) at
Cache.cc:2756
#3 0x006ef52e in Cache::open_read (this=value optimized out,
cont=0x2aaaf0101a30, key=value optimized out, request=0x2aaaf0100708,
params=0x2aaaf01000e0, type=value optimized out,
hostname=0x2aaaf0240073
cdn.u1.huluxia.comhttpg1/M00/0C/8D/wKgBB1QAtUOAXXj-AAARZtl9MXk020.jpg_160x160.jpegcdn.u1.huluxia.com\377,
host_len=18)
at CacheRead.cc:136
#4 0x006ccf6d in open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1083
#5 CacheProcessor::open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3600
#6 0x00588d94 in do_cache_open_read (this=value optimized out,
url=value optimized out, hdr=value optimized out,
params=value optimized out, pin_in_cache=value optimized out) at
HttpCacheSM.cc:216
#7 HttpCacheSM::open_read (this=value optimized out, url=value optimized
out, hdr=value optimized out, params=value optimized out,
pin_in_cache=value optimized out) at HttpCacheSM.cc:248
#8 0x005961e3 in HttpSM::do_cache_lookup_and_read
(this=0x2aaaf010) at HttpSM.cc:4330
#9 0x005af784 in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6992
#10 0x005a8ec2 in HttpSM::handle_api_return (this=0x2aaaf010) at
HttpSM.cc:1509
#11 0x005a95c0 in HttpSM::state_api_callout (this=0x2aaaf010,
event=0, data=0x0) at HttpSM.cc:1441
#12 0x005af26a in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6882
#13 0x0059563e in HttpSM::state_remap_request (this=0x2aaaf010,
event=63002) at HttpSM.cc:3826
#14 0x005ac598 in HttpSM::main_handler (this=0x2aaaf010,
event=63002, data=0x0) at HttpSM.cc:2546
#15 0x00605c3a in handleEvent (this=0x2aaacc548000, event=1,
e=0x2aaaf024ed20) at ../../../iocore/eventsystem/I_Continuation.h:146
#16 RemapPlugins::run_remap (this=0x2aaacc548000, event=1, e=0x2aaaf024ed20)
at RemapPlugins.cc:180
#17 0x0074656f in handleEvent (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at I_Continuation.h:146
#18 EThread::process_event (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at UnixEThread.cc:144
#19 0x00746edb in EThread::execute (this=0x2afd7171f010) at
UnixEThread.cc:195
#20 0x0074590a in spawn_thread_internal (a=0x1b86300) at Thread.cc:88
#21 0x2afd68f2e9d1 in start_thread () from /lib64/libpthread.so.0
#22 0x2afd69f24b6d in clone () from /lib64/libc.so.6
(gdb) f 1
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
611 t-diskHandler-ready_list.enqueue(op);
(gdb) p t-diskHandler
$1 = (DiskHandler *) 0x0
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3053) enable-linux-native-aio crash
[
https://issues.apache.org/jira/browse/TS-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221792#comment-14221792
]
Leif Hedstrom commented on TS-3053:
---
Hmmm, maybe we closed too many :). [~shinrich] Did we close this one by
mistake? It seems the others were closed as dupe of this.
enable-linux-native-aio crash
-
Key: TS-3053
URL: https://issues.apache.org/jira/browse/TS-3053
Project: Traffic Server
Issue Type: Bug
Reporter: Qiang Li
configure with --enable-linux-native-aio it will crash sometime
{code}
(gdb) bt
#0 enqueue (op=0x2aaae465ecc0) at ../../lib/ts/List.h:290
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
#2 0x006ca458 in CacheVC::handleRead (this=0x2aaae465eb40) at
Cache.cc:2756
#3 0x006ef52e in Cache::open_read (this=value optimized out,
cont=0x2aaaf0101a30, key=value optimized out, request=0x2aaaf0100708,
params=0x2aaaf01000e0, type=value optimized out,
hostname=0x2aaaf0240073
cdn.u1.huluxia.comhttpg1/M00/0C/8D/wKgBB1QAtUOAXXj-AAARZtl9MXk020.jpg_160x160.jpegcdn.u1.huluxia.com\377,
host_len=18)
at CacheRead.cc:136
#4 0x006ccf6d in open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1083
#5 CacheProcessor::open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3600
#6 0x00588d94 in do_cache_open_read (this=value optimized out,
url=value optimized out, hdr=value optimized out,
params=value optimized out, pin_in_cache=value optimized out) at
HttpCacheSM.cc:216
#7 HttpCacheSM::open_read (this=value optimized out, url=value optimized
out, hdr=value optimized out, params=value optimized out,
pin_in_cache=value optimized out) at HttpCacheSM.cc:248
#8 0x005961e3 in HttpSM::do_cache_lookup_and_read
(this=0x2aaaf010) at HttpSM.cc:4330
#9 0x005af784 in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6992
#10 0x005a8ec2 in HttpSM::handle_api_return (this=0x2aaaf010) at
HttpSM.cc:1509
#11 0x005a95c0 in HttpSM::state_api_callout (this=0x2aaaf010,
event=0, data=0x0) at HttpSM.cc:1441
#12 0x005af26a in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6882
#13 0x0059563e in HttpSM::state_remap_request (this=0x2aaaf010,
event=63002) at HttpSM.cc:3826
#14 0x005ac598 in HttpSM::main_handler (this=0x2aaaf010,
event=63002, data=0x0) at HttpSM.cc:2546
#15 0x00605c3a in handleEvent (this=0x2aaacc548000, event=1,
e=0x2aaaf024ed20) at ../../../iocore/eventsystem/I_Continuation.h:146
#16 RemapPlugins::run_remap (this=0x2aaacc548000, event=1, e=0x2aaaf024ed20)
at RemapPlugins.cc:180
#17 0x0074656f in handleEvent (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at I_Continuation.h:146
#18 EThread::process_event (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at UnixEThread.cc:144
#19 0x00746edb in EThread::execute (this=0x2afd7171f010) at
UnixEThread.cc:195
#20 0x0074590a in spawn_thread_internal (a=0x1b86300) at Thread.cc:88
#21 0x2afd68f2e9d1 in start_thread () from /lib64/libpthread.so.0
#22 0x2afd69f24b6d in clone () from /lib64/libc.so.6
(gdb) f 1
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
611 t-diskHandler-ready_list.enqueue(op);
(gdb) p t-diskHandler
$1 = (DiskHandler *) 0x0
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3053) enable-linux-native-aio crash
[
https://issues.apache.org/jira/browse/TS-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3053:
--
Fix Version/s: 5.3.0
enable-linux-native-aio crash
-
Key: TS-3053
URL: https://issues.apache.org/jira/browse/TS-3053
Project: Traffic Server
Issue Type: Bug
Reporter: Qiang Li
Fix For: 5.3.0
configure with --enable-linux-native-aio it will crash sometime
{code}
(gdb) bt
#0 enqueue (op=0x2aaae465ecc0) at ../../lib/ts/List.h:290
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
#2 0x006ca458 in CacheVC::handleRead (this=0x2aaae465eb40) at
Cache.cc:2756
#3 0x006ef52e in Cache::open_read (this=value optimized out,
cont=0x2aaaf0101a30, key=value optimized out, request=0x2aaaf0100708,
params=0x2aaaf01000e0, type=value optimized out,
hostname=0x2aaaf0240073
cdn.u1.huluxia.comhttpg1/M00/0C/8D/wKgBB1QAtUOAXXj-AAARZtl9MXk020.jpg_160x160.jpegcdn.u1.huluxia.com\377,
host_len=18)
at CacheRead.cc:136
#4 0x006ccf6d in open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1083
#5 CacheProcessor::open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3600
#6 0x00588d94 in do_cache_open_read (this=value optimized out,
url=value optimized out, hdr=value optimized out,
params=value optimized out, pin_in_cache=value optimized out) at
HttpCacheSM.cc:216
#7 HttpCacheSM::open_read (this=value optimized out, url=value optimized
out, hdr=value optimized out, params=value optimized out,
pin_in_cache=value optimized out) at HttpCacheSM.cc:248
#8 0x005961e3 in HttpSM::do_cache_lookup_and_read
(this=0x2aaaf010) at HttpSM.cc:4330
#9 0x005af784 in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6992
#10 0x005a8ec2 in HttpSM::handle_api_return (this=0x2aaaf010) at
HttpSM.cc:1509
#11 0x005a95c0 in HttpSM::state_api_callout (this=0x2aaaf010,
event=0, data=0x0) at HttpSM.cc:1441
#12 0x005af26a in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6882
#13 0x0059563e in HttpSM::state_remap_request (this=0x2aaaf010,
event=63002) at HttpSM.cc:3826
#14 0x005ac598 in HttpSM::main_handler (this=0x2aaaf010,
event=63002, data=0x0) at HttpSM.cc:2546
#15 0x00605c3a in handleEvent (this=0x2aaacc548000, event=1,
e=0x2aaaf024ed20) at ../../../iocore/eventsystem/I_Continuation.h:146
#16 RemapPlugins::run_remap (this=0x2aaacc548000, event=1, e=0x2aaaf024ed20)
at RemapPlugins.cc:180
#17 0x0074656f in handleEvent (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at I_Continuation.h:146
#18 EThread::process_event (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at UnixEThread.cc:144
#19 0x00746edb in EThread::execute (this=0x2afd7171f010) at
UnixEThread.cc:195
#20 0x0074590a in spawn_thread_internal (a=0x1b86300) at Thread.cc:88
#21 0x2afd68f2e9d1 in start_thread () from /lib64/libpthread.so.0
#22 0x2afd69f24b6d in clone () from /lib64/libc.so.6
(gdb) f 1
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
611 t-diskHandler-ready_list.enqueue(op);
(gdb) p t-diskHandler
$1 = (DiskHandler *) 0x0
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (TS-3053) enable-linux-native-aio crash
[
https://issues.apache.org/jira/browse/TS-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reopened TS-3053:
---
Looks like one close too many, thanks [~bettydreamit]
enable-linux-native-aio crash
-
Key: TS-3053
URL: https://issues.apache.org/jira/browse/TS-3053
Project: Traffic Server
Issue Type: Bug
Reporter: Qiang Li
Fix For: 5.3.0
configure with --enable-linux-native-aio it will crash sometime
{code}
(gdb) bt
#0 enqueue (op=0x2aaae465ecc0) at ../../lib/ts/List.h:290
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
#2 0x006ca458 in CacheVC::handleRead (this=0x2aaae465eb40) at
Cache.cc:2756
#3 0x006ef52e in Cache::open_read (this=value optimized out,
cont=0x2aaaf0101a30, key=value optimized out, request=0x2aaaf0100708,
params=0x2aaaf01000e0, type=value optimized out,
hostname=0x2aaaf0240073
cdn.u1.huluxia.comhttpg1/M00/0C/8D/wKgBB1QAtUOAXXj-AAARZtl9MXk020.jpg_160x160.jpegcdn.u1.huluxia.com\377,
host_len=18)
at CacheRead.cc:136
#4 0x006ccf6d in open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1083
#5 CacheProcessor::open_read (this=value optimized out,
cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local=value optimized
out,
request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3600
#6 0x00588d94 in do_cache_open_read (this=value optimized out,
url=value optimized out, hdr=value optimized out,
params=value optimized out, pin_in_cache=value optimized out) at
HttpCacheSM.cc:216
#7 HttpCacheSM::open_read (this=value optimized out, url=value optimized
out, hdr=value optimized out, params=value optimized out,
pin_in_cache=value optimized out) at HttpCacheSM.cc:248
#8 0x005961e3 in HttpSM::do_cache_lookup_and_read
(this=0x2aaaf010) at HttpSM.cc:4330
#9 0x005af784 in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6992
#10 0x005a8ec2 in HttpSM::handle_api_return (this=0x2aaaf010) at
HttpSM.cc:1509
#11 0x005a95c0 in HttpSM::state_api_callout (this=0x2aaaf010,
event=0, data=0x0) at HttpSM.cc:1441
#12 0x005af26a in HttpSM::set_next_state (this=0x2aaaf010) at
HttpSM.cc:6882
#13 0x0059563e in HttpSM::state_remap_request (this=0x2aaaf010,
event=63002) at HttpSM.cc:3826
#14 0x005ac598 in HttpSM::main_handler (this=0x2aaaf010,
event=63002, data=0x0) at HttpSM.cc:2546
#15 0x00605c3a in handleEvent (this=0x2aaacc548000, event=1,
e=0x2aaaf024ed20) at ../../../iocore/eventsystem/I_Continuation.h:146
#16 RemapPlugins::run_remap (this=0x2aaacc548000, event=1, e=0x2aaaf024ed20)
at RemapPlugins.cc:180
#17 0x0074656f in handleEvent (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at I_Continuation.h:146
#18 EThread::process_event (this=0x2afd7171f010, e=0x2aaaf024ed20,
calling_code=1) at UnixEThread.cc:144
#19 0x00746edb in EThread::execute (this=0x2afd7171f010) at
UnixEThread.cc:195
#20 0x0074590a in spawn_thread_internal (a=0x1b86300) at Thread.cc:88
#21 0x2afd68f2e9d1 in start_thread () from /lib64/libpthread.so.0
#22 0x2afd69f24b6d in clone () from /lib64/libc.so.6
(gdb) f 1
#1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
611 t-diskHandler-ready_list.enqueue(op);
(gdb) p t-diskHandler
$1 = (DiskHandler *) 0x0
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
