[FFmpeg-devel] [PATCH] av_malloc() workaround for QNX platform

Michael Niedermayer michaelni at gmx.at
Thu Feb 7 22:04:45 CET 2013


On Thu, Feb 07, 2013 at 10:57:16PM +0200, Mike Gorchak wrote:
> > 0x0000FE0 + 0x00000020
> > is
> > 0x1000 not 0x10000
> 
> Sorry for typo.
> 
> > and you stated above "32 bytes aligned and size also 32 bytes"
> > that makes an allocation of 64bytes due to
> > "ptr = malloc(size + ALIGN);"
> > thus 0x1000 up to 0x101F is allocated and there are 32bytes available
> > at the pointer as requested
> 
> I agree this code is correct, but anyway something trashing the heap
> when this code is active. Maybe code somewhere has va_malloc() and
> corresponding free() instead of va_free(), but this situation is hard
> to check. I've checked vice versa situation when malloc()/va_free() is
> used, and have not found any cases. Memory heap corruption is 100%
> reproducible using H.264 codec, but when posix_memalign() is used, all
> goes fine, because free() and va_free() are the same.

make sure you use latest git
can you try with something like valgrind or asan ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130207/50d7a8c3/attachment.asc>


More information about the ffmpeg-devel mailing list