[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-users
Subject:    Re: Memory leak in SSL_CTX_load_verify_locations()
From:       Jeffrey Walton <noloader () gmail ! com>
Date:       2011-12-21 22:45:36
Message-ID: CAH8yC8k5A9Luz-jxN_8BftskYP4xu4jiCzMkOR1ofy=iid7C4g () mail ! gmail ! com
[Download RAW message or body]

On Wed, Dec 21, 2011 at 1:26 PM, nandan shantharaj <iamnandans@gmail.com> w=
rote:
> Hi All,
> =C2=A0=C2=A0=C2=A0=C2=A0SSL_CTX_load_verify_locations() is causing memory=
 leak in my
> application. Folowing is the function trace.
>
> =C2=A0=C2=A0 262=C2=A0 1072 bytes leaked in 4 blocks (2.25% of all bytes =
leaked)
> =C2=A0=C2=A0 263=C2=A0 These range in size from 268 to 268 bytes and are =
allocated
> =C2=A0=C2=A0 264=C2=A0 #0=C2=A0 0x800003ffefb9b6b8 in default_malloc_ex()=
 from
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 265=C2=A0 #1=C2=A0 0x800003ffefb9bd10 in CRYPTO_malloc() fro=
m
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 266=C2=A0 #2=C2=A0 0x800003ffefc1a808 in BUF_MEM_grow() from
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 267=C2=A0 #3=C2=A0 0x800003ffefc715a4 in X509_NAME_oneline()=
 from
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 268=C2=A0 #4=C2=A0 0x800003ffefc4af24 in x509_cb() from
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 269=C2=A0 #5=C2=A0 0x800003ffefc56be0 in ASN1_item_ex_d2i() =
from
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 270=C2=A0 #6=C2=A0 0x800003ffefc56730 in ASN1_item_d2i() fro=
m
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 271=C2=A0 #7=C2=A0 0x800003ffefc4af90 in d2i_X509() from
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 272=C2=A0 #8=C2=A0 0x800003ffefc68e70 in PEM_X509_INFO_read_=
bio() from
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 273=C2=A0 #9=C2=A0 0x800003ffefc7ca8c in X509_load_cert_crl_=
file#HLO_CL_#i2_0x1()
> from /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 274=C2=A0 #10 0x800003ffefc7c170 in by_file_ctrl() from
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 275=C2=A0 #11 0x800003ffefc78ff8 in X509_LOOKUP_ctrl() from
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 276=C2=A0 #12 0x800003ffefc6f6b8 in X509_STORE_load_location=
s() from
> /opt/omni/lib64/libcrypto.sl.0.9.8
> =C2=A0=C2=A0 277=C2=A0 #13 0x800003ffefa9ea8c in SSL_CTX_load_verify_loca=
tions() from
> /opt/omni/lib64/libssl.sl.0.9.8
> =C2=A0=C2=A0 278=C2=A0 #14 0x40000000000b4750 in _stub_SSL_CTX_load_verif=
y_locations() at
> ipc.c:152
> =C2=A0=C2=A0 279=C2=A0 #15 0x40000000000ce190 in SecIpc_SSL_ApplyCertConf=
ig() at
> ipc.c:10669
> =C2=A0=C2=A0 280=C2=A0 #16 0x40000000000ce7f8 in SecIpc_SSL_Accept() at i=
pc.c:10803
> =C2=A0=C2=A0 281=C2=A0 #17 0x40000000000cf9a8 in SecIpcNegotiateProtoAcce=
pt() at
> ipc.c:11304
> =C2=A0=C2=A0 282=C2=A0 #18 0x40000000000cfd88 in SecIpcNegotiateProtoAcce=
ptPeek() at
> ipc.c:11423
> =C2=A0=C2=A0 283=C2=A0 #19 0x40000000000d0274 in SecIpcWaitForIpcEvent() =
at ipc.c:11574
> =C2=A0=C2=A0 284=C2=A0 #20 0x4000000000047fa8 in GetRequest() at daemon.c=
:1555
> =C2=A0=C2=A0 285=C2=A0 #21 0x4000000000046e00 in main() at daemon.c:1250
> =C2=A0=C2=A0 286=C2=A0 #22 0xc00000000000a784 in $START$() from /usr/lib/=
pa20_64/dld.sl
> =C2=A0=C2=A0 Both the ssl and context variables are freed in application =
with the
> following calls
> =C2=A0=C2=A0 SSL_free() and SSL_CTX_free().
>
> =C2=A0=C2=A0 Still GDB reports memory leak. Do i have to call any other f=
unction to
> release the memory or if it's actual memory leak in OpenSSL, is there a f=
ix
> for the same.
If you talk with the GDB folks, they will probably recommend a
dedicated leak checker such as Valgrind
(http://people.redhat.com/jkratoch/DeveloperConference2011-debug.pdf).

Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majordomo@openssl.org
[prev in list] [next in list] [prev in thread] [next in thread]