Full_Name: Alan Clark Version: devel OS: Linux / NetWare / WinNT URL: ftp://ftp.openldap.org/incoming/aclark-000609 The above patch adds additional debug to the lber memory functions. Specifically it does the following: 1. Puts a known value at the end of the buffer (one is already at the beginning) 2. Checks for both values being there on all free and realloc functions. This identifies buffers that have had their head or tail overwritten. 3. Any memory freed is filled with poison - 0xff to make it easier to find code that uses memory after it is free'd. Since we now have the buffer size, at both alloc and free time, I put in a little counter that gives the current value for amount of memory allocated. Note: this value won't be correct if the library is running in the kernel or for multi-threaded applications, as there is no lock around modification of the counter. I added a ber_get/get option to get the value. This has proved very helpful to us when searching for memory leaks. You're welcome to it if it seems useful to you. -Steve Sonntag -Alan Clark Manager Novell Directory Services
Looks like this would violate alignment restrictions on many CPU? Also, s/(int|long)/ber_len_t/ Kurt At 06:18 PM 6/9/00 GMT, VTAG@novell.com wrote: >Full_Name: Alan Clark >Version: devel >OS: Linux / NetWare / WinNT >URL: ftp://ftp.openldap.org/incoming/aclark-000609.patch > >The above patch adds additional debug to the lber memory functions. = >Specifically it >does the following: > >1. Puts a known value at the end of the buffer (one is already at the = >beginning) >2. Checks for both values being there on all free and realloc functions. = >This identifies > buffers that have had their head or tail overwritten. >3. Any memory freed is filled with poison - 0xff to make it easier to = >find code > that uses memory after it is free'd. > >Since we now have the buffer size, at both alloc and free time, >I put in a little counter that gives the current value for amount of = >memory allocated. Note: this value won't be correct if the library is = >running=20 >in the kernel or for multi-threaded applications, as there is no lock = >around modification >of the counter. > >I added a ber_get/get option to get the value. This has proved very = >helpful to us >when searching for memory leaks. > >You're welcome to it if it seems useful to you. > >-Steve Sonntag >-Alan Clark >Manager >Novell Directory Services > >--=_045C7138.7E1FB730 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> ><HTML><HEAD> ><META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type= >> ><META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR></HEAD> ><BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: = >2px"> ><DIV>Full_Name: Alan Clark<BR>Version: devel<BR>OS: Linux / NetWare /=20 >WinNT<BR>URL: <A=20 >href=3D"ftp://ftp.openldap.org/incoming/aclark-00060">ftp://ftp.openldap.or= >g/incoming/aclark-00060</A>9</DIV> ><DIV> </DIV> ><DIV>The above patch adds additional debug to the lber memory functions.&nb= >sp;=20 >Specifically it</DIV> ><DIV>does the following:</DIV> ><DIV> </DIV> ><DIV>1. Puts a known value at the end of the buffer (one is already = >at the=20 >beginning)</DIV> ><DIV>2. Checks for both values being there on all free and realloc=20 >functions. This identifies</DIV> ><DIV> buffers that have had their head or tail overwritten.</DIV> ><DIV>3. Any memory freed is filled with poison - 0xff to make it = >easier to=20 >find code</DIV> ><DIV> that uses memory after it is free'd.</DIV> ><DIV> </DIV> ><DIV>Since we now have the buffer size, at both alloc and free time,</DIV> ><DIV>I put in a little counter that gives the current value for amount of = >memory=20 >allocated. Note: this value won't be correct if the library is = >running=20 ></DIV> ><DIV>in the kernel or for multi-threaded applications, as there is no = >lock=20 >around modification</DIV> ><DIV>of the counter.</DIV> ><DIV> </DIV> ><DIV>I added a ber_get/get option to get the value. This has proved = >very=20 >helpful to us</DIV> ><DIV>when searching for memory leaks.</DIV> ><DIV> </DIV> ><DIV>You're welcome to it if it seems useful to you.</DIV> ><DIV> </DIV> ><DIV>-Steve Sonntag<BR>-Alan Clark</DIV> ><DIV>Manager</DIV> ><DIV>Novell Directory Services</DIV></BODY></HTML> > >--=_045C7138.7E1FB730-- > >
Yes you are correct. The storing of the pattern at the end of the buffer will violate boundary constraints. I will fix it. In the mean time, there is a bug ber_memrealloc. If LDAP_MEMORY_DEBUG is defined and realloc fails, then variable new is never initialized. Fix: Index: memory.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblber/memory.c,v retrieving revision 1.27 diff -u -w -r1.27 memory.c --- memory.c 2000/05/13 00:36:07 1.27 +++ memory.c 2000/06/09 21:40:56 @@ -198,7 +198,7 @@ void * ber_memrealloc( void* p, ber_len_t s ) { - void *new; + void *new = NULL; ber_int_options.lbo_valid = LBER_INITIALIZED; /* realloc(NULL,s) -> malloc(s) */ -Steve >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 09-Jun-00 3:26:44 PM >>> Looks like this would violate alignment restrictions on many CPU? Also, s/(int|long)/ber_len_t/ Kurt At 06:18 PM 6/9/00 GMT, VTAG@novell.com wrote: >Full_Name: Alan Clark >Version: devel >OS: Linux / NetWare / WinNT >URL: ftp://ftp.openldap.org/incoming/aclark-000609.patch > >The above patch adds additional debug to the lber memory functions. = >Specifically it >does the following: > >1. Puts a known value at the end of the buffer (one is already at the = >beginning) >2. Checks for both values being there on all free and realloc functions. = >This identifies > buffers that have had their head or tail overwritten. >3. Any memory freed is filled with poison - 0xff to make it easier to = >find code > that uses memory after it is free'd. > >Since we now have the buffer size, at both alloc and free time, >I put in a little counter that gives the current value for amount of = >memory allocated. Note: this value won't be correct if the library is = >running=20 >in the kernel or for multi-threaded applications, as there is no lock = >around modification >of the counter. > >I added a ber_get/get option to get the value. This has proved very = >helpful to us >when searching for memory leaks. > >You're welcome to it if it seems useful to you. > >-Steve Sonntag >-Alan Clark >Manager >Novell Directory Services > >--=_045C7138.7E1FB730 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> ><HTML><HEAD> ><META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type= >> ><META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR></HEAD> ><BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: = >2px"> ><DIV>Full_Name: Alan Clark<BR>Version: devel<BR>OS: Linux / NetWare /=20 >WinNT<BR>URL: <A=20 >href=3D"ftp://ftp.openldap.org/incoming/aclark-00060">ftp://ftp.openldap.or= >g/incoming/aclark-00060</A>9</DIV> ><DIV> </DIV> ><DIV>The above patch adds additional debug to the lber memory functions.&nb= >sp;=20 >Specifically it</DIV> ><DIV>does the following:</DIV> ><DIV> </DIV> ><DIV>1. Puts a known value at the end of the buffer (one is already = >at the=20 >beginning)</DIV> ><DIV>2. Checks for both values being there on all free and realloc=20 >functions. This identifies</DIV> ><DIV> buffers that have had their head or tail overwritten.</DIV> ><DIV>3. Any memory freed is filled with poison - 0xff to make it = >easier to=20 >find code</DIV> ><DIV> that uses memory after it is free'd.</DIV> ><DIV> </DIV> ><DIV>Since we now have the buffer size, at both alloc and free time,</DIV> ><DIV>I put in a little counter that gives the current value for amount of = >memory=20 >allocated. Note: this value won't be correct if the library is = >running=20 ></DIV> ><DIV>in the kernel or for multi-threaded applications, as there is no = >lock=20 >around modification</DIV> ><DIV>of the counter.</DIV> ><DIV> </DIV> ><DIV>I added a ber_get/get option to get the value. This has proved = >very=20 >helpful to us</DIV> ><DIV>when searching for memory leaks.</DIV> ><DIV> </DIV> ><DIV>You're welcome to it if it seems useful to you.</DIV> ><DIV> </DIV> ><DIV>-Steve Sonntag<BR>-Alan Clark</DIV> ><DIV>Manager</DIV> ><DIV>Novell Directory Services</DIV></BODY></HTML> > >--=_045C7138.7E1FB730-- > >
changed notes changed state Open to Suspended
moved from Incoming to Development
Updated patch URL: ftp://ftp.openldap.org/incoming/aclark-000620.patch -Steve Sonntag -Alan Clark >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 09-Jun-00 3:26:44 PM >>> Looks like this would violate alignment restrictions on many CPU? Also, s/(int|long)/ber_len_t/ Kurt At 06:18 PM 6/9/00 GMT, VTAG@novell.com wrote: >Full_Name: Alan Clark >Version: devel >OS: Linux / NetWare / WinNT >URL: ftp://ftp.openldap.org/incoming/aclark-000609.patch > >The above patch adds additional debug to the lber memory functions. = >Specifically it >does the following: > >1. Puts a known value at the end of the buffer (one is already at the = >beginning) >2. Checks for both values being there on all free and realloc functions. = >This identifies > buffers that have had their head or tail overwritten. >3. Any memory freed is filled with poison - 0xff to make it easier to = >find code > that uses memory after it is free'd. > >Since we now have the buffer size, at both alloc and free time, >I put in a little counter that gives the current value for amount of = >memory allocated. Note: this value won't be correct if the library is = >running=20 >in the kernel or for multi-threaded applications, as there is no lock = >around modification >of the counter. > >I added a ber_get/get option to get the value. This has proved very = >helpful to us >when searching for memory leaks. > >You're welcome to it if it seems useful to you. > >-Steve Sonntag >-Alan Clark >Manager >Novell Directory Services > >--=_045C7138.7E1FB730 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> ><HTML><HEAD> ><META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type= >> ><META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR></HEAD> ><BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: = >2px"> ><DIV>Full_Name: Alan Clark<BR>Version: devel<BR>OS: Linux / NetWare /=20 >WinNT<BR>URL: <A=20 >href=3D"ftp://ftp.openldap.org/incoming/aclark-00060">ftp://ftp.openldap.or= >g/incoming/aclark-00060</A>9</DIV> ><DIV> </DIV> ><DIV>The above patch adds additional debug to the lber memory functions.&nb= >sp;=20 >Specifically it</DIV> ><DIV>does the following:</DIV> ><DIV> </DIV> ><DIV>1. Puts a known value at the end of the buffer (one is already = >at the=20 >beginning)</DIV> ><DIV>2. Checks for both values being there on all free and realloc=20 >functions. This identifies</DIV> ><DIV> buffers that have had their head or tail overwritten.</DIV> ><DIV>3. Any memory freed is filled with poison - 0xff to make it = >easier to=20 >find code</DIV> ><DIV> that uses memory after it is free'd.</DIV> ><DIV> </DIV> ><DIV>Since we now have the buffer size, at both alloc and free time,</DIV> ><DIV>I put in a little counter that gives the current value for amount of = >memory=20 >allocated. Note: this value won't be correct if the library is = >running=20 ></DIV> ><DIV>in the kernel or for multi-threaded applications, as there is no = >lock=20 >around modification</DIV> ><DIV>of the counter.</DIV> ><DIV> </DIV> ><DIV>I added a ber_get/get option to get the value. This has proved = >very=20 >helpful to us</DIV> ><DIV>when searching for memory leaks.</DIV> ><DIV> </DIV> ><DIV>You're welcome to it if it seems useful to you.</DIV> ><DIV> </DIV> ><DIV>-Steve Sonntag<BR>-Alan Clark</DIV> ><DIV>Manager</DIV> ><DIV>Novell Directory Services</DIV></BODY></HTML> > >--=_045C7138.7E1FB730-- > >
I applied your revised patch with a few minor changes to devel. Kurt
changed notes changed state Suspended to Closed
applied revised patch