[MPlayer-cvslog] r35203 - in trunk/libmpcodecs: vf_delogo.c vf_unsharp.c

[Ingo Brückl]

Reimar Döffinger wrote on Thu, 20 Sep 2012 05:39:29 +0200:

> On 20 Sep 2012, at 00:05, Ingo Brückl <ib at wupperonline.de> wrote:
>> Reimar Döffinger wrote on Wed, 19 Sep 2012 21:41:20 +0200:
>>
>>> On Wed, Sep 19, 2012 at 09:02:14PM +0200, Ingo Brückl wrote:
>>>>> static int put_image( struct vf_instance *vf, mp_image_t *mpi, double pts) {
>>>>>     mp_image_t *dmpi = mpi->priv;
>>>>> +    mpi->priv = NULL;
>>>>>
>>>>>     if( !(mpi->flags & MP_IMGFLAG_DIRECT) )
>>>>>         // no DR, so get a new image! hope we'll get DR buffer:
>>>>
>>>> This makes 'mplayer -vf-add unsharp=l7x7:1.7 <file>' crash with SIGSEGV after
>>>> the file has been played (applies to '-vf-add delogo' as well).
>>
> But are you sure it is exactly this commit, and also that there is no
> other valgrind error before?

There is no valgrind error before and the crash is totally reproducible.
SIGSEGV with this patch and if I comment the nulling, it's fine again.

I currently can reproduce it on XviD .avi only, it doesn't seem to occur with
x264 .mp4 (and if I remember correctly, it did occur only with these .avi
files the days before, but I can't swear). In order to make the crash happen,
the file must reach its end by itself, i.e. you must not jump over its end to
end playback, but you may jump near to its end.

> Because that is a crash deep in the exit deallocation code in the libc,
> I can't see how nulling some field in a filter should be able to cause a
> crash there.

I was already wondering myself about that. It's strange, but reproducible.
(Please see your private e-mail.)

Maybe it's because I'm using shared ffmpeg or because of my old CPU. We
already had issues that nobody but me could reproduce.

Ingo