https://issues.apache.org/bugzilla/show_bug.cgi?id=54357
--- Comment #34 from Kaspar Brand <[email protected]> --- (In reply to Alex Bligh from comment #33) > I didn't realise that (because the old code was never freeing cid under any > circumstances). Yes, that's what was referring to in comment 30 with the issue in the current certinfo_free code. > This is presumably why you have > inserted: > OCSP_CERTID_free(cid); > if aia is NULL and there is no stapling URL. That's because we're aborting early, and we don't want to store any certinfo in this case - i.e., its part of the cleanup of temporary stuff. > But when the server apr pool is freed (on a restart), [...] > Therefore, when the restart occurs, the hash table will be entry and it will > call OCSP_cert_to_id again for each certificate, allocating another > OSCP_CERTID structure (and anything beneath that). As far as I can tell, > this will be leaked on each restart. This doesn't happen, and is probably the reason you thought v7 would leak. The SSLModConfigRec ("mc") survives restarts, and the stapling_cert_info hash is not cleared. Put differently, we only add certinfo for a specific certificate once in the lifetime of the process - if apr_hash_set() for certificate X was called at startup, then it's skipped if certificate X is encountered again in any of the additional rounds (in fact, this also the reason I put in the TRACE1 log statement, which you'll see only once per certificate and process lifetime when configuring "LogLevel ssl:trace1"). > I think: > apr_pool_cleanup_register(p, cid, OCSP_CERTID_free, apr_pool_cleanup_null); > > or similar somewhere around the hash_set will fix this. It's sort of moot because it would only be called when httpd exits. I don't have strong feelings, and hope that we get some further opinions from other httpd devs at this point (Rainer/Ruediger/Joe/Steve?). -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
