Builder ffmpeg64-solaris10-i386 Build #14112

Results:

Failed

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

1. git updating ( 7 secs )
   1. stdio
2. shell  
   1. - no logs -
3. shell_1  
   1. - no logs -
4. shell_2  
   1. - no logs -
5. shell_3  
   1. - no logs -
6. shell_4  
   1. - no logs -
7. shell_5  
   1. - no logs -

Build Properties:

Forced Build Properties:

Responsible Users:

1. Chun-Min Chang

   chun.m.changohnoyoudont@gmail.com
2. Michael Niedermayer

   michaelohnoyoudont@niedermayer.cc

Timing:

All Changes:

:

1. Change #281548

   Category	ffmpeg
   Changed by	Chun-Min Chang <chun.m.changohnoyoudont@gmail.com>
   Changed at	Sat 12 Sep 2026 05:20:09
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	a024f8c5413d2c7e653d1843547050319c33fbe0

   Comments

   avcodec/vp9: unref next_refs in vp9_decode_flush
   vp9_decode_flush() releases s->s.frames[], s->s.refs[] and s->s.ref_frames[]
   but leaves s->next_refs[] referenced. Under frame threading,
   vp9_decode_update_thread_context() seeds a worker's s->s.refs[] from the source
   worker's next_refs[] (not from its refs[]). The pre-flush next_refs therefore
   survive a flush and can be resurrected into a worker's refs[] afterwards,
   letting a subsequent inter frame pass the reference-availability check and
   decode against references that no longer exist.
   
   Unref s->next_refs[] alongside s->s.refs[] so that flushing fully drops the
   decoder's reference state.
   
   Fixes: heap out-of-bounds read and write after avcodec_flush_buffers()
   Fixes: 34c2zQaUquOl
   Found-by: Mozilla's bugmon automation, reviewed and reported by Chun-Min Chang <cchang@mozilla.com>
   Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

   Changed files

   • libavcodec/vp9.c

2. Change #281549

   Category	ffmpeg
   Changed by	Chun-Min Chang <chun.m.changohnoyoudont@gmail.com>
   Changed at	Sat 12 Sep 2026 05:20:09
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	b772f5033c729ef2502bee8972cf497661ac096f

   Comments

   avcodec/vp8: do not await a negative reference-frame row
   vp8_mc_luma()/vp8_mc_chroma() derive the reference row to await from y_off,
   which includes the block's motion vector, and never floor it at 0, so a vector
   pointing above the frame makes the awaited row negative.
   
   For a 16x16 block the expression still bottoms out at 0 for any vector inside
   clamp_mv()'s +-16 px margin, which is why the omission is easy to miss. The
   split modes, however, predict 8- and 4-row blocks, where a much smaller vector
   suffices: at mb_y 0 with block_h 8, y_off -12 gives (3 - 12 + 8) >> 4 == -1,
   and with block_h 4, y_off -8 does. SPLITMV sub-vectors are moreover never
   clamped, and NEWMV deltas are applied after clamp_mv(), so larger vectors are
   reachable too.
   
   ff_thread_progress_await() returns as soon as progress >= n, and progress is
   initialised to -1 under frame threading, so a negative row is treated as
   already reached and no happens-before edge with the thread decoding the
   reference frame is established. emulated_edge_mc() nevertheless clamps the
   source rectangle and reads row 0 of the reference plane, i.e. the row is read
   without waiting for it to be written.
   
   Floor the awaited row at 0, the lowest row the subsequent read can touch. The
   floor only ever raises a negative row to 0, never above a row already awaited
   on the same frame, so it cannot introduce a stall.
   
   Fixes: unsynchronized cross-thread read of reference frame rows
   Fixes: IFu1maPxsZFJ
   Found-by: Mozilla's AI bot, reviewed and reported by Chun-Min Chang <cchang@mozilla.com>
   Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

   Changed files

   • libavcodec/vp8.c

3. Change #281550

   Category	ffmpeg
   Changed by	Michael Niedermayer <michaelohnoyoudont@niedermayer.cc>
   Changed at	Sat 12 Sep 2026 05:20:09
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	9e17d6c9f187a9e6ba8624f00fa14b5d40dbdf24

   Comments

   avcodec/rv34: do not await a negative reference-frame row
   Fixes: unsynchronized cross-thread read of reference frame rows
   Fixes: IFu1maPxsZFJ
   Found-by: Mozilla's AI bot, reviewed and reported by Chun-Min Chang <cchang@mozilla.com>

   Changed files

   • libavcodec/rv34.c

4. Change #281551

   Category	ffmpeg
   Changed by	Michael Niedermayer <michaelohnoyoudont@niedermayer.cc>
   Changed at	Sat 12 Sep 2026 05:20:09
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	709f8fececd0ec6586208010e1d578abf3340dfc

   Comments

   avcodec/rv34: do not copy an unused reference line in the edge emulation
   The luma interpolation filters read two lines above and three lines
   below a block, so rv34_mc() needs 8 * height + 5 reference lines, but it
   had emulated_edge_mc() copy one more.
   
   Fixes: data race between rv40_loop_filter() and rv34_mc() under frame threading

   Changed files

   • libavcodec/rv34.c