Re: reference through null pointer and memory leak (related to ITS#7588)

[hyc@symas.com]

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/
>
>


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