[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: additional debug for lber memory functions (ITS#584)
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=_2E765B5B.52339AF0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 =3D NULL;
ber_int_options.lbo_valid =3D LBER_INITIALIZED;
=20
/* 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. =3D
>Specifically it
>does the following:
>
>1. Puts a known value at the end of the buffer (one is already at the =
=3D
>beginning)
>2. Checks for both values being there on all free and realloc functions. =
=3D
>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 =
=3D
>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 =3D
>memory allocated. Note: this value won't be correct if the library is =
=3D
>running=3D20
>in the kernel or for multi-threaded applications, as there is no lock =3D
>around modification
>of the counter.
>
>I added a ber_get/get option to get the value. This has proved very =3D
>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
>
>--=3D_045C7138.7E1FB730
>Content-Type: text/html; charset=3DISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
><HTML><HEAD>
><META content=3D3D"text/html; charset=3D3Diso-8859-1" http-equiv=3D3DConte=
nt-Type=3D
>>
><META content=3D3D"MSHTML 5.00.2014.210" name=3D3DGENERATOR></HEAD>
><BODY style=3D3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
=3D
>2px">
><DIV>Full_Name: Alan Clark<BR>Version: devel<BR>OS: Linux / NetWare =
/=3D20
>WinNT<BR>URL: <A=3D20
>href=3D3D"ftp://ftp.openldap.org/incoming/aclark-00060";>ftp://ftp.openldap=
.or=3D
>g/incoming/aclark-00060</A>9</DIV>
><DIV> </DIV>
><DIV>The above patch adds additional debug to the lber memory functions.&n=
b=3D
>sp;=3D20
>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 =
=3D
>at the=3D20
>beginning)</DIV>
><DIV>2. Checks for both values being there on all free and realloc=3D20
>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 =
=3D
>easier to=3D20
>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 =
=3D
>memory=3D20
>allocated. Note: this value won't be correct if the library is =3D
>running=3D20
></DIV>
><DIV>in the kernel or for multi-threaded applications, as there is no =3D
>lock=3D20
>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 =
=3D
>very=3D20
>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>
>
>--=3D_045C7138.7E1FB730--
>
>
--=_2E765B5B.52339AF0
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"><FONT=20
size=3D1>
<DIV>Yes you are correct. The storing of the pattern at the end =
of=20
the</DIV>
<DIV>buffer will violate boundary constraints. I will fix it.</DIV>
<DIV> </DIV>
<DIV>In the mean time, there is a bug ber_memrealloc. If=20
LDAP_MEMORY_DEBUG</DIV>
<DIV>is defined and realloc fails, then variable new is never initialized.<=
/DIV>
<DIV> </DIV>
<DIV>Fix:</DIV>
<DIV>Index:=20
memory.c<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>RCS=20
file: /repo/OpenLDAP/pkg/ldap/libraries/liblber/memory.c,v<BR>retrieving=20=
revision 1.27<BR>diff -u -w -r1.27 memory.c<BR>--- memory.c 2000/05/13=
=20
00:36:07 1.27<BR>+++ memory.c 2000/06/09 21:40:56<BR>@@ -198,7 =
+198,7=20
@@<BR> void *<BR> ber_memrealloc( void* p, ber_len_t s=20
)<BR> {<BR>- void *new;<BR>+ void *new =3D=20
NULL;<BR> ber_int_options.lbo_valid =3D=20
LBER_INITIALIZED;<BR> <BR> /* realloc(NULL,s) -> =
malloc(s)=20
*/</DIV>
<DIV> </DIV>
<DIV>-Steve</DIV></FONT><BR><BR>>>> "Kurt D. Zeilenga"=20
<Kurt@OpenLDAP.org> 09-Jun-00 3:26:44 PM >>><BR>Looks like =
this=20
would violate alignment restrictions<BR>on many CPU?<BR><BR>Also,=20
s/(int|long)/ber_len_t/<BR><BR>Kurt<BR><BR>At 06:18 PM 6/9/00 GMT,=20
VTAG@novell.com wrote:<BR>>Full_Name: Alan Clark<BR>>Version:=20
devel<BR>>OS: Linux / NetWare / WinNT<BR>>URL:=20
ftp://ftp.openldap.org/incoming/aclark-000609.patch<BR>><BR>>The =
above=20
patch adds additional debug to the lber memory functions. =20
=3D<BR>>Specifically it<BR>>does the following:<BR>><BR>>1.&nbs=
p; Puts=20
a known value at the end of the buffer (one is already at the=20
=3D<BR>>beginning)<BR>>2. Checks for both values being there on all =
free and=20
realloc functions. =3D<BR>>This identifies<BR>> buffers =
that=20
have had their head or tail overwritten.<BR>>3. Any memory freed =
is=20
filled with poison - 0xff to make it easier to =3D<BR>>find code<BR>>=
=20
that uses memory after it is free'd.<BR>><BR>>Since we now have the =
buffer=20
size, at both alloc and free time,<BR>>I put in a little counter that =
gives=20
the current value for amount of =3D<BR>>memory allocated. Note: =
this=20
value won't be correct if the library is =3D<BR>>running=3D20<BR>>in =
the=20
kernel or for multi-threaded applications, as there is no lock =3D<BR>>a=
round=20
modification<BR>>of the counter.<BR>><BR>>I added a ber_get/get =
option=20
to get the value. This has proved very =3D<BR>>helpful to =
us<BR>>when=20
searching for memory leaks.<BR>><BR>>You're welcome to it if it =
seems=20
useful to you.<BR>><BR>>-Steve Sonntag<BR>>-Alan=20
Clark<BR>>Manager<BR>>Novell Directory=20
Services<BR>><BR>>--=3D_045C7138.7E1FB730<BR>>Content-Type: =
text/html;=20
charset=3DISO-8859-1<BR>>Content-Transfer-Encoding:=20
quoted-printable<BR>><BR>><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML =
4.0=20
Transitional//EN"><BR>><HTML><HEAD><BR>><META=20
content=3D3D"text/html; charset=3D3Diso-8859-1"=20
http-equiv=3D3DContent-Type=3D<BR>>><BR>><META content=3D3D"MSH=
TML=20
5.00.2014.210" name=3D3DGENERATOR></HEAD><BR>><BODY =
style=3D3D"FONT:=20
8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP:=20
=3D<BR>>2px"><BR>><DIV>Full_Name: Alan Clark<BR>Versio=
n:=20
devel<BR>OS: Linux / NetWare /=3D20<BR>>WinNT<BR>URL:=20
<A=3D20<BR>>href=3D3D"ftp://ftp.openldap.org/incoming/aclark-00060"&g=
t;ftp://ftp.openldap.or=3D<BR>>g/incoming/aclark-00060</A>9</DI=
V><BR>><DIV>&nbsp;</DIV><BR>><DIV>The=20
above patch adds additional debug to the lber memory=20
functions.&nb=3D<BR>>sp;=3D20<BR>>Specifically=20
it</DIV><BR>><DIV>does the=20
following:</DIV><BR>><DIV>&nbsp;</DIV><BR>><=
DIV>1.&nbsp;=20
Puts a known value at the end of the buffer (one is already =3D<BR>>at=
=20
the=3D20<BR>>beginning)</DIV><BR>><DIV>2. Checks for =
both values=20
being there on all free and realloc=3D20<BR>>functions.&nbsp; =
This=20
identifies</DIV><BR>><DIV>&nbsp; buffers that have had =
their=20
head or tail overwritten.</DIV><BR>><DIV>3.&nbsp; Any =
memory=20
freed is filled with poison - 0xff to make it =3D<BR>>easier to=3D20<BR>=
>find=20
code</DIV><BR>><DIV>&nbsp; that uses memory after it =
is=20
free'd.</DIV><BR>><DIV>&nbsp;</DIV><BR>><DIV=
>Since=20
we now have the buffer size, at both alloc and free=20
time,</DIV><BR>><DIV>I put in a little counter that gives =
the=20
current value for amount of =3D<BR>>memory=3D20<BR>>allocated.&nb=
sp; Note:=20
this value won't be correct if the library is=20
=3D<BR>>running=3D20<BR>></DIV><BR>><DIV>in the =
kernel or for=20
multi-threaded applications, as there is no =3D<BR>>lock=3D20<BR>>aro=
und=20
modification</DIV><BR>><DIV>of the=20
counter.</DIV><BR>><DIV>&nbsp;</DIV><BR>><DI=
V>I=20
added a ber_get/get option to get the value.&nbsp; This has proved=20
=3D<BR>>very=3D20<BR>>helpful to us</DIV><BR>><DIV>whe=
n=20
searching for memory=20
leaks.</DIV><BR>><DIV>&nbsp;</DIV><BR>><DIV&=
gt;You're=20
welcome to it if it seems useful to=20
you.</DIV><BR>><DIV>&nbsp;</DIV><BR>><DIV>=
;-Steve=20
Sonntag<BR>-Alan=20
Clark</DIV><BR>><DIV>Manager</DIV><BR>><DIV>N=
ovell=20
Directory=20
Services</DIV></BODY></HTML><BR>><BR>>--=3D_045C713=
8.7E1FB730--<BR>><BR>><BR></BODY></HTML>
--=_2E765B5B.52339AF0--