[vlc-devel] [patch] ensure p_pic->pf_release calls are performed carefuly

[Anthony Loiseau]

Hi,

Not sure I understand what you mean by "plugin", I will explain the
context more accurately. Also, since I have sent last mail I have
discovered that this problem is more weird as it appears to be.

Context:
Using git VLC and debian etch, I add a movie to the playlist with those
parameters : 

vlc -vvv --video-filter=deinterlace --deinterlace-mode=linear myFile.ts

I got a backtrace like this one
#0  0x00000000 in ?? ()
#1  0xaf59d550 in Deinterlace (p_filter=0x8457754, p_pic=0x83c5908) at
deinterlace.c:2185
#2  0xb7f1d4ed in RunThread (p_vout=0x83c5374) at
video_output/video_output.c:1013
#3  0xb7d79240 in start_thread ()
from /lib/tls/i686/cmov/libpthread.so.0
#4  0xb7e5149e in clone () from /lib/tls/i686/cmov/libc.so.6


Frame #1 is the unprotected call to pf_release().


NB: This command works fine:
vlc -vvv --vout-filter=deinterlace --deinterlace-mode=linear  myFile.ts


The weird thing is on the frame 1, about deinterlace mode:
p_vout->p_sys->i_mode = 3
The mode 3 seems not to be the linear one:
#define DEINTERLACE_BLEND   3
#define DEINTERLACE_LINEAR  5

But maybe its normal since linear deinterlace seems disabled
(deinterlace.c:2158)
p_filter->psz_object_name is ok: "deinterlace"


NB2: I can give you more infos such as full backtraces, or open a track
ticket if needed.

regards
Anthony Loiseau

Le lundi 14 avril 2008 à 16:14 +0300, Rémi Denis-Courmont a écrit :
> Le mardi 8 avril 2008, Anthony Loiseau a écrit :
> > I have crossed a segmentation fault with a not protected call to
> > "p_pic->pf_release()" (video_filter/deinterlace.c:2185).
> >
> > Most of those calls are already protected by "if( p_pic->pf_release
> > )", this patch ensure the test to be performed before all calls to
> > p_pic->pf_release().
> 
> Do we know which plugins fail to set the callback? (and if it makes much 
> sense not to set the callback except in some really corner cases).
> 
> I suspect this is yet another attempt to use an object before it's been 
> initialized. If that is the case, checking for pf_release NULL-ity will 
> not fix the problem - merely hide it in some cases.
>