[Libav-user] Array bounds error while reading from ffmpeg data array using Purify

["René J.V. Bertin"]

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é