From d02b48c63a58ea4367a0e905979f140b7d090f86 Mon Sep 17 00:00:00 2001 From: "Ralf S. Engelschall" Date: Mon, 21 Dec 1998 10:52:47 +0000 Subject: Import of old SSLeay release: SSLeay 0.8.1b --- doc/memory.doc | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 doc/memory.doc (limited to 'doc/memory.doc') diff --git a/doc/memory.doc b/doc/memory.doc new file mode 100644 index 0000000000..b9aa33ace0 --- /dev/null +++ b/doc/memory.doc @@ -0,0 +1,27 @@ +In the interests of debugging SSLeay, there is an option to compile +using some simple memory leak checking. + +All malloc(), free() and realloc() calls in SSLeay now go via +Malloc(), Free() and Realloc() (except those in crypto/lhash). + +If CRYPTO_MDEBUG is defined, these calls are #defined to +CRYPTO_malloc(), CRYPTO_free() and CRYPTO_realloc(). +If it is not defined, they are #defined to malloc(), free() and realloc(). + +the CRYPTO_malloc() routines by default just call the underlying library +functons. + +If CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON) is called, memory leak detection is +turned on. CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_OFF) turns it off. + +When turned on, each Malloc() or Realloc() call is recored along with the file +and line number from where the call was made. (This is done using the +lhash library which always uses normal system malloc(3) routines). + +void CRYPTO_mem_leaks(BIO *b); +void CRYPTO_mem_leaks_fp(FILE *fp); +These both print out the list of memory that has not been free()ed. +This will probably be rather hard to read, but if you look for the 'top level' +structure allocation, this will often give an idea as to what is not being +free()ed. I don't expect people to use this stuff normally. + -- cgit v1.2.3