[XviD-devel] mem_align.c problem

Rick Foos xvid-devel@xvid.org
Wed, 27 Nov 2002 09:58:49 -0600


This is a multi-part message in MIME format.

------=_NextPart_000_0205_01C295FB.955B1720
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0206_01C295FB.955B1720"


------=_NextPart_001_0206_01C295FB.955B1720
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I noticed the CACHE_LINESIZE 0 problem as well when building a C only =
version, and noted it in portab.h.=20

It seems that the appropriate place for the CACHE_LINESIZE 0 definition =
is when no architecture is defined.

I'm not sure what the proposal is for the final fix, but applying this =
diff to portab.h defines this case in the right place.

In build/generic, make -f Makefile.generic will then build a library =
that duplicates the problem.

Rick Foos
  ----- Original Message -----=20
  From: pikatu=20
  To: xvid-devel@xvid.org=20
  Sent: Wednesday, November 27, 2002 2:17 AM
  Subject: [XviD-devel] mem_align.c problem



  To demonstrate the problem  replace the file with the one I attach =
hereby=20
  and try to allocate and free a block with 0 alignment.

  You will see that xvid_free crashes.

  What I understand is that because you always examine the (mem-1) =
position=20
  you have to allocate at list size+1 bytes.=20

  In case of 0 alignment, you should assign size+1 bytes, put 1 in the =
first=20
  position, and return mem+1 so that xvid_free will free the correct =
block.

  This is not what happens now.
  You are allocating size+1 bytes and return that same pointer.
  Then xvid_free will free the same pointer in case *(mem-1) is zero.
  However, in case  *(mem-1) is not zero you have a problem.=20

  Actually=20
  *mem_ptr =3D 0;
  doesn't do anything.

  I am not sure how much this code is called with alignment 0, but in =
case it=20
  does it may lead to severe problems.

  Ilan Bar-On


------=_NextPart_001_0206_01C295FB.955B1720
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I noticed the CACHE_LINESIZE 0 problem =
as well when=20
building a C only version, and noted it in portab.h. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>It seems that the&nbsp;appropriate =
place for the=20
CACHE_LINESIZE 0 definition is when no architecture is =
defined.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure what the proposal is for =
the final=20
fix, but applying this diff to portab.h defines this case in the right=20
place.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In build/generic, make -f =
Makefile.generic will=20
then build a library that duplicates the problem.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Rick Foos</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dpikatu@012.net.il =
href=3D"mailto:pikatu@012.net.il">pikatu</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dxvid-devel@xvid.org=20
  href=3D"mailto:xvid-devel@xvid.org">xvid-devel@xvid.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, November 27, =
2002 2:17=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [XviD-devel] =
mem_align.c=20
  problem</DIV>
  <DIV><BR></DIV><BR>To demonstrate the problem&nbsp; replace the file =
with the=20
  one I attach hereby <BR>and try to allocate and free a block with 0=20
  alignment.<BR><BR>You will see that xvid_free crashes.<BR><BR>What I=20
  understand is that because you always examine the (mem-1) position =
<BR>you=20
  have to allocate at list size+1 bytes. <BR><BR>In case of 0 alignment, =
you=20
  should assign size+1 bytes, put 1 in the first <BR>position, and =
return mem+1=20
  so that xvid_free will free the correct block.<BR><BR>This is not what =
happens=20
  now.<BR>You are allocating size+1 bytes and return that same =
pointer.<BR>Then=20
  xvid_free will free the same pointer in case *(mem-1) is =
zero.<BR>However, in=20
  case&nbsp; *(mem-1) is not zero you have a problem. <BR><BR>Actually=20
  <BR>*mem_ptr =3D 0;<BR>doesn't do anything.<BR><BR>I am not sure how =
much this=20
  code is called with alignment 0, but in case it <BR>does it may lead =
to severe=20
  problems.<BR><BR>Ilan Bar-On<BR><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0206_01C295FB.955B1720--

------=_NextPart_000_0205_01C295FB.955B1720
Content-Type: text/plain;
	name="diff.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="diff.txt"

Index: portab.h=0A=
=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=0A=
RCS file: /xvid/xvidcore/src/portab.h,v=0A=
retrieving revision 1.39=0A=
diff -r1.39 portab.h=0A=
144c144=0A=
< #    define CACHE_LINE  16=0A=
---=0A=
> #    define CACHE_LINE  0=0A=

------=_NextPart_000_0205_01C295FB.955B1720--