[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