Memory leaks in y4mdenoise with 64-bit Linux

--===============5598607437793509936==
Content-Type: multipart/alternative; boundary="0-342669582-1286817748=:46654"

--0-342669582-1286817748=:46654
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Bernhard:

I've been digging through y4mdenoise's code today, and so far, I haven't fo=
und any obvious reason why it should be running out of memory.=A0 I ran it =
with a fake 720x576 progressive PAL image stream, generated from a 720x480 =
progressive NTSC-sized image stream, but nothing is going wrong.

I have assertions that make sure dynamically-allocated memory is cleared ou=
t regularly, so the only possibility I have left is that there's something =
wrong with my memory allocation itself.=A0 Luckily, all memory allocation i=
s done in Allocator classes.

Since this problem started with y4mdenoise version 3, the first thing I wou=
ld like you to do is to undefine SET_REGION_IMPLEMENTED_WITH_VECTOR and BOR=
DEREXTENTBOUNDARYSET_IMPLEMENTED_WITH_VECTOR in MotionSearcher.hh -- that s=
hould factor out whether it's some weird issue with the VariableSizeAllocat=
or class.=A0 (Do this with the latest code, not version 3.)

In the letter you sent back on September 6, I noticed that the number of le=
aked bytes, divided by the number of leaked blocks, is ~256KB.=A0 Multiple =
allocators use that size, i.e. 262144 bytes.=A0 So if the above hack doesn'=
t magically make the problem go away, please modify SearchBorder.hh so that=
 m_oMovedRegionSetAllocator is initialized with 393216 (i.e. 384KB) and m_o=
MovedRegionAllocator is initialized with 524288 (i.e. 512KB), and modify Se=
archWindow.hh so that m_oPSBNAllocator is initialized with 786432 (i.e. 768=
KB).=A0 Then tell me what the leak summary says.=A0 Hopefully that'll narro=
w down which allocator is keeping memory after it's supposed to be purged.

So far, I suspect that I'm doing something wrong that doesn't manifest unde=
r 32-bit Linux, but manifests under 64-bit Linux.=A0 I'm doing some strange=
 pointer-arithmetic in my allocator classes in order to divide a single sys=
tem-allocated block into pieces, but as far as I can tell, none of it shoul=
d break just because the pointer/word size has changed from 32 to 64 bits.

Thanks for helping me track this down!=A0 Sorry for the hassle.

Steven Boswell

=0A=0A=0A      
--0-342669582-1286817748=:46654
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;">Bernhard:<br><br>I've been digging through y4=
mdenoise's code today, and so far, I haven't found any obvious reason why i=
t should be running out of memory.&nbsp; I ran it with a fake 720x576 progr=
essive PAL image stream, generated from a 720x480 progressive NTSC-sized im=
age stream, but nothing is going wrong.<br><br>I have assertions that make =
sure dynamically-allocated memory is cleared out regularly, so the only pos=
sibility I have left is that there's something wrong with my memory allocat=
ion itself.&nbsp; Luckily, all memory allocation is done in Allocator class=
es.<br><br>Since this problem started with y4mdenoise version 3, the first =
thing I would like you to do is to undefine SET_REGION_IMPLEMENTED_WITH_VEC=
TOR and BORDEREXTENTBOUNDARYSET_IMPLEMENTED_WITH_VECTOR in MotionSearcher.h=
h -- that should factor out whether it's some weird issue with the
 VariableSizeAllocator class.&nbsp; (Do this with the latest code, not vers=
ion 3.)<br><br>In the letter you sent back on September 6, I noticed that t=
he number of leaked bytes, divided by the number of leaked blocks, is ~256K=
B.&nbsp; Multiple allocators use that size, i.e. 262144 bytes.&nbsp; So if =
the above hack doesn't magically make the problem go away, please modify Se=
archBorder.hh so that m_oMovedRegionSetAllocator is initialized with 393216=
 (i.e. 384KB) and m_oMovedRegionAllocator is initialized with 524288 (i.e. =
512KB), and modify SearchWindow.hh so that m_oPSBNAllocator is initialized =
with 786432 (i.e. 768KB).&nbsp; Then tell me what the leak summary says.&nb=
sp; Hopefully that'll narrow down which allocator is keeping memory after i=
t's supposed to be purged.<br><br>So far, I suspect that I'm doing somethin=
g wrong that doesn't manifest under 32-bit Linux, but manifests under 64-bi=
t Linux.&nbsp; I'm doing some strange pointer-arithmetic in my
 allocator classes in order to divide a single system-allocated block into =
pieces, but as far as I can tell, none of it should break just because the =
pointer/word size has changed from 32 to 64 bits.<br><br>Thanks for helping=
 me track this down!&nbsp; Sorry for the hassle.<br><br>Steven Boswell<br><=
br></td></tr></table><br>=0A=0A      
--0-342669582-1286817748=:46654--


--===============5598607437793509936==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
--===============5598607437793509936==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Mjpeg-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mjpeg-developer

--===============5598607437793509936==--