--On Friday, May 24, 2013 9:06 PM +0000 [email protected] 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
