Hello,
The attached patch fixes a rather profuse memory leak in the Squid
4.0.x series where under certain conditions, HttpRequest objects would
get lost. I can provide more information here if requested,
specifically a Valgrind trace and configuration to reproduce this.
I suggest that a better long term solution would be to make the
members private, and have setter methods to ensure the correct
unlocking occurs. Alternatively, using a smart pointer, e.g.
Http::HttpRequestPointer. If people have any recommendations here, let
me know and I can work towards this.
Thank you,
Nathan.
P.S. I have two more patches that fix less severe memory leaks that
are quite distinct from one another. Should I submit them as a single
patch, or multiple patches? At least one of the patches will involve
some discussion on how to improve it. They are not large.
Ensure any previous HttpRequest objects on AccessLogEntry are unlocked, to ensure they don't leak memory.
With this change, all current assignments to al->request and
al->adapted_request are guarded by either a nullptr check, or by
HTTPMSGUNLOCK()'ing the previous request object first.
This is submitted on behalf of Bloomberg L.P.
=== modified file 'src/client_side.cc'
--- src/client_side.cc 2016-02-13 07:51:20 +0000
+++ src/client_side.cc 2016-03-10 03:59:42 +0000
@@ -446,6 +446,7 @@
}
if (request) {
+ HTTPMSGUNLOCK(al->adapted_request);
al->adapted_request = request;
HTTPMSGLOCK(al->adapted_request);
}
@@ -2820,6 +2821,7 @@
acl_checklist->al->tcpClient = clientConnection;
acl_checklist->al->cache.port = port;
acl_checklist->al->cache.caddr = log_addr;
+ HTTPMSGUNLOCK(acl_checklist->al->request);
acl_checklist->al->request = request;
HTTPMSGLOCK(acl_checklist->al->request);
acl_checklist->nonBlockingCheck(httpsSslBumpAccessCheckDone, this);
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
