<html><body><div style="color:#000; background-color:#fff; font-family:lucida console, sans-serif;font-size:13px"><div id="yui_3_16_0_1_1444070495678_5899"><span>Hi,</span></div><div id="yui_3_16_0_1_1444070495678_5937"><br></div>I forgot to mention that the exact same lockups happen with 1.6.0.<div id="yui_3_16_0_1_1444070495678_6168" dir="ltr"> I switched to master in the hope that the latest gl commits would solve the issues.<br><span></span></div><div id="yui_3_16_0_1_1444070495678_5938"><br></div><div id="yui_3_16_0_1_1444070495678_6169" dir="ltr">I would like to mention that a non gl pipeline (i.e. "videotestsrc ! d3dvideosink") never locks up where the gl one does systematically.</div><div id="yui_3_16_0_1_1444070495678_6888" dir="ltr">The gl lockups are reproducible 100% of the time in one or two mouse clicks.<br></div><div id="yui_3_16_0_1_1444070495678_6199" dir="ltr"><br></div><div id="yui_3_16_0_1_1444070495678_6230" dir="ltr">I have attached a full backtrace of the lockup that happens when going from Running to Ready state : <span id="yui_3_16_0_1_1444070495678_6368" class="">full_backtrace_ready.txt</span></div><div id="yui_3_16_0_1_1444070495678_6375" dir="ltr"><br><span id="yui_3_16_0_1_1444070495678_6368" class=""></span></div><div id="yui_3_16_0_1_1444070495678_6697" dir="ltr"><span id="yui_3_16_0_1_1444070495678_6368" class="">I have also attached a full backtrace of another lockup on resize : </span><span id="yui_3_16_0_1_1444070495678_6368" class="">full_backtrace_resize.txt</span></div><div id="yui_3_16_0_1_1444070495678_6550" dir="ltr"><span id="yui_3_16_0_1_1444070495678_6368" class="">The lockup on resize is particular in the sense that it happens only on one resize scenario.</span></div><div id="yui_3_16_0_1_1444070495678_7010" dir="ltr"><span id="yui_3_16_0_1_1444070495678_6368" class="">The video gadget and its window are embedded in a larger application.</span></div><div id="yui_3_16_0_1_1444070495678_7234" dir="ltr"><span id="yui_3_16_0_1_1444070495678_6368" class="">Resizing the widget through a splitter or max/minimizing the application does not lead to the lockup.</span></div><div id="yui_3_16_0_1_1444070495678_7235" dir="ltr"><span id="yui_3_16_0_1_1444070495678_6368" class="">The video widget has a console panel that can be shown or hidden.</span></div><div id="yui_3_16_0_1_1444070495678_7236" dir="ltr"><span id="yui_3_16_0_1_1444070495678_6368" class="">Opening the console panel does not lead to a lockup. Closing it does... Both events trigger a resize of the main/parent window.<br></span></div><div id="yui_3_16_0_1_1444070495678_7237" dir="ltr"><span id="yui_3_16_0_1_1444070495678_6368" class=""><br></span></div><div class="" dir="ltr" id="yui_3_16_0_1_1444070495678_5987">And, thanks Xavier for mentioning how glimagesink creates a private child window.</div><div id="yui_3_16_0_1_1444070495678_6767" class="" dir="ltr"> I'll be less clueless when reading the code. But don't expect a fix coming from me anytime soon though...</div><div id="yui_3_16_0_1_1444070495678_8725" class="" dir="ltr"> I'll continue to look at the code but more to learn than to fix.<br></div><div id="yui_3_16_0_1_1444070495678_6808" class="" dir="ltr">But I can help by providing test results or testing patches.<br class="" id="yui_3_16_0_1_1444070495678_6561"></div><div class="" id="yui_3_16_0_1_1444070495678_6166" dir="ltr"><br></div><div id="yui_3_16_0_1_1444070495678_7238" class="" dir="ltr">Regards,</div><div id="yui_3_16_0_1_1444070495678_7239" class="" dir="ltr">Philippe.<br class="" id="yui_3_16_0_1_1444070495678_6564"></div><br><div id="yui_3_16_0_1_1444070495678_7267" class="qtdSeparateBR"><br><br></div><div style="display: block;" id="yui_3_16_0_1_1444070495678_8698" class="yahoo_quoted"> <div id="yui_3_16_0_1_1444070495678_8697" style="font-family: lucida console, sans-serif; font-size: 13px;"> <div id="yui_3_16_0_1_1444070495678_8696" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div id="yui_3_16_0_1_1444070495678_8695" dir="ltr"> <font id="yui_3_16_0_1_1444070495678_8701" face="Arial" size="2"> Le Lundi 5 octobre 2015 18h01, Xavier Claessens <xavier.claessens@collabora.com> a écrit :<br> </font> </div> <blockquote id="yui_3_16_0_1_1444070495678_8700" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <br><br> <div id="yui_3_16_0_1_1444070495678_8699" class="y_msg_container">Hi,<br clear="none"><br clear="none">This sounds familiar indeed, but my fixes for the bugs I saw are all<br clear="none">included in the 1.6 release, so it must be something else or a more<br clear="none">recent regression.<br clear="none"><br clear="none">On win32, GStreamer create its own internal child window to not mess up<br clear="none">with user's window. So it is normal it destroy that window when<br clear="none">finalizing the gl context, that won't destroy user's window.<br clear="none"><br clear="none">Could you please send me the full backtrace (all threads)?<br clear="none"><br clear="none">Regards,<br clear="none">Xavier Claessens.<br clear="none"><br clear="none"><div class="yqt7920425666" id="yqtfd89583"><br clear="none">Le lundi 05 octobre 2015 à 11:25 +0100, Nicolas Dufresne a écrit :<br clear="none">> Le lundi 05 octobre 2015 à 07:15 +0000, philippe renon a écrit :<br clear="none">> > It was reproduced on a post 1.6.0 master compiled under Windows<br clear="none">> > 7/MingW. Overlay window is provided by a Qt 5.4.1 app. Pipeline runs<br clear="none">> > fine otherwise.<br clear="none">> > <br clear="none">> > Here are some back traces taken during the lockup:<br clear="none">> > <br clear="none">> > Thread 1 is locked while finalizing the gl context.<br clear="none">> > Thread 22 is locked while trying to destroy a window (!?!)<br clear="none">> > Thread 21 is waiting for nav event (which is, I guess, ok).<br clear="none">> <br clear="none">> Hi,<br clear="none">> <br clear="none">> my colleague (in CC) have hit this issue recently, I think he'll be<br clear="none">> able to provide what he found. Please keep him in CC as he's on on this<br clear="none">> mailing list. This is specific to Windows and we could not find enough<br clear="none">> information to be able to solve this issue completely.<br clear="none">> <br clear="none">> cheers,<br clear="none">> Nicolas<br clear="none"><br clear="none"><br clear="none"></div><br><br></div> </blockquote> </div> </div> </div></div></body></html>