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. 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().
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)
--On Friday, May 24, 2013 9:06 PM +0000 jdhgit@yahoo.com wrote: Please don't send garbage to the ITS. I advise finding an email client that can actually generate proper email. --Quanah > --1665047788-1800616979-1369429529=:40525 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > Configuration:=0A=0A=A0 CFLAGS=3D"-g -O0" ./configure > --exec-prefix=3D/usr = --prefix=3D/ --enable-overlays=3Dyes > --enable-slapd --enable-debug=0A=0ASta= rt server: =0A=0A=A0 valgrind > --leak-check=3Dfull openldap/servers/slapd/sl= apd=0A=0APerform search > with sorted, paged results. Repeating the command w= ill cause the leaked > memory to grow. I'm using:=0A=0A=A0 ldapsearch -H ldap= ://10.10.9.85 -x > -b ou=3Dpeople,dc=3Dexample,dc=3Dcom -s one -E'!sss=3Dsn:2= .5.13.3' > -E'!pr=3D10/prompt'=0A=0AAt the prompt, type ctrl-C.=0A=0AKill the= > slapd process. The output of valgrind shows the > following:=0A=0A=3D=3D486= =3D=3D =0A=3D=3D486=3D=3D HEAP > SUMMARY:=0A=3D=3D486=3D=3D=A0=A0=A0=A0 in us= e at exit: 95,262 bytes in > 1,984 blocks=0A=3D=3D486=3D=3D=A0=A0 total heap = usage: 34,975 allocs, > 32,991 frees, 22,150,370 bytes allocated=0A=3D=3D486= =3D=3D > =0A=3D=3D486=3D=3D 394 (16 direct, 378 indirect) bytes in 1 blocks a= re > definitely lost in loss record 7 of 10=0A=3D=3D486=3D=3D=A0=A0=A0 at 0x4= > 027282: malloc (vg_replace_malloc.c:270)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x82= 228BF: ber_memalloc_x (memory.c:228)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x822290= C: ber_memalloc (memory.c:244)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x81EAC29: tav= l_insert (tavl.c:94)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x81C7FE9: sssvlv_op_res= ponse (sssvlv.c:760)=0A=3D=3D486=3D=3D=A0=A0=A0 > by 0x8084184: slap_response= _play > (result.c:491)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80859AE: slap_send_sea= > rch_entry (result.c:995)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x810BDD6: > bdb_searc= h (search.c:1014)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80F11DB: > overlay_op_walk = (backover.c:671)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x80F138B: over_op_func (bac= kover.c:723)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x80F1443: over_op_search (backo= ver.c:750)=0A=3D=3D486=3D=3D=A0=A0=A0 > by 0x80748AE: fe_op_search (search.c:= 402)=0A=3D=3D486=3D=3D > =0A=3D=3D486=3D=3D 94,753 (16 direct, 94,737 indirec= t) bytes in 1 > blocks are definitely lost in loss record 10 of 10=0A=3D=3D48= > 6=3D=3D=A0=A0=A0 at 0x4027282: malloc > (vg_replace_malloc.c:270)=0A=3D=3D486= =3D=3D=A0=A0=A0 by 0x82228BF: > ber_memalloc_x (memory.c:228)=0A=3D=3D486=3D= =3D=A0=A0=A0 by 0x822290C: > ber_memalloc (memory.c:244)=0A=3D=3D486=3D=3D=A0= =A0=A0 by 0x81EAB3A: > tavl_insert (tavl.c:69)=0A=3D=3D486=3D=3D=A0=A0=A0 by = 0x81C7FE9: > sssvlv_op_response (sssvlv.c:760)=0A=3D=3D486=3D=3D=A0=A0=A0 by = > 0x8084184: slap_response_play (result.c:491)=0A=3D=3D486=3D=3D=A0=A0=A0 > by = 0x80859AE: slap_send_search_entry > (result.c:995)=0A=3D=3D486=3D=3D=A0=A0=A0= by 0x810BDD6: bdb_search > (search.c:1014)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x8= 0F11DB: > overlay_op_walk (backover.c:671)=0A=3D=3D486=3D=3D=A0=A0=A0 by 0x80= > F138B: over_op_func (backover.c:723)=0A=3D=3D486=3D=3D=A0=A0=A0 by > 0x80F144= 3: over_op_search (backover.c:750)=0A=3D=3D486=3D=3D=A0=A0=A0 > by 0x80748AE:= fe_op_search (search.c:402)=0A=3D=3D486=3D=3D > =0A=3D=3D486=3D=3D LEAK SUMM= ARY:=0A=3D=3D486=3D=3D=A0=A0=A0 definitely > lost: 32 bytes in 2 blocks=0A=3D= =3D486=3D=3D=A0=A0=A0 indirectly lost: > 95,115 bytes in 1,976 blocks=0A=3D= =3D486=3D=3D=A0=A0=A0=A0=A0 possibly > lost: 0 bytes in 0 blocks=0A=3D=3D486= =3D=3D=A0=A0=A0 still reachable: > 115 bytes in 6 blocks=0A=3D=3D486=3D=3D=A0= =A0=A0=A0=A0=A0=A0=A0 > suppressed: 0 bytes in 0 blocks=0A=3D=3D486=3D=3D Rea= chable blocks > (those to which a pointer was found) are not shown.=0A=3D=3D4= 86=3D=3D > To see them, rerun with: --leak-check=3Dfull --show-reachable=3Dye= > s=0A=3D=3D486=3D=3D =0A=3D=3D486=3D=3D For counts of detected and > suppresse= d errors, rerun with: -v=0A=3D=3D486=3D=3D ERROR SUMMARY: 2 > errors from 2 c= ontexts (suppressed: 71 from 13) > --1665047788-1800616979-1369429529=:40525 > Content-Type: text/html; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > <html><body><div style=3D"color:#000; background-color:#fff; > font-family:ti= mes new roman, new york, times, > serif;font-size:12pt">Configuration:<br><br= >> CFLAGS=3D"-g -O0" ./configure --exec-prefix=3D/usr --prefix=3D/ >> --e= > nable-overlays=3Dyes --enable-slapd --enable-debug<br><br>Start server: > <br= >> <br> valgrind --leak-check=3Dfull >> openldap/servers/slapd/slapd<br><b= > r>Perform search with sorted, paged results. Repeating the command will > cau= se the leaked memory to grow. I'm using:<br><br> ldapsearch -H > ldap:/= /10.10.9.85 -x -b ou=3Dpeople,dc=3Dexample,dc=3Dcom -s one > -E'!sss=3Dsn:2.5= .13.3' -E'!pr=3D10/prompt'<br><br>At the prompt, type > ctrl-C.<br><br>Kill t= he slapd process. The output of valgrind shows the > following:<br><br>=3D=3D= 486=3D=3D <br>=3D=3D486=3D=3D HEAP > SUMMARY:<br>=3D=3D486=3D=3D &= nbsp; in use at exit: > 95,262 bytes in 1,984 blocks<br>=3D=3D486=3D=3D= total heap > usage: 34,975 allocs, 32,991 frees, 22,150,370 byte= s > allocated<br>=3D=3D486=3D=3D <br>=3D=3D486=3D=3D 394 (16 > direct, 378 indirect) bytes in 1 blocks are definitely lost in loss > record= 7 of 10<br>=3D=3D486=3D=3D at 0x4027282: > malloc (vg_repl= ace_malloc.c:270)<br>=3D=3D486=3D=3D > by 0x82228BF: ber_me= malloc_x > (memory.c:228)<br>=3D=3D486=3D=3D by 0x822290C: = > ber_memalloc (memory.c:244)<br>=3D=3D486=3D=3D by > 0x81EAC= 29: tavl_insert (tavl.c:94)<br>=3D=3D486=3D=3D > by 0x81C7F= E9: sssvlv_op_response > (sssvlv.c:760)<br>=3D=3D486=3D=3D = by 0x8084184: > slap_response_play (result.c:491)<br>=3D=3D486=3D=3D &nb= sp; > by 0x80859AE: slap_send_search_entry (result.c:995)<br>=3D=3D486= > =3D=3D by 0x810BDD6: bdb_search > (search.c:1014)<br>=3D=3D= 486=3D=3D by 0x80F11DB: > overlay_op_walk (backover.c:671)<= br>=3D=3D486=3D=3D > by 0x80F138B: over_op_func (backover.c= > :723)<br>=3D=3D486=3D=3D by 0x80F1443: over_op_search > (ba= ckover.c:750)<br>=3D=3D486=3D=3D by 0x80748AE: > fe_op_sear= ch > (search.c:402)<br>=3D=3D486=3D=3D <br>=3D=3D486=3D=3D 94,753 (16 direct, > 9= 4,737 indirect) bytes in 1 blocks are definitely lost in loss record > 10 of = 10<br>=3D=3D486=3D=3D at 0x4027282: malloc > (vg_replace_ma= lloc.c:270)<br>=3D=3D486=3D=3D by > 0x82228BF: ber_memalloc= _x > (memory.c:228)<br>=3D=3D486=3D=3D by 0x822290C: ber_me= > malloc (memory.c:244)<br>=3D=3D486=3D=3D by 0x81EAB3A: > ta= vl_insert (tavl.c:69)<br>=3D=3D486=3D=3D by > 0x81C7FE9: ss= svlv_op_response > (sssvlv.c:760)<br>=3D=3D486=3D=3D by 0x8= 084184: > slap_response_play (result.c:491)<br>=3D=3D486=3D=3D &nb= sp; > by 0x80859AE: slap_send_search_entry (result.c:995)<br>=3D=3D486=3D=3D&= > nbsp; by 0x810BDD6: bdb_search > (search.c:1014)<br>=3D=3D486=3D= =3D by 0x80F11DB: > overlay_op_walk (backover.c:671)<br>=3D= =3D486=3D=3D > by 0x80F138B: over_op_func (backover.c:723)<= > br>=3D=3D486=3D=3D by 0x80F1443: over_op_search > (backover.c:750)<br>=3D=3D486=3D=3D by 0x80748AE: > fe_op_= search (search.c:402)<br>=3D=3D486=3D=3D <br>=3D=3D486=3D=3D LEAK > SUMMARY:<= br>=3D=3D486=3D=3D definitely lost: 32 bytes > in 2 blocks<= br>=3D=3D486=3D=3D indirectly lost: > 95,115 bytes in 1,976= > blocks<br>=3D=3D486=3D=3D possibly lost: 0 > b= ytes in 0 blocks<br>=3D=3D486=3D=3D still reachable: > 115 = bytes in 6 > blocks<br>=3D=3D486=3D=3D &nb= > sp; suppressed: 0 bytes in 0 blocks<br>=3D=3D486=3D=3D Reachable > bloc= ks (those to which a pointer was found) are not > shown.<br>=3D=3D486=3D=3D T= o see them, rerun with: --leak-check=3Dfull > --show-reachable=3Dyes<br>=3D= =3D486=3D=3D <br>=3D=3D486=3D=3D For > counts of detected and suppressed erro= rs, rerun with: > -v<br>=3D=3D486=3D=3D ERROR SUMMARY: 2 errors from 2 contex= ts > (suppressed: 71 from 13)<br><br><br><div style=3D"font-family: times new= > roman, new york, times, serif; font-size: 12pt;"><div > style=3D"font-family= : times new roman, new york, > times, serif; font-size: 12pt;"> </div> </div> </div></body></html> > --1665047788-1800616979-1369429529=:40525-- > > -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
fixed in master fixed in RE24
changed notes changed state Release to Closed