SSL_CTX leak?

SSL_CTX leak?

[Thiago Farina]

Hi,

Do we leak the context we allocate in imap-send.c:280 intentionally?

Regards,

--
Thiago Farina

Re: SSL_CTX leak?

[Jeff King]

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

Re: SSL_CTX leak?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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.