Commit Message

The compound literals assigned to "components"
only exist within the scope of the if/else
block (thanks Mark Thompson for the better
explanation).
Thus, after this if/else block, "components"
ends up pointing to an arbitrary/undefined
array. With some compilers and depending on
optimization settings, these arbitrary values
may end up being the same value (i.e. 0 with
GNU GCC 9.x). Unfortunately, the GNU GCC
compiler, at least, never prints any warnings
about this.
This patch fixes this issue by assigning the
constant arrays to local variables at function
scope and then pointing "components" to those
as necessary.
Fixes #7915
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
---
libavcodec/vaapi_encode_mjpeg.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

On Friday, 07 June 2019 at 23:45, U. Artie Eoff wrote:
> The compound literals assigned to "components"> only exist within the scope of the if/else> block (thanks Mark Thompson for the better> explanation).> > Thus, after this if/else block, "components"> ends up pointing to an arbitrary/undefined> array. With some compilers and depending on> optimization settings, these arbitrary values> may end up being the same value (i.e. 0 with> GNU GCC 9.x). Unfortunately, the GNU GCC> compiler, at least, never prints any warnings> about this.> > This patch fixes this issue by assigning the> constant arrays to local variables at function> scope and then pointing "components" to those> as necessary.> > Fixes #7915
Brilliant detective work, Artie. Could you open a bug report with gcc
upstream? A case like this should get an explicit warning from gcc like
you pointed out.
Regards,
Dominik

Dominik 'Rathann' Mierzejewski:
> On Friday, 07 June 2019 at 23:45, U. Artie Eoff wrote:>> The compound literals assigned to "components">> only exist within the scope of the if/else>> block (thanks Mark Thompson for the better>> explanation).>>>> Thus, after this if/else block, "components">> ends up pointing to an arbitrary/undefined>> array. With some compilers and depending on>> optimization settings, these arbitrary values>> may end up being the same value (i.e. 0 with>> GNU GCC 9.x). Unfortunately, the GNU GCC>> compiler, at least, never prints any warnings>> about this.>>>> This patch fixes this issue by assigning the>> constant arrays to local variables at function>> scope and then pointing "components" to those>> as necessary.>>>> Fixes #7915> > Brilliant detective work, Artie. Could you open a bug report with gcc> upstream? A case like this should get an explicit warning from gcc like> you pointed out.> > Regards,> Dominik>
A request for this has already been opened [1].
It seems that this is also responsible for filesystem corruption on
linux when using a SSD cache + HDD combination (see [2]).
- Andreas
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
[2]: https://bugzilla.kernel.org/show_bug.cgi?id=203573

On Thu, Jun 13, 2019 at 15:41:55 +0000, Eoff, Ullysses A wrote:
> According to comments in the gcc request, it looks like we> could use " -fsanitize=address". Anyone care to test it> out to see if it will work?
The AddressSanatizer does not make this a warning at compile time (or
perhaps it may, additionally), but it instruments the binary with code
for analyzing and debugging address accesses, similar to valgrind:
https://github.com/google/sanitizers/wiki/AddressSanitizer
So this is not a permanent solution, but might be something for fate.
Moritz