Builder ffmpeg64-solaris10-i386 Build #13528

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

1. git update ( 9 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 ( 11 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_64.sh' failed ( 0 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Zhao Zhili

   zhilizhaoohnoyoudont@tencent.com

Timing:

All Changes:

:

1. Change #263179

   Category	ffmpeg
   Changed by	Zhao Zhili <zhilizhaoohnoyoudont@tencent.com>
   Changed at	Wed 01 Apr 2026 15:56:37
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	c695ad11977983ffb98697dfc793be9bd456a2c3

   Comments

   avfilter/vidstabtransform: use existing ctx variable for outlink
   Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

   Changed files

   • libavfilter/vf_vidstabtransform.c

2. Change #263180

   Category	ffmpeg
   Changed by	Zhao Zhili <zhilizhaoohnoyoudont@tencent.com>
   Changed at	Wed 01 Apr 2026 15:56:37
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	316531e61cf234ce184de7e750410bded7c9bb14

   Comments

   avfilter/vidstabtransform: always use in-place transform path
   libvidstab's vsTransformPrepare() takes different internal code paths
   for in-place (src == dest) vs. separate-buffer operation. The
   separate-buffer path stores a shallow copy of the source frame pointer
   in td->src without allocating internal memory (srcMalloced stays 0).
   When a subsequent frame takes the in-place path, vsFrameIsNull(&td->src)
   is false so vsFrameAllocate() is skipped, and vsFrameCopy() writes into
   the stale pointer left over from the previous frame, corrupting memory
   that the caller no longer owns.
   
   Whether a given frame is writable depends on pipeline scheduling and
   frame reference management, which can change between FFmpeg versions.
   Since FFmpeg 8.1, changes in the scheduler caused some frames to arrive
   as non-writable, leading to alternation between in-place and
   separate-buffer paths that triggered the bug.
   
   Fix this by marking the input pad with AVFILTERPAD_FLAG_NEEDS_WRITABLE.
   
   Fix #22595

   Changed files

   • libavfilter/vf_vidstabtransform.c