[
https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=34962&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-34962
]
ASF GitHub Bot logged work on TS-5092:
--------------------------------------
Author: ASF GitHub Bot
Created on: 08/Jan/17 02:56
Start Date: 08/Jan/17 02:56
Worklog Time Spent: 10m
Work Description: GitHub user zwoop opened an issue:
https://github.com/apache/trafficserver/issues/1308
CID 1368316 & 1368315: Leaks and NULL references
I think this landed recently (TS-5092?), and we have to fix this for 7.1.x.
clang-analyzer also detects the NULL pointer reference.
```C
** CID 1368316: Resource leaks (RESOURCE_LEAK)
/proxy/http/HttpSM.cc: 5049 in HttpSM::do_http_server_open(bool)()
________________________________________________________________________________________________________
*** CID 1368316: Resource leaks (RESOURCE_LEAK)
/proxy/http/HttpSM.cc: 5049 in HttpSM::do_http_server_open(bool)()
5043 int len = 0;
5044 const char *host =
t_state.hdr_info.server_request.host_get(&len);
5045 if (host && len > 0) {
5046 opt.set_sni_servername(host, len);
5047 }
5048
CID 1368316: Resource leaks (RESOURCE_LEAK)
Failing to save or free storage allocated by
"Layout::relative_to(this->t_state.txn_conf->client_cert_filepath,
this->t_state.txn_conf->client_cert_filename)" leaks it.
5049 ats_scoped_str clientCert(
5050
ats_strdup((Layout::relative_to(t_state.txn_conf->client_cert_filepath,
t_state.txn_conf->client_cert_filename))));
5051 opt.set_client_certname(clientCert);
5052 connect_action_handle = sslNetProcessor.connect_re(this,
// state machine
5053
&t_state.current.server->dst_addr.sa, // addr + port
5054 &opt);
** CID 1368315: Null pointer dereferences (FORWARD_NULL)
/proxy/http2/Http2ConnectionState.cc: 217 in
rcv_headers_frame(Http2ConnectionState &, const Http2Frame &)()
________________________________________________________________________________________________________
*** CID 1368315: Null pointer dereferences (FORWARD_NULL)
/proxy/http2/Http2ConnectionState.cc: 217 in
rcv_headers_frame(Http2ConnectionState &, const Http2Frame &)()
211 if (!stream) {
212 return error;
213 }
214 }
215
216 // keep track of how many bytes we get in the frame
CID 1368315: Null pointer dereferences (FORWARD_NULL)
Dereferencing null pointer "stream".
217 stream->request_header_length += payload_length;
218 if (stream->request_header_length >
Http2::max_request_header_size) {
219 return Http2Error(HTTP2_ERROR_CLASS_STREAM,
HTTP2_ERROR_PROTOCOL_ERROR,
220 "recv headers payload for headers greater
than header length");
221 }
222
```
----
----
Issue Time Tracking
-------------------
Worklog Id: (was: 34962)
Time Spent: 1.5h (was: 1h 20m)
> ATS handling of too many concurrent streams too agressive and maybe out of
> spec
> -------------------------------------------------------------------------------
>
> Key: TS-5092
> URL: https://issues.apache.org/jira/browse/TS-5092
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
> Reporter: Susan Hinrichs
> Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> This issue was identified while debugging new errors seen by an internal team
> after they enabled HTTP/2 in their client. On the backend, they saw an
> increase in the cases were ATS sends the origin the POST header but no POST
> body and then closes the connection.
> With the addition of Error() messages we were able to see a case where the
> client is trying to open the 101'st stream on a session. This is beyond the
> 100 max concurrent stream limit, so ATS shuts down the session which kills
> the previous 100 streams.
> A closer reading of section 5.1.2 of the spec
> (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this
> should be a stream error and not a connection error. Bryan Call, Masaori, and
> Maskit confirmed this interpretation. Maskit also noted that the other error
> case in the current createStream method must be treated as a connection error.
> Presumably the client library is expecting the refused stream case so it can
> try again later.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
