Re: Fix for memory corruption in yuvdeinterlace

Hi Steven,

> // do NOT do this - the "in0 -w" computes an address 'w' bytes BEFORE the
> // start of the buffer

Steven, as I mentioned *often* before, your bugfix was none. It at best
introduced another, different bug, or it changed it into something
different...

> 	The buffer management (or rather the address calculation) in 
> 	yuvdeinterlace has been problematic for a long time.

Because me not having enough time to fix the various fixes (and well,
some real bugs introduced by me, myself...) of the bugfixes... Sorry for
that, but I have a real life, too... (In which I currently hate most,
that valgrind does not exist for Win32(boss likes it)... BTW: Anyone any
ideas on that?...)...

Strange enough, with the old version (before your fix) valgrid, while
moaning about *a whole lot* of other things...(*sigh*) did *not* moan
about memory management inside constructor and destructor. *And* glibc
was not moaning, too. Now, they both do on my x86-machine... (This is
why I have a local (completely different, with a fix of the fix and
recursive :]) development copy, here on my hard disk which I never put
into the cvs. It at least works for me. Eventually I will do the same
than Mato? Dunno. 

> 	What I was seeing was crashes in free() because the incorrect
> 	address was being passed.

I did not have that one. As said above checked with valgrind a long time
ago. McOSX???

> 	It also appears that malloc/free implementations differ a lot.  Others
> 	(with linux systems) were having no issues with yuvdeinterlace but 
> 	it was consistently crashing on a OSX system.

OK, so we might have needed some "#if OSX", then?

> 	The program no longer crashes on either platform so the problem, 
> 	from my perspective, is resolved.  

No, this is definately wrong. In the version with your bugfix (from CVS)
it crashes on *my* machine. Ever. At the end of execution I get a
glibc-crash moaning about memory leaks...

> 	It just feels "sloppy" to over allocate the buffers rather than 
> 	check for the boundary conditions.  Why not allocate the exact 
> 	size needed and check the address so that it doesn't go outside
> 	the frame?

Because it is *a* *lot* *CENSORED* slower. While you might not mind
that, I (and others) do. And the maximum amount of boundary-"violation"
can be *precisely* defined before allocating the memory. (See other
email for shabby ASCII-Art-Image on the concept for yuvdeinterlace's
memory "management"...)

cu
Stefan



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/