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 <[email protected]> > To: [email protected]; [email protected] > Cc: > Sent: Friday, May 24, 2013 8:10 AM > Subject: Re: reference through null pointer and memory leak (related to > ITS#7588) > > [email protected] 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/ > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
