Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QDeclarativeView and the QML debugger
tedmiddleton last edited by
I've found something a bit strange. On OSX, under some circumstances, when I destroy a QDeclarativeView and then try to create a new one, my process hangs inside of QDeclarativeView's constructor. Here's the stack trace:
@0 select$DARWIN_EXTSN 0x7fff8dcab322
1 qt_safe_select 0x100e55b66
2 QNativeSocketEnginePrivate::nativeSelect 0x100b8c4d4
3 QNativeSocketEngine::waitForReadOrWrite 0x100b89b4a
4 QAbstractSocket::waitForReadyRead 0x100b80084
5 QPacketProtocol::waitForReadyRead 0x10034923e
6 QTcpServerConnection::waitForMessage 0x105787c8a
7 non-virtual thunk to QTcpServerConnection::waitForMessage() 0x105787cad
8 QDeclarativeDebugServer::waitForMessage 0x10035842a
9 QDeclarativeDebugService::waitForMessage 0x10034b080
10 QJSDebugService::addEngine 0x10035ec38
11 QDeclarativeEnginePrivate::init 0x10019ffce
12 QDeclarativeViewPrivate::init 0x100270ef8
13 QDeclarativeView::QDeclarativeView 0x100270eba
14 DomainLoginScreen::DomainLoginScreen domainloginscreen.cpp 9 0x10001d00d
15 DomainLoginScreen::DomainLoginScreen domainloginscreen.cpp 25 0x10001cfcd
16 ShowDomainLoginInteraction::ShowDomainLoginInteraction active_states.cpp 73 0x10001ec81
17 ShowDomainLoginInteraction::ShowDomainLoginInteraction active_states.cpp 76 0x10001e945
18 boost::statechart::state<ShowDomainLoginInteraction, Active, boost::mpl::list<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, (boost::statechart::history_mode)0>::shallow_construct state.hpp 89 0x10001259c
Note that this only happens when I enable QML debugging in my project build options.
I could probably put together a debug version of Qt to investigate this, but before I do that, does anyone know anything about this? What might be causing this? I'm creating a QMainWindow, then I'm creating a QDeclarativeView and assigning it as the QMainWindows's central widget. Then I create a new QDeclarativeView and assign that as the QMainWindow's central widget.
Did you "file a bug report":https://bugreports.qt-project.org/ ? That is the only way to make sure a developer that knows the relevant code will actually notice your problem.
tedmiddleton last edited by
No - I didn't. I'm trying to figure out whether this is my problem or a bug (probably my problem). If I'm going to file a bug report, I'd like to put together a small test program to demo the problem. Before I do that, I wanted to know if anyone had seen this before and perhaps had some advice.
I'll see if I can make a small test program to submit with the bug.
I would not be surprised if the declarative view is blocking for the debugger to connect... with the debugger sitting there, considering his day's work done after the first view was closed:).