Dear Gian, I have checked that of course. But this is not the case, the destructor has been reduced to a single call to qDebug (see my other mail) and the error persists. Also, when I set a breakpoint on the qDebug line, the debugger halts on the second call (both are already in the stack) which is again very suprising.
I use the debugger often and never had any problem like that before. Cheers, Etienne 2015-11-09 16:43 GMT+01:00 Gian Maxera <[email protected]>: > > > On 9 Nov 2015, at 15:38, Konstantin Tokarev <[email protected]> wrote: > > > > > > > > 09.11.2015, 18:22, "Etienne Sandré-Chardonnal" <[email protected]>: > >> Dear all, > >> > >> I am debugging an app which crashes when an object is being deleted. > The debuggers halt on a segmentation fault inside QObject destructor. The > object deletion was requested by a call to deleteLater() > >> > >> Here is what I get in the stack trace: > >> > >> 0 QObject::~QObject qobject.cpp 993 0x7ffff62c7580 > >> 1 RendererInterface::~RendererInterface rendererinterface.cpp > 119 0x60664f > >> 2 RendererInterface::~RendererInterface rendererinterface.cpp > 137 0x60667e > >> 3 qDeleteInEventHandler qobject.cpp 4391 0x7ffff62d06e5 > >> > >> How is it possible to have the destructor twice in the stack?? At the > beginning I was thinking this was a GDB bug (GDB/MinGW under windows is > buggy) but I get the same result when compiling the app under linux. > >> > >> Any idea how this can happen? > > > > Answer is definitely around lines 119-137 of rendererinterface.cpp > > > You are calling delete on the same object into the destructor. You are > doing something like that: > > delete this > > inside the destructor. > > Maybe there is some internal variable that got the “this” value and force > the object to try to destroy itself. > >
_______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
