<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Alex,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks for the prompt reply! Thanks also for the clarifications.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Agreed, I just realized the requests seem to be failing with Http::scServiceUnavailable, so my focus turned to Security::PeerConnector::sslCrtvdHandleReply() and friends.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Best.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 18, 2023 at 11:11 AM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/18/23 13:46, Hamilton Coutinho wrote:<br>
> Hi all,<br>
> <br>
> We are observing what seems to be several objects leaking in the output <br>
> mgr:mem, to the tune of 10s of 1000s <br>
> of HttpRequest, HttpHeaderEntry, Comm::Connection, Security::ErrorDetail, cbdata PeekingPeerConnector (31), etc.<br>
> <br>
> We dumped a core and managed to find some HttpRequest objects and they <br>
> all seem to have failed in the same way, with an ERR_SECURE_CONNECT_FAIL <br>
> category, for a site that has a certificate signed by a CA authority not <br>
> available to squid.<br>
> <br>
> If I would guess, the origin of the problem might be in <br>
> Ssl::PeekingPeerConnector::checkForPeekAndSpliceMatched():<br>
> <br>
>      if (finalAction == Ssl::bumpTerminate) {<br>
>          bail(new ErrorState(ERR_SECURE_CONNECT_FAIL, Http::scForbidden, <br>
> request.getRaw(), al));<br>
>          clientConn->close();<br>
>          clientConn = nullptr;<br>
> <br>
> Wondering if assigning null to clientConn there would be premature.<br>
<br>
<br>
FWIW, that connection pointer reset itself looks OK to me. ConnStateData <br>
and/or others should have a connection closure handler attached to the <br>
clientConn descriptor. That handler should be notified by Comm and <br>
initiate cleanup of the objects responsible for client-Squid communication.<br>
<br>
The bail() call above should inform the requestor about the <br>
error/termination and terminate this AsyncJob. That requestor should <br>
then close the Squid-server connection and clean up associated state.<br>
<br>
While there may be bugs in those "should..." sequences, please note that <br>
the pasted code is not related to handling of untrusted origin servers <br>
(unless your ssl_bump rules specifically activate the terminate action <br>
upon discovering such an origin server). The pasted code is reacting to <br>
an "ssl_bump terminate" rule matching.<br>
<br>
<br>
Cheers,<br>
<br>
Alex.<br>
<br>
_______________________________________________<br>
squid-dev mailing list<br>
<a href="mailto:squid-dev@lists.squid-cache.org" target="_blank">squid-dev@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-dev" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font size="2">Hamilton</font></div></div></div></div></div>