glimagesink : lockup when using overlay and going back to ready state

[philippe renon]

Hi,
I forgot to mention that the exact same lockups happen with 1.6.0. I switched to master in the hope that the latest gl commits would solve the issues.

I would like to mention that a non gl pipeline (i.e. "videotestsrc ! d3dvideosink") never locks up where the gl one does systematically.The gl lockups are reproducible 100% of the time in one or two mouse clicks.

I have attached a full backtrace of the lockup that happens when going from Running to Ready state : full_backtrace_ready.txt
I have also attached a full backtrace of another lockup on resize : full_backtrace_resize.txtThe lockup on resize is particular in the sense that it happens only on one resize scenario.The video gadget and its window are embedded in a larger application.Resizing the widget through a splitter or max/minimizing the application does not lead to the lockup.The video widget has a console panel that can be shown or hidden.Opening the console panel does not lead to a lockup. Closing it does... Both events trigger a resize of the main/parent window.

And, thanks Xavier for mentioning how glimagesink creates a private child window. I'll be less clueless when reading the code. But don't expect a fix coming from me anytime soon though... I'll continue to look at the code but more to learn than to fix.
But I can help by providing test results or testing patches.

Regards,Philippe.



     Le Lundi 5 octobre 2015 18h01, Xavier Claessens <xavier.claessens at collabora.com> a écrit :
   
 

 Hi,

This sounds familiar indeed, but my fixes for the bugs I saw are all
included in the 1.6 release, so it must be something else or a more
recent regression.

On win32, GStreamer create its own internal child window to not mess up
with user's window. So it is normal it destroy that window when
finalizing the gl context, that won't destroy user's window.

Could you please send me the full backtrace (all threads)?

Regards,
Xavier Claessens.


Le lundi 05 octobre 2015 à 11:25 +0100, Nicolas Dufresne a écrit :
> Le lundi 05 octobre 2015 à 07:15 +0000, philippe renon a écrit :
> > It was reproduced on a post 1.6.0 master compiled under Windows
> > 7/MingW. Overlay window is provided by a Qt 5.4.1 app. Pipeline runs
> > fine otherwise.
> > 
> > Here are some back traces taken during the lockup:
> > 
> > Thread 1 is locked while finalizing the gl context.
> > Thread 22 is locked while trying to destroy a window (!?!)
> > Thread 21 is waiting for nav event (which is, I guess, ok).
> 
> Hi,
> 
> my colleague (in CC) have hit this issue recently, I think he'll be
> able to provide what he found. Please keep him in CC as he's on on this
> mailing list. This is specific to Windows and we could not find enough
> information to be able to solve this issue completely.
> 
> cheers,
> Nicolas




 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151005/7f83b966/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: full_backtrace_resize.txt
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151005/7f83b966/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: full_backtrace_ready.txt
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151005/7f83b966/attachment-0003.txt>