I don't know if you're writing a client or a server, but I'll just
describe what I did:

- hack up your code with some conditional memory debugging stuff such
  that it accepts (or connects) a fixed number of times and then
  calls CRYPTO_mem_leaks_fp() and exits.
- run the program for one connection and save the leak output
- run the program for two connections and save the leak output
- massage the data using "awk '{print $3 $4 $1 $6}'"
- now diff the result of that.

That will show you what you leak from one connection to the next - I
assume that this will show you what you forgot to clean up.

Now you have to find what functions are leaking the memory by looking
in the ssl source and finding what in function is (e.g.) in file
x_algor.c at line 102.

Steve

On Tue, 17 Jul 2001, C. Gould wrote:

>
> Ok, thanks a bunch.  I got that working, and found what appears to be a
> decent number of memory leaks.  I know my application is leaking memory,
> but the output i'm getting isn't really of much use to me.  Could anyone
> assist me in interpreting the snippet of output I've attached below.
> There is more, but I left it out because of space considerations.  What is
> the best way to track down the source of these leaks.  Is it safe to
> assume these are my own fault, or could the OpenSSL library be leaking
> some memory?
>
>
>
> -- snip --
>
> [14:53:30]   225 file=x_algor.c, line=102, thread=14734, number=8,
> address=080F6E30
> [14:53:30]   112 file=o_names.c, line=160, thread=14734, number=16,
> address=080F1F50
> [14:53:30]   249 file=a_bytes.c, line=114, thread=14734, number=21,
> address=080F7588
> [14:53:30]   311 file=asn1_lib.c, line=371, thread=14734, number=16,
> address=080F8CB0
> [14:57:28]  4202 file=lhash.c, line=193, thread=14734, number=12,
> address=0810D620
> [14:53:30]    57 file=o_names.c, line=160, thread=14734, number=16,
> address=080F16A8
> [14:53:30]   201 file=bn_lib.c, line=335, thread=14734, number=72,
> address=080F6558
> [14:56:43]  2217 file=stack.c, line=122, thread=14734, number=20,
> address=080F9C80
> [14:53:30]   223 file=buffer.c, line=67, thread=14734, number=12,
> address=080F6DA0
> [14:53:30]     0 file=o_names.c, line=160, thread=14734, number=16,
> address=080F2648
> [14:53:30]     8 file=o_names.c, line=160, thread=14734, number=16,
> address=080F0EC0
> [14:53:30]   272 file=a_bytes.c, line=114, thread=14734, number=3,
> address=080F7D70
> [14:53:30]   100 file=evp_pbe.c, line=120, thread=14734, number=16,
> address=080F3E90
> [14:53:30]   285 file=a_object.c, line=268, thread=14734, number=24,
> address=080F8378
> [14:57:12]  3594 file=ssl_sess.c, line=114, thread=14734, number=200,
> address=08109E38
> [14:53:30]   246 file=asn1_lib.c, line=371, thread=14734, number=16,
> address=080F7498
> [14:56:43]  2216 file=ssl_sess.c, line=114, thread=14734, number=200,
> address=08108E08
> [14:53:30]    51 file=o_names.c, line=160, thread=14734, number=16,
> address=080F15B8
> [14:56:54]  2930 file=lhash.c, line=193, thread=14734, number=12,
> address=0810A650
> [14:57:25]  4018 file=ssl_sess.c, line=114, thread=14734, number=200,
> address=0810EC88
> [14:53:30]   220 file=x_name.c, line=221, thread=14734, number=16,
> address=080F6CB0
> [14:53:30]     2 file=o_names.c, line=160, thread=14734, number=16,
> address=080F0DD0
> [14:53:30]   269 file=asn1_lib.c, line=371, thread=14734, number=16,
> address=080F7C80
> [14:56:44]  2429 file=stack.c, line=122, thread=14734, number=20,
> address=080FA2B8
> [14:57:15]  3778 file=lhash.c, line=193, thread=14734, number=12,
> address=08111350
> [14:53:30]    97 file=evp_pbe.c, line=120, thread=14734, number=16,
> address=080F3DA0
> [14:57:22]  3990 file=lhash.c, line=193, thread=14734, number=12,
> address=08111320
> [14:53:30]    32 file=o_names.c, line=160, thread=14734, number=16,
> address=080F0D70
> [14:53:30]   161 file=stack.c, line=122, thread=14734, number=20,
> address=080F53A8
> [14:53:30]   243 file=a_object.c, line=242, thread=14734, number=3,
> address=080F73A8
> [14:53:30]   305 file=x_exten.c, line=123, thread=14734, number=20,
> address=080F8AD0
> [14:53:30]    45 file=o_names.c, line=160, thread=14734, number=16,
> address=080F14C8
> [14:53:30]   329 file=bn_lib.c, line=335, thread=14734, number=12,
> address=080F5BC0
> [14:53:30]   197 file=bn_lib.c, line=295, thread=14734, number=20,
> address=080F6318
> [14:56:57]  3064 file=ssl_sess.c, line=114, thread=14734, number=200,
> address=0810CB38
> [14:53:30]   192 file=bn_lib.c, line=335, thread=14734, number=72,
> address=080F62B8
> [14:53:30]    90 file=o_names.c, line=160, thread=14734, number=16,
> address=080F1C50
> [14:53:30]    39 file=o_names.c, line=160, thread=14734, number=16,
> address=080F13D8
> [14:53:30]  1823 file=bn_lib.c, line=335, thread=14734, number=8,
> address=080F9980
> [14:53:30]  1858 file=bn_lib.c, line=335, thread=14734, number=264,
> address=080FA108
> [14:53:30]   301 file=a_type.c, line=277, thread=14734, number=8,
> address=080F8920
> [14:53:30]   237 file=a_object.c, line=268, thread=14734, number=24,
> address=080F71C8
> [14:53:30]    84 file=o_names.c, line=160, thread=14734, number=16,
> address=080F1B60
> [14:53:30]   135 file=o_names.c, line=160, thread=14734, number=16,
> address=080F22E8
> [14:53:30]   325 file=bn_lib.c, line=295, thread=14734, number=20,
> address=080F5A10
> [14:53:30]   333 file=lhash.c, line=193, thread=14734, number=12,
> address=080F59E0
> [14:53:30]    31 file=o_names.c, line=160, thread=14734, number=16,
> address=080F1258
> [14:53:30]   186 file=bn_lib.c, line=335, thread=14734, number=136,
> address=080F60D8
> [14:53:30]    78 file=o_names.c,
>
> -- end snip --
>
>
> On Thursday 12 July 2001 08:17 am, you wrote:
> > You need to do the following in your code -
> >
> > at start:
> >         CRYPTO_malloc_debug_init();
> >         CRYPTO_dbg_set_options(V_CRYPTO_MDEBUG_ALL);
> >         CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
> >
> > at end:
> >         CRYPTO_mem_leaks_fp(stderr);
> >
> > This produces tons of memory references that you'll have to sort out
> what
> > are valid and which you think are leaks.  I found that I could reformat
> > the data with awk and do a diff between a number of sessions to see
> where
> > the memory was growing.
> >
> > Steve
> >
> > On Wed, 11 Jul 2001, C. Gould wrote:
> > > I've been tuning up my code and am now trying to locate sources of
> what
> > > appears to be some leaking memory.  I've searched the archives and saw
> > > a bit of discussion about compiling with -DCRYPTO_MDEBUG set.  When I
> did
> > > so there was no indication that any sort of leaks were even trying to
> be
> > > detected.  Any suggestions as to how I can sort this situation out?
> > >
> > > Chris
> >
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [EMAIL PROTECTED]
> Automated List Manager                           [EMAIL PROTECTED]
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to