Builder ffmpegsos-solaris10-i386 Build #14058

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpegsos-solaris10-i386' triggered this build

Steps and Logfiles:

1. git update ( 4 secs )
   1. stdio
2. shell 'gsed -i ...' ( 0 secs )
   1. stdio
3. shell_1 'gsed -i ...' ( 0 secs )
   1. stdio
4. shell_2 'gsed -i ...' failed ( 0 secs )
   1. stdio
5. shell_3 './configure --samples="../../../ffmpeg/fate-suite" ...' failed ( 6 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 0 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config_sos.sh' failed ( 0 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Martin Storsjö

   martinohnoyoudont@martin.st

Timing:

All Changes:

:

1. Change #270350

   Category	ffmpeg
   Changed by	Martin Storsjö <martinohnoyoudont@martin.st>
   Changed at	Wed 10 Jun 2026 20:03:01
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	d05786cf23ead5a92f722b3ba4516d99d7f108ad

   Comments

   aarch64: vp9lpf: Fix GCS violations
   The aarch64 VP9 loopfilters actually violate aarch64 GCS
   (Guarded Control Stack), even though we marked the code as GCS
   compliant in 846746be4b8edd66be8be2c123b0072de2636e9d.
   
   This means that builds with GCS enabled, after that commit,
   will crash when decoding VP9, on future hardware (or current
   QEMU) that supports GCS. This also goes for ffmpeg version 8.1.1
   where the GCS enabling was backported.
   
   This matches the fix that was done for hevcdsp in
   1f7ed8a78de1da743a359913ce05cc258a400b5d.
   
   This issue wasn't observed if running checkasm in QEMU - therefore,
   I thought all GCS issues had been fixed by
   846746be4b8edd66be8be2c123b0072de2636e9d. (If I would have
   tested the full "make fate" with QEMU, the issue would
   have appeared though.)
   
   However with the new checkasm, some of the GCS violations
   do appear even in checkasm.
   
   The reason is that the checkasm vp9 test intentionally craft
   input pixels that attempt to trigger all the individual
   separate cases in each input buffer (in
   randomize_loopfilter_buffers). This means that the checkasm
   tests actually never test or exercise the early exit cases,
   which are the ones that violate GCS.
   
   With the new checkasm, the call to "bench_new" always test
   running the code at least once, even if not benchmarking.
   
   As the input buffers weren't reinitialized between the test
   and "bench_new", the pixel differences now differ from the
   initial setup, so that the code now some times (often) would
   end up hitting the early exit cases.
   
   Ideally, the vp9 checkasm test would be repeated to cover all
   cases of input buffers that allow early exits, in addition to
   covering the case with all different cases in one block.

   Changed files

   • libavcodec/aarch64/vp9lpf_16bpp_neon.S
   • libavcodec/aarch64/vp9lpf_neon.S