[FFmpeg-trac] #8747(swscale:new): libswscale 4.3 crash if output buffer is not 16 bytes aligned for yuv2rgb conversion
FFmpeg
trac at avcodec.org
Sat Jun 20 04:11:34 EEST 2020
#8747: libswscale 4.3 crash if output buffer is not 16 bytes aligned for yuv2rgb
conversion
------------------------------------+-----------------------------------
Reporter: melanconj | Owner:
Type: defect | Status: new
Priority: important | Component: swscale
Version: git-master | Resolution:
Keywords: regression | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
------------------------------------+-----------------------------------
Comment (by melanconj):
Apologies, I should have mentioned our real world use case in the report.
We've noticed this regression when trying to integrate 4.3 in our
application. Our test infrastructure has been crashing consistently with
the new version. In our case, the application is a C# program doing
interop into swscale. Arrays in C# are 8 bytes aligned so we crash about
half the time we call into swscale. I've put the alignment check in the
sample to ensure it reproduces systematically, although I'm testing a bit
more now and it seems C allocations are consistently 16 bytes aligned for
this buffer size. This small PoC for a smaller buffer shows unaligned
buffers about half the time in 32 bits:
{{{
#include <stdint.h>
#include <stdio.h>
int main()
{
for (int i = 0; i < 8; i++) {
void* dst = malloc(320*240*3);
if (((int64_t)dst & ~0xF) == (int64_t)dst) {
printf("aligned\n");
} else {
printf("unaligned\n");
}
}
}
}}}
I took a look into other languages to see if C# was the odd one here, it
seems few offer 16 bytes guarantees for their arrays. For example both
Rust and Go are only providing a type-size alignment guarantee for their
arrays. C and C++ appear to give 16 bytes in 64 bits, but only 8 for 32
bits programs.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8747#comment:3>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list