Closing the QQuickView results in a crash

[dimovnike]

When calling close() or deleteLater() on the QQuickView object the app results in a crash, e.g. see the follosing code:

qDebug() << "start";
qmlView->close();
// CRASH HERE
qDebug() << "close() invoked";
qmlView->deleteLater();
qDebug() << "deleteLater() invoked";

Disposing the object is needed because QT doesnt allow to mix EGL and non-EGL windows, it produces this error "EGLFS: OpenGL windows cannot be mixed with others" and I need to delete the QML before showing a normal QMainWindow.

I tried to debug with gdb but it doesnt show very much, it shows something liek this:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./testgui5'.
Program terminated with signal 11, Segmentation fault.
#0  0xb0ed02d4 in ?? () from /usr/local/qt-5.4.1/plugins/mediaservice/libopenmaxilmediaplayer.so
(gdb) bt
#0  0xb0ed02d4 in ?? () from /usr/local/qt-5.4.1/plugins/mediaservice/libopenmaxilmediaplayer.so
#1  0xecb2f278 in ?? ()
#2  0xecb2f278 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[dimovnike]

More tests showed that this only affects a running video, if I pause video in QML before calling deleteLater() it works good (the object is properly destroyed as i get the destroyed() signal).

[Nightmare204]

@carlonluca IDK if this issue is related to #51.

I have a QQuickView which loads a video player in qml. As with EGLFS we don't have "window management" and therefore can't have applications that are not fullsize or are topmost, I decided to Close and Show the QQuickView which I found places the GUI on top.

I'm not using deleteLater(), but I reuse the same QQUickView. However after 20 to 25 "Close and Show" operations I have some similar behaviour to the one @dimovnike described.

Therefore as a Quick fix I decided to restart the full app after 15 "Close and Show" operations, but after long time that the app is running I start to have behaviours like the ones described in #51.....

Only one solution until today, manually restart the Raspberry Pi...

Could the fixes applied to POT5.2.0 be effective to all this?

[carlonluca]

Possible, but I never had time to try to reproduce this. Do you have a short code to reproduce?