John Hardin wrote:

My previous email to ITS is unreadable. Here is a repeat of what I posted.

Thanks, fixed now in master.

-John

Configuration:

CFLAGS="-g -O0" ./configure --exec-prefix=/usr --prefix=/ --enable-overlays=yes --enable-slapd --enable-debug

Start server:

valgrind --leak-check=full openldap/servers/slapd/slapd

Perform search with sorted, paged results. Repeating the command will cause the leaked memory to grow. I'm using:

ldapsearch -H ldap://10.10.9.85 -x -b ou=people,dc=example,dc=com -s one -E'!sss=sn:2.5.13.3' -E'!pr=10/prompt'

At the prompt, type ctrl-C.

Kill the slapd process. The output of valgrind shows the following:

==486== ==486== HEAP SUMMARY: ==486== in use at exit: 95,262 bytes in 1,984 blocks ==486== total heap usage: 34,975 allocs, 32,991 frees, 22,150,370 bytes allocated ==486== ==486== 394 (16 direct, 378 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 10 ==486== at 0x4027282: malloc (vg_replace_malloc.c:270) ==486== by 0x82228BF: ber_memalloc_x (memory.c:228) ==486== by 0x822290C: ber_memalloc (memory.c:244) ==486== by 0x81EAC29: tavl_insert (tavl.c:94) ==486== by 0x81C7FE9: sssvlv_op_response (sssvlv.c:760) ==486== by 0x8084184: slap_response_play (result.c:491) ==486== by 0x80859AE: slap_send_search_entry (result.c:995) ==486== by 0x810BDD6: bdb_search (search.c:1014) ==486== by 0x80F11DB: overlay_op_walk (backover.c:671) ==486== by 0x80F138B: over_op_func (backover.c:723) ==486== by 0x80F1443: over_op_search (backover.c:750) ==486== by 0x80748AE: fe_op_search (search.c:402) ==486== ==486== 94,753 (16 direct, 94,737 indirect) bytes in 1 blocks are definitely lost in loss record 10 of 10 ==486== at 0x4027282: malloc (vg_replace_malloc.c:270) ==486== by 0x82228BF: ber_memalloc_x (memory.c:228) ==486== by 0x822290C: ber_memalloc (memory.c:244) ==486== by 0x81EAB3A: tavl_insert (tavl.c:69) ==486== by 0x81C7FE9: sssvlv_op_response (sssvlv.c:760) ==486== by 0x8084184: slap_response_play (result.c:491) ==486== by 0x80859AE: slap_send_search_entry (result.c:995) ==486== by 0x810BDD6: bdb_search (search.c:1014) ==486== by 0x80F11DB: overlay_op_walk (backover.c:671) ==486== by 0x80F138B: over_op_func (backover.c:723) ==486== by 0x80F1443: over_op_search (backover.c:750) ==486== by 0x80748AE: fe_op_search (search.c:402) ==486== ==486== LEAK SUMMARY: ==486== definitely lost: 32 bytes in 2 blocks ==486== indirectly lost: 95,115 bytes in 1,976 blocks ==486== possibly lost: 0 bytes in 0 blocks ==486== still reachable: 115 bytes in 6 blocks ==486== suppressed: 0 bytes in 0 blocks ==486== Reachable blocks (those to which a pointer was found) are not shown. ==486== To see them, rerun with: --leak-check=full --show-reachable=yes ==486== ==486== For counts of detected and suppressed errors, rerun with: -v ==486== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 71 from 13)

----- Original Message ----- From: Howard Chu hyc@symas.com To: jdhgit@yahoo.com; openldap-its@openldap.org Cc: Sent: Friday, May 24, 2013 8:10 AM Subject: Re: reference through null pointer and memory leak (related to ITS#7588)

jdhgit@yahoo.com wrote:

...

Full_Name: John Hardin Version: master OS: Centos 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.23.115.111)

The commit for ITS#7588 causes a crash if next_node is NULL:

       /* Set the first entry to send for the next page */
       so->so_tree = next_node;

•   next_node->avl_left = NULL;
  
  

next_node will be NULL if all entries have been sent, or if slapd_shutdown is true.

Thanks for pointing this out, will fix it shortly.

...

Another issue related to ITS#7588 is a memory leak when a sorted search with paged results is aborted. This may be because so->so_tree is not the root of the tree when free_sort_op() calls tavl_free().

Not being root of the tree is irrelevant. The tree is threaded, and every remaining node is connected by its preceding node's right child pointer. The tavl_free() function recurses over all of the right and left children, so this should not be a problem.

Can you post a test case that demonstrates the leak?

-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/