wfg wrote:
> I've managed to track down the cause of the leak.
> I have a solution that seems to work, but I'm sure
> there must be a better way to fix it and was
> hoping for some help from people more familiar
> with this code.
>
> After pouring over loads of traces and single
> stepping with gdb (complicated by the fact that
> gdb seems to get confused in openssl code
> for some reason), I found that each tls socket
> connection/closeleaks
> two 64-byte (0x40) blocks and
> one 24-byte (0x18) block.
>
> I tracked these down to the following in Tls_Clean()
> (file: tls.c):
>
> statePtr->p_bio (64 bytes)
> statePtr->bio->ptr (24 bytes)
> statePtr->bio (64 bytes)
>
> I added calls to OPENSSL_free() for each of these
> (if they were not 0) at the end of Tls_Clean()
> and that seemed to fix the problem. However,
> it seems like a hack since these were not
> allocated using OPENSSL_malloc() directly
> but rather via calls to BIO_new_tcl() and BIO_new()
> in ImportObjCmd()
>
> Anyone familiar with this code care to offer some
> guidance?
Please file this report as a bug at tls.sourceforge.net.
I believe you have hunted it down far enough where I can
identify the mem leak specifically.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
Received on Sun Apr 30 02:16:33 2006