Re: [Development] [QML] Singletons are deleted before the other objects
[..] > > IMHO deleting first the QML singletons then the rest of the Active > > objects > > > > is also wrong, because some of the active objects might need these > > singletons. > > > > I think the right way is to delete all the active objects first, then QML > > > > singletons, try delete again all the active objects (supposing that the > > QML > > singletons will create new objects in Component.onDestruction), then at > > the > > very end, all the C++ singletons. IMHO this is the right way to do it, and > > is not a hack at all. Doing something right, even if it's harder, is not a > > hack ... > > And I feel that this is trying to solve a problem at the wrong level, hence > me calling it a hack. No doubt we have many hacks in place, but they come > at a cost of maintenance and complexity an already complex shutdown > procedure. (/me points to qdeclarativeelement_destructor :) . So if we > wanted to add this complexity, then I think it needs a better > justification. I'm afraid I don't see that yet. > I don't see a better justification than the fact that this is the right way to do it > At run-time you can rely on the life time of singletons. When the > application is being shut down and you rely on a specific order of > destruction, then I think you have to take care of it in your application. > (And we may be missing tools to achieve that) I can't do it in my application, I'm trying to create a standalone QML *plugin* and I have no control when it's created/destroyed. [..] > > > I don't see how using a weak pointer will fix the problem, who will > > delete > > > > the singleton object in the end? > > As we have established earlier, the singleton _does_ get deleted by the > engine. The subject of this email thread gives it away :). > > Hmm, I apologize, I may have misunderstood or rather misinterpreted an > earlier statement of yours about what's happening. I understood "active > objects may still need to access the singletons in their destructor" as > pointer based access and I (perhaps mistakenly?) concluded that you're > experiencing crashes from users of the singleton _to_ the singleton due to > dangling pointers. If that's not the case, could you elaborate a bit on > what kind of access this is? Yes, that is the case and I still fail see how a weak pointer will help me to fix the problem... I'm using the the singleton as a central manager for file handles, memory allocators and many other resources. When a new object is created it uses this singleton to create and access its resources and when is destroyed it needs to use the same singleton to save some data, but the singleton it's not there anymore so it can't save its state and release its resources. Of course this is my use case, but you'll find many other use cases when a singletons must be the very last object that needs to be deleted. E.g. a Settings singleton which the active object needs it to save their states... > >>> I can't reference it > > > > for every object that depends on it, because, BTW, there are cases when > > the VM doesn't delete all the objects! Yes it has lots of memleaks at the > > end! > > What are you trying to say here? Is throwing mud supposed to motivate and > convince me? :( > No, not at all! I'm sorry if you see it that way ... I just tried to explain why your proposed workaround doesn't work... [..] > > At this point it's your word against mine :). You can try to convince me to > invest time to implement the behavior you'd like. You can try to implement > it yourself and convince me or some other approver to approve the change. > Or you can try to convince somebody else to implement the change. If you check the thread from the beginning you'll see that I'm not the only one who thinks that the current behavior is wrong. IMHO your approach is wrong, we all agreed that the current singletons behavior is not ok, but you still want use cases in order convince you that it needs to be fixed :). It is impossible for me (and for everybody else) to give you all the possible use cases out there when the singletons must be deleted last... IMHO you should ask yourself if there is any use case when the singleton should be deleted first ;-)... I think it will much faster to implement it myself :), if nobody wants to approve it, then I'll just keep for myself ;-)... Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On Monday, September 29, 2014 04:16:05 PM Harri Porten wrote: > On Mon, 29 Sep 2014, Simon Hausmann wrote: > > Yes, with emphasis on "until". Note that we are now talking about the "end > > of the application" situation, so our agreement ends right there ;-). We > > are talking about the time the QQmlEngine destructor is executed, which > > from a QML engine perspective is the "end of the application" point of > > time. What happens during that period of time is just as "fishy" as when > > tearing down a C++ application: The order of destruction for global > > objects between several compilation units is undefined. In C++ you cannot > > rely on it (I think you can rely on the order within a unit), so you > > prepare yourself with levels of indirection and/or weak references. > > I was thinking the same for a long time. Until I discovered (the hard way) > a that at least one aspect of the C++ behavior is standardized: the order > of destruction is guaranteed to be the reverse of the construction (see > [basic.start.term]). > > I ran into this because of a singleton being encapsuled within a function > using a 'static' object. The crashes upon application exit seemed > arbitrary at first but turned out to be well-defined :) > > Which deletion order is the best for QML... maybe it can't be changed > anymore. I'd just generally vouch for a *defined* order (even if > problematic) rather than an undefined one. Right, that makes sense. In C++ the problem stems from the diversity of compilers, which we (unfortunately :) don't have with Qml. There is only one implementation and it defines the behavior. The question is how much we want to change the behavior. We could implement a reverse order destruction, if somebody makes a good case for it. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On Mon, 29 Sep 2014, Simon Hausmann wrote: > Yes, with emphasis on "until". Note that we are now talking about the "end of > the application" situation, so our agreement ends right there ;-). We are > talking about the time the QQmlEngine destructor is executed, which from a QML > engine perspective is the "end of the application" point of time. What happens > during that period of time is just as "fishy" as when tearing down a C++ > application: The order of destruction for global objects between several > compilation units is undefined. In C++ you cannot rely on it (I think you can > rely on the order within a unit), so you prepare yourself with levels of > indirection and/or weak references. I was thinking the same for a long time. Until I discovered (the hard way) a that at least one aspect of the C++ behavior is standardized: the order of destruction is guaranteed to be the reverse of the construction (see [basic.start.term]). I ran into this because of a singleton being encapsuled within a function using a 'static' object. The crashes upon application exit seemed arbitrary at first but turned out to be well-defined :) Which deletion order is the best for QML... maybe it can't be changed anymore. I'd just generally vouch for a *defined* order (even if problematic) rather than an undefined one. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On Wednesday 24. September 2014 23.10.01 BogDan wrote: [...] > Hi, > > Do we all agree that the singletons, by definition, must be available to > any object at any time until the end of the application? Yes, with emphasis on "until". Note that we are now talking about the "end of the application" situation, so our agreement ends right there ;-). We are talking about the time the QQmlEngine destructor is executed, which from a QML engine perspective is the "end of the application" point of time. What happens during that period of time is just as "fishy" as when tearing down a C++ application: The order of destruction for global objects between several compilation units is undefined. In C++ you cannot rely on it (I think you can rely on the order within a unit), so you prepare yourself with levels of indirection and/or weak references. Right now the order of destruction in the QML engine is defined like this (by the existence of one implementation only): 1) Singletons are deleted first 2) The remaining JavaScript objects are deleted at random We can't change (2) really and we can't swap step 1 and 2 because it breaks for singletons that _are_ JavaScript objects. (to be continued further down) > IMHO deleting first the QML singletons then the rest of the Active objects > is also wrong, because some of the active objects might need these > singletons. > > I think the right way is to delete all the active objects first, then QML > singletons, try delete again all the active objects (supposing that the QML > singletons will create new objects in Component.onDestruction), then at the > very end, all the C++ singletons. IMHO this is the right way to do it, and > is not a hack at all. Doing something right, even if it's harder, is not a > hack ... And I feel that this is trying to solve a problem at the wrong level, hence me calling it a hack. No doubt we have many hacks in place, but they come at a cost of maintenance and complexity an already complex shutdown procedure. (/me points to qdeclarativeelement_destructor :) . So if we wanted to add this complexity, then I think it needs a better justification. I'm afraid I don't see that yet. At run-time you can rely on the life time of singletons. When the application is being shut down and you rely on a specific order of destruction, then I think you have to take care of it in your application. (And we may be missing tools to achieve that) Note that this is separate from the order of destruction "between" singletons - here it might makes sense to implement destruction in reversal to construction, although construction is non-deterministic from the framework's point of view. > I don't see how using a weak pointer will fix the problem, who will delete > the singleton object in the end? As we have established earlier, the singleton _does_ get deleted by the engine. The subject of this email thread gives it away :). Hmm, I apologize, I may have misunderstood or rather misinterpreted an earlier statement of yours about what's happening. I understood "active objects may still need to access the singletons in their destructor" as pointer based access and I (perhaps mistakenly?) concluded that you're experiencing crashes from users of the singleton _to_ the singleton due to dangling pointers. If that's not the case, could you elaborate a bit on what kind of access this is? >>> I can't reference it > for every object that depends on it, because, BTW, there are cases when > the VM doesn't delete all the objects! Yes it has lots of memleaks at the > end! What are you trying to say here? Is throwing mud supposed to motivate and convince me? :( If there are memory leaks, then I think we agree that those should be fixed. In this email thread we are talking about semantics during engine shutdown. At this point it's your word against mine :). You can try to convince me to invest time to implement the behavior you'd like. You can try to implement it yourself and convince me or some other approver to approve the change. Or you can try to convince somebody else to implement the change. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
- Original Message - From: Simon Hausmann To: BogDan Cc: Chris Adams ; Qt Development Group Sent: Thursday, September 25, 2014 8:34 AM Subject: Re: SV: [Development] [QML] Singletons are deleted before the other objects On Monday, September 22, 2014 02:28:06 AM BogDan wrote: > - Original Message - > From: Simon Hausmann > To: BogDan > Cc: Chris Adams ; Qt Development Group > Sent: Monday, September 22, 2014 11:56 AM > Subject: Re: SV: [Development] [QML] Singletons are deleted before the > otherobjects > On Monday 22. September 2014 01.33.14 BogDan wrote: > > On Monday 22. September 2014 01.19.17 BogDan wrote: > > > Hi Simon, > > > > > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > > > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > > > fixed it. The same problem is in previous releases. > > > > > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > > > The other active objects are deleted in MemoryManager::sweep(*true*) > > > which is called by MemoryManager::~MemoryManager() > > > which is called by ExecutionEngine::~ExecutionEngine() > > > which is called by QV8Engine::~QV8Engine() > > > which is called by QJSEngine::~QJSEngine() > > > which is called *after* QQmlEngine::~QQmlEngine() > > > > > > Check the call-stack: > > > 0 MyObject::~MyObject myobject.cpp44 0x7fffd141eb4b > > > 1 MyObject::~MyObject myobject.cpp46 0x7fffd141ec8a > > > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > > qv4qobjectwrapper.cpp 10180x75f79ee1 f9ee33f96f9ee33f96 3 > > > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > > qv4qobjectwrapper.cpp 10210x75f79f2e 4 > > > QV4::MemoryManager::sweep qv4mm.cpp 377 0x75efd080 > > > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x75efda18 > > > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > > > 0x75ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > > > 0x7606b7f2 > > > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7606b87e > > > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x75e64b1e > > > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x75fb0b5d > > > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x75fb0b8c > > > 12 QObjectPrivate::deleteChildren qobject.cpp 19430x7599efd0 > > > 13 QObject::~QObject qobject.cpp 10340x7599d760 > > > 14 QWindow::~QWindow qwindow.cpp 210 0x763f5bdc > > > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp1099 > > > 0x76bc0353 > > > 16 QQuickView::~QQuickView qquickview.cpp 220 0x76c9fe35 > > > 17 mainmain.cpp12 0x4021fb > > > > > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > > > after/in MemoryManager::~MemoryManager ... > > > > Ahh, so what you're talking about are the _JavaScript_ wrappers for the > > singletons, not the singleton objects themselves. That explains the > > confusion. > > > > Yes, due to the inheritance the final garbage collection runs as the very > > last step - and it has to, conceptually. I'm wondering: What code do you > > have running at that point that gets still called? Is it code in C++ > > destructors? > > > > > > > > > > > > > > Yes, the code from their destructors needs the singletons objects which > > are > > not available anymore. > > When are those destructors called? > > We need a little bit more information here, because it isn't obvious how to > solve this. There's naturally a pool of objects around that haven't been > garbage collected. On engine shutdown the garbage collector sweeps them all, > and there's naturally no way to define an order of destruction if you think > of such an environment. > > > > > > I know that there is a pool of active objects, what I think is wrong is to > delete the register singletons before you delete these objects. > > > The active objects destructors are called by MemoryManager::sweep. > These objects register themselves in the singleton object when they are > created and they must unregister themselves in the destructor when they > are deleted. But as you seen the singletons are deleted before, so there is > no way to properly unregister themselves! This is why I believe that the > singletons must be the very last objects that are deleted (just like in > any
Re: [Development] [QML] Singletons are deleted before the other objects
On Monday, September 22, 2014 02:28:06 AM BogDan wrote: > - Original Message - > From: Simon Hausmann > To: BogDan > Cc: Chris Adams ; Qt Development Group > Sent: Monday, September 22, 2014 11:56 AM > Subject: Re: SV: [Development] [QML] Singletons are deleted before the > other objects > On Monday 22. September 2014 01.33.14 BogDan wrote: > > On Monday 22. September 2014 01.19.17 BogDan wrote: > > > Hi Simon, > > > > > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > > > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > > > fixed it. The same problem is in previous releases. > > > > > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > > > The other active objects are deleted in MemoryManager::sweep(*true*) > > > which is called by MemoryManager::~MemoryManager() > > > which is called by ExecutionEngine::~ExecutionEngine() > > > which is called by QV8Engine::~QV8Engine() > > > which is called by QJSEngine::~QJSEngine() > > > which is called *after* QQmlEngine::~QQmlEngine() > > > > > > Check the call-stack: > > > 0 MyObject::~MyObject myobject.cpp44 0x7fffd141eb4b > > > 1 MyObject::~MyObject myobject.cpp46 0x7fffd141ec8a > > > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > > qv4qobjectwrapper.cpp 10180x75f79ee1 f9ee33f96f9ee33f96 3 > > > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > > qv4qobjectwrapper.cpp 10210x75f79f2e 4 > > > QV4::MemoryManager::sweep qv4mm.cpp 377 0x75efd080 > > > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x75efda18 > > > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > > > 0x75ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > > > 0x7606b7f2 > > > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7606b87e > > > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x75e64b1e > > > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x75fb0b5d > > > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x75fb0b8c > > > 12 QObjectPrivate::deleteChildren qobject.cpp 19430x7599efd0 > > > 13 QObject::~QObject qobject.cpp 10340x7599d760 > > > 14 QWindow::~QWindow qwindow.cpp 210 0x763f5bdc > > > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp1099 > > > 0x76bc0353 > > > 16 QQuickView::~QQuickView qquickview.cpp 220 0x76c9fe35 > > > 17 mainmain.cpp12 0x4021fb > > > > > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > > > after/in MemoryManager::~MemoryManager ... > > > > Ahh, so what you're talking about are the _JavaScript_ wrappers for the > > singletons, not the singleton objects themselves. That explains the > > confusion. > > > > Yes, due to the inheritance the final garbage collection runs as the very > > last step - and it has to, conceptually. I'm wondering: What code do you > > have running at that point that gets still called? Is it code in C++ > > destructors? > > > > > > > > > > > > > > Yes, the code from their destructors needs the singletons objects which > > are > > not available anymore. > > When are those destructors called? > > We need a little bit more information here, because it isn't obvious how to > solve this. There's naturally a pool of objects around that haven't been > garbage collected. On engine shutdown the garbage collector sweeps them all, > and there's naturally no way to define an order of destruction if you think > of such an environment. > > > > > > I know that there is a pool of active objects, what I think is wrong is to > delete the register singletons before you delete these objects. > > > The active objects destructors are called by MemoryManager::sweep. > These objects register themselves in the singleton object when they are > created and they must unregister themselves in the destructor when they > are deleted. But as you seen the singletons are deleted before, so there is > no way to properly unregister themselves! This is why I believe that the > singletons must be the very last objects that are deleted (just like in > any other languages). > > So, my proposal is to move the singletons deletion from > QmlEngine::~QQmlEngine():910 to another place which is called after > MemoryManager::sweep(*true*) is doing its job. > > I'd like to
Re: [Development] [QML] Singletons are deleted before the other objects
On 19/09/2014 10:37 PM, BogDan wrote: > Hello folks, > >Singletons registered using qmlRegisterSingletonType, are deleted *before* > the other active objects. I consider it to be wrong because some of the active > objects may still need to access the singletons in their destructor ... > > IMHO singletons should be the very last objects deleted (also in the reverse > order). > > Is there any reason why they are deleted before the other active objects? > Or this is just a bug? > > Cheers, > BogDan. > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Would this also be related to https://bugreports.qt-project.org/browse/QTBUG-38422? Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
- Original Message - From: Simon Hausmann To: BogDan Cc: Chris Adams ; Qt Development Group Sent: Monday, September 22, 2014 11:56 AM Subject: Re: SV: [Development] [QML] Singletons are deleted before the other objects On Monday 22. September 2014 01.33.14 BogDan wrote: > On Monday 22. September 2014 01.19.17 BogDan wrote: > > Hi Simon, > > > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > > fixed it. The same problem is in previous releases. > > > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > > The other active objects are deleted in MemoryManager::sweep(*true*) > > which is called by MemoryManager::~MemoryManager() > > which is called by ExecutionEngine::~ExecutionEngine() > > which is called by QV8Engine::~QV8Engine() > > which is called by QJSEngine::~QJSEngine() > > which is called *after* QQmlEngine::~QQmlEngine() > > > > Check the call-stack: > > 0 MyObject::~MyObject myobject.cpp44 0x7fffd141eb4b > > 1 MyObject::~MyObject myobject.cpp46 0x7fffd141ec8a > > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > qv4qobjectwrapper.cpp 10180x75f79ee1 f9ee33f96f9ee33f96 3 > > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > qv4qobjectwrapper.cpp 10210x75f79f2e 4 > > QV4::MemoryManager::sweep qv4mm.cpp 377 0x75efd080 > > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x75efda18 > > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > > 0x75ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > > 0x7606b7f2 > > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7606b87e > > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x75e64b1e > > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x75fb0b5d > > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x75fb0b8c > > 12 QObjectPrivate::deleteChildren qobject.cpp 19430x7599efd0 > > 13 QObject::~QObject qobject.cpp 10340x7599d760 > > 14 QWindow::~QWindow qwindow.cpp 210 0x763f5bdc > > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp10990x76bc0353 > > 16 QQuickView::~QQuickView qquickview.cpp 220 0x76c9fe35 > > 17 mainmain.cpp12 0x4021fb > > > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > > after/in MemoryManager::~MemoryManager ... > > Ahh, so what you're talking about are the _JavaScript_ wrappers for the > singletons, not the singleton objects themselves. That explains the > confusion. > > Yes, due to the inheritance the final garbage collection runs as the very > last step - and it has to, conceptually. I'm wondering: What code do you > have running at that point that gets still called? Is it code in C++ > destructors? > > > > > > > Yes, the code from their destructors needs the singletons objects which are > not available anymore. When are those destructors called? We need a little bit more information here, because it isn't obvious how to solve this. There's naturally a pool of objects around that haven't been garbage collected. On engine shutdown the garbage collector sweeps them all, and there's naturally no way to define an order of destruction if you think of such an environment. I know that there is a pool of active objects, what I think is wrong is to delete the register singletons before you delete these objects. The active objects destructors are called by MemoryManager::sweep. These objects register themselves in the singleton object when they are created and they must unregister themselves in the destructor when they are deleted. But as you seen the singletons are deleted before, so there is no way to properly unregister themselves! This is why I believe that the singletons must be the very last objects that are deleted (just like in any other languages). So, my proposal is to move the singletons deletion from QmlEngine::~QQmlEngine():910 to another place which is called after MemoryManager::sweep(*true*) is doing its job. I'd like to mention one more thing, the singletons and the other objects are register in a standalone plugin. Please let me know if you need more info. Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On Monday 22. September 2014 01.33.14 BogDan wrote: > On Monday 22. September 2014 01.19.17 BogDan wrote: > > Hi Simon, > > > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > > fixed it. The same problem is in previous releases. > > > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > > The other active objects are deleted in MemoryManager::sweep(*true*) > > which is called by MemoryManager::~MemoryManager() > > which is called by ExecutionEngine::~ExecutionEngine() > > which is called by QV8Engine::~QV8Engine() > > which is called by QJSEngine::~QJSEngine() > > which is called *after* QQmlEngine::~QQmlEngine() > > > > Check the call-stack: > > 0 MyObject::~MyObject myobject.cpp44 0x7fffd141eb4b > > 1 MyObject::~MyObject myobject.cpp46 0x7fffd141ec8a > > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > qv4qobjectwrapper.cpp 10180x75f79ee1 f9ee33f96f9ee33f96 3 > > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > qv4qobjectwrapper.cpp 10210x75f79f2e 4 > > QV4::MemoryManager::sweep qv4mm.cpp 377 0x75efd080 > > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x75efda18 > > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > > 0x75ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > > 0x7606b7f2 > > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7606b87e > > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x75e64b1e > > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x75fb0b5d > > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x75fb0b8c > > 12 QObjectPrivate::deleteChildren qobject.cpp 19430x7599efd0 > > 13 QObject::~QObject qobject.cpp 10340x7599d760 > > 14 QWindow::~QWindow qwindow.cpp 210 0x763f5bdc > > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp10990x76bc0353 > > 16 QQuickView::~QQuickView qquickview.cpp 220 0x76c9fe35 > > 17 mainmain.cpp12 0x4021fb > > > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > > after/in MemoryManager::~MemoryManager ... > > Ahh, so what you're talking about are the _JavaScript_ wrappers for the > singletons, not the singleton objects themselves. That explains the > confusion. > > Yes, due to the inheritance the final garbage collection runs as the very > last step - and it has to, conceptually. I'm wondering: What code do you > have running at that point that gets still called? Is it code in C++ > destructors? > > > > > > > Yes, the code from their destructors needs the singletons objects which are > not available anymore. When are those destructors called? We need a little bit more information here, because it isn't obvious how to solve this. There's naturally a pool of objects around that haven't been garbage collected. On engine shutdown the garbage collector sweeps them all, and there's naturally no way to define an order of destruction if you think of such an environment. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On Monday 22. September 2014 01.19.17 BogDan wrote: > Hi Simon, > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > fixed it. The same problem is in previous releases. > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > The other active objects are deleted in MemoryManager::sweep(*true*) > which is called by MemoryManager::~MemoryManager() > which is called by ExecutionEngine::~ExecutionEngine() > which is called by QV8Engine::~QV8Engine() > which is called by QJSEngine::~QJSEngine() > which is called *after* QQmlEngine::~QQmlEngine() > > Check the call-stack: > 0 MyObject::~MyObject myobject.cpp44 0x7fffd141eb4b > 1 MyObject::~MyObject myobject.cpp46 0x7fffd141ec8a > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > qv4qobjectwrapper.cpp 10180x75f79ee1 f9ee33f96f9ee33f96 3 > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > qv4qobjectwrapper.cpp 10210x75f79f2e 4 > QV4::MemoryManager::sweep qv4mm.cpp 377 0x75efd080 > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x75efda18 > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > 0x75ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > 0x7606b7f2 > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7606b87e > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x75e64b1e > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x75fb0b5d > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x75fb0b8c > 12 QObjectPrivate::deleteChildren qobject.cpp 19430x7599efd0 > 13 QObject::~QObject qobject.cpp 10340x7599d760 > 14 QWindow::~QWindow qwindow.cpp 210 0x763f5bdc > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp10990x76bc0353 > 16 QQuickView::~QQuickView qquickview.cpp 220 0x76c9fe35 > 17 mainmain.cpp12 0x4021fb > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > after/in MemoryManager::~MemoryManager ... Ahh, so what you're talking about are the _JavaScript_ wrappers for the singletons, not the singleton objects themselves. That explains the confusion. Yes, due to the inheritance the final garbage collection runs as the very last step - and it has to, conceptually. I'm wondering: What code do you have running at that point that gets still called? Is it code in C++ destructors? Yes, the code from their destructors needs the singletons objects which are not available anymore. Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On Monday 22. September 2014 01.19.17 BogDan wrote: > Hi Simon, > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > fixed it. The same problem is in previous releases. > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > The other active objects are deleted in MemoryManager::sweep(*true*) > which is called by MemoryManager::~MemoryManager() > which is called by ExecutionEngine::~ExecutionEngine() > which is called by QV8Engine::~QV8Engine() > which is called by QJSEngine::~QJSEngine() > which is called *after* QQmlEngine::~QQmlEngine() > > Check the call-stack: > 0 MyObject::~MyObject myobject.cpp44 0x7fffd141eb4b > 1 MyObject::~MyObject myobject.cpp46 0x7fffd141ec8a > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > qv4qobjectwrapper.cpp 10180x75f79ee1 f9ee33f96f9ee33f96 3 > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > qv4qobjectwrapper.cpp 10210x75f79f2e 4 > QV4::MemoryManager::sweep qv4mm.cpp 377 0x75efd080 > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x75efda18 > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > 0x75ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > 0x7606b7f2 > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7606b87e > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x75e64b1e > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x75fb0b5d > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x75fb0b8c > 12 QObjectPrivate::deleteChildren qobject.cpp 19430x7599efd0 > 13 QObject::~QObject qobject.cpp 10340x7599d760 > 14 QWindow::~QWindow qwindow.cpp 210 0x763f5bdc > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp10990x76bc0353 > 16 QQuickView::~QQuickView qquickview.cpp 220 0x76c9fe35 > 17 mainmain.cpp12 0x4021fb > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > after/in MemoryManager::~MemoryManager ... Ahh, so what you're talking about are the _JavaScript_ wrappers for the singletons, not the singleton objects themselves. That explains the confusion. Yes, due to the inheritance the final garbage collection runs as the very last step - and it has to, conceptually. I'm wondering: What code do you have running at that point that gets still called? Is it code in C++ destructors? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
Hi Simon, I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 branch (sha1 f9ee33f96), is a little bit old, but I bet nobody fixed it. The same problem is in previous releases. So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 The other active objects are deleted in MemoryManager::sweep(*true*) which is called by MemoryManager::~MemoryManager() which is called by ExecutionEngine::~ExecutionEngine() which is called by QV8Engine::~QV8Engine() which is called by QJSEngine::~QJSEngine() which is called *after* QQmlEngine::~QQmlEngine() Check the call-stack: 0 MyObject::~MyObject myobject.cpp44 0x7fffd141eb4b 1 MyObject::~MyObject myobject.cpp46 0x7fffd141ec8a 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter qv4qobjectwrapper.cpp 10180x75f79ee1 f9ee33f96f9ee33f96 3 (anonymous namespace)::QObjectDeleter::~QObjectDeleter qv4qobjectwrapper.cpp 10210x75f79f2e 4 QV4::MemoryManager::sweep qv4mm.cpp 377 0x75efd080 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x75efda18 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 0x75ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 0x7606b7f2 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7606b87e 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x75e64b1e 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x75fb0b5d 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x75fb0b8c 12 QObjectPrivate::deleteChildren qobject.cpp 19430x7599efd0 13 QObject::~QObject qobject.cpp 10340x7599d760 14 QWindow::~QWindow qwindow.cpp 210 0x763f5bdc 15 QQuickWindow::~QQuickWindow qquickwindow.cpp10990x76bc0353 16 QQuickView::~QQuickView qquickview.cpp 220 0x76c9fe35 17 mainmain.cpp12 0x4021fb IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved after/in MemoryManager::~MemoryManager ... Cheers, BogDan. From: Hausmann Simon To: Chris Adams ; BogDan Cc: Qt Development Group Sent: Monday, September 22, 2014 9:33 AM Subject: SV: [Development] [QML] Singletons are deleted before the other objects Hi, In general I agree with Chris. However I'm a little puzzled that this is happening. If you take a look at the QQmlEngine destructor you can see that singletons are deleted last. So I'm wondering what is happening in your app Bogdan. Can you create a minimal test case? Thanks, Simon Fra: Chris Adams Sendt: 05:45 mandag 22. september 2014 Til: BogDan Kopi: Qt Development Group Emne: Re: [Development] [QML] Singletons are deleted before the other objects Hi, On Fri, Sep 19, 2014 at 10:37 PM, BogDan wrote: Hello folks, > > Singletons registered using qmlRegisterSingletonType, are deleted *before* >the other active objects. I consider it to be wrong because some of the active >objects may still need to access the singletons in their destructor ... > >IMHO singletons should be the very last objects deleted (also in the reverse >order). > I tend to agree that they should be deleted last. Enforcing deletion in the reverse order to how they were registered might impose some slight performance penalty at instantiation time, however, depending on how the deletion order is determined at cleanup time, since they are instantiated on demand (and hence possibly out-of-order). >Is there any reason why they are deleted before the other active objects? >Or this is just a bug? > I don't believe that there is any particular reason for deleting them prior to other active objects, but perhaps Simon or Lars can correct me on this point. Nonetheless, I don't think that the current behaviour is a bug, per-se, as the destruction order was never documented or guaranteed, as far as I know. Cheers, Chris. >Cheers, >BogDan. > >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
Hi, In general I agree with Chris. However I'm a little puzzled that this is happening. If you take a look at the QQmlEngine destructor you can see that singletons are deleted last. So I'm wondering what is happening in your app Bogdan. Can you create a minimal test case? Thanks, Simon Fra: Chris Adams Sendt: 05:45 mandag 22. september 2014 Til: BogDan Kopi: Qt Development Group Emne: Re: [Development] [QML] Singletons are deleted before the other objects Hi, On Fri, Sep 19, 2014 at 10:37 PM, BogDan mailto:bog_dan...@yahoo.com>> wrote: Hello folks, Singletons registered using qmlRegisterSingletonType, are deleted *before* the other active objects. I consider it to be wrong because some of the active objects may still need to access the singletons in their destructor ... IMHO singletons should be the very last objects deleted (also in the reverse order). I tend to agree that they should be deleted last. Enforcing deletion in the reverse order to how they were registered might impose some slight performance penalty at instantiation time, however, depending on how the deletion order is determined at cleanup time, since they are instantiated on demand (and hence possibly out-of-order). Is there any reason why they are deleted before the other active objects? Or this is just a bug? I don't believe that there is any particular reason for deleting them prior to other active objects, but perhaps Simon or Lars can correct me on this point. Nonetheless, I don't think that the current behaviour is a bug, per-se, as the destruction order was never documented or guaranteed, as far as I know. Cheers, Chris. Cheers, BogDan. ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
I tend to agree. Sounds like a bug to me. Cheers, Lars On 19/09/14 14:37, "BogDan" wrote: >Hello folks, > > Singletons registered using qmlRegisterSingletonType, are deleted >*before* >the other active objects. I consider it to be wrong because some of the >active >objects may still need to access the singletons in their destructor ... > >IMHO singletons should be the very last objects deleted (also in the >reverse >order). > >Is there any reason why they are deleted before the other active objects? >Or this is just a bug? > >Cheers, >BogDan. > >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
Hi, On Fri, Sep 19, 2014 at 10:37 PM, BogDan wrote: > Hello folks, > > Singletons registered using qmlRegisterSingletonType, are deleted > *before* > the other active objects. I consider it to be wrong because some of the > active > objects may still need to access the singletons in their destructor ... > > IMHO singletons should be the very last objects deleted (also in the > reverse > order). > I tend to agree that they should be deleted last. Enforcing deletion in the reverse order to how they were registered might impose some slight performance penalty at instantiation time, however, depending on how the deletion order is determined at cleanup time, since they are instantiated on demand (and hence possibly out-of-order). > > Is there any reason why they are deleted before the other active objects? > Or this is just a bug? > I don't believe that there is any particular reason for deleting them prior to other active objects, but perhaps Simon or Lars can correct me on this point. Nonetheless, I don't think that the current behaviour is a bug, per-se, as the destruction order was never documented or guaranteed, as far as I know. Cheers, Chris. > > Cheers, > BogDan. > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [QML] Singletons are deleted before the other objects
Hello folks, Singletons registered using qmlRegisterSingletonType, are deleted *before* the other active objects. I consider it to be wrong because some of the active objects may still need to access the singletons in their destructor ... IMHO singletons should be the very last objects deleted (also in the reverse order). Is there any reason why they are deleted before the other active objects? Or this is just a bug? Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development