Thiago FarinaHi,
Do we leak the context we allocate in imap-send.c:280 intentionally?
Regards,
-- Thiago Farina
Thiago Farina
Jeff KingRe: SSL_CTX leak?
On Thu, Mar 27, 2014 at 10:37:07AM -0300, Thiago Farina wrote:
> Do we leak the context we allocate in imap-send.c:280 intentionally?
It was never mentioned on the mailing list when the patches came originally, so I suspect is just an omission.
Presumably the SSL_CTX is needed by the connection that survives after the function, but my reading of SSL_CTX_free implies that the data is reference-counted, and the library would presumably handle it fine.
OTOH, it is probably not causing a huge problem (since we wouldn't end up freeing it until the end of the program anyway), so I would not personally devote to many brain cycles to figuring out how OpenSSL handles it.
-Peff
Junio C HamanoRe: SSL_CTX leak?
Jeff King <peff@peff.net> writes:
Show 10 quoted lines
> On Thu, Mar 27, 2014 at 10:37:07AM -0300, Thiago Farina wrote: > >> Do we leak the context we allocate in imap-send.c:280 intentionally? > > It was never mentioned on the mailing list when the patches came > originally, so I suspect is just an omission. > > Presumably the SSL_CTX is needed by the connection that survives after > the function, but my reading of SSL_CTX_free implies that the data is > reference-counted, and the library would presumably handle it fine.
Yes, I was reading the SSL_new() yesterday and found out that at least in a recent code it increments the reference count on the ctx it is fed. So it would be the right thing to decrement the refcount in the caller that created the context and used to call SSL_new(), but I fully agree with the analysis below (with s/a huge/any/):
> OTOH, it is probably not causing a huge problem (since we wouldn't end > up freeing it until the end of the program anyway), so I would not > personally devote to many brain cycles to figuring out how OpenSSL > handles it.
Heh. So you are saying that I wasted 30 minutes yesterday? ;-)
Thanks.