Just some general thoughts:
On Dec 17, 2012, at 11:19, Navin wrote:
> I've got a piece of code which extracts every rgb pixel from a video and
> displays it without any problem. But when I ran it with Purify, I got these
> errors:
>
> [E] ABR: Array bounds read in GetFrame {197 occurrences}
> Reading 1 byte from 0x04ae0040 (1 byte at 0x04ae0040 illegal)
> Address 0x04ae0040 is 16 bytes before the beginning of a 1769472 byte
> block at 0x04ae0050
> Address 0x04ae0040 points to a malloc'd block in heap 0x003a0000
> Thread ID: 0x17c4
>
> So I reduced the code to just this
> pAreaInMemory[0] = g_pFrameRGB->data[0][0];
> and I'm still getting the error (which I've shown above).
> The code goes something like this (I've shown many of the initializations in
> GetFrame itself although they're supposed to be outside):
Are you compiling in 32 or 64 bits, i.e. are you reading 1 or 2 addresses ahead
of the allocated block? 2 address locations ahead could mean that the data
matrix indexing is 1-based and not 0-based, for instance.
Checking avcodec/avcodec.h, there's the following doxygen comment associated
with the AVFrame->data member:
/**
* pointer to the picture/channel planes.
* This might be different from the first allocated byte
* - encoding: Set by user
* - decoding: set by AVCodecContext.get_buffer()
*/
Maybe you're seeing exactly what's stated, that data[0][0] is different from
the first allocated byte?
> Why is there a bounds problem when reading from data[0][0] ? I noticed the
> way data is initialized in ffmpeg. Is this purify error something I can
> ignore (there's no memory leak. Just the bounds error) or can it lead to
> serious problems?
A leak error you could chose to ignore as they're often false alarms (memory
deallocated elsewhere). A bounds error is another issue because in this case
you're not just checking the location for a specific value but you're assuming
it contains a valid pixel. Which it most likely will not if the location is
indeed not within the allocated block. Whether that can lead to serious
problems only you can assess, but on some platforms you'd get an exception even
for reading an illegal address.
René
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
