Crash within Qt Code using drag and drop (Qt BUG?)
-
Hi, I have an intermittent crash within the Qt Code. I have run it with the Qt sources and the crash occurs on: Line 1273 of qcoreapplication.cpp.
It is due to a de-referenced pointer.
@void QCoreApplication::postEvent(QObject *receiver, QEvent *event, int priority)
{
if (receiver == 0) {
qWarning("QCoreApplication::postEvent: Unexpected null receiver");
delete event;
return;
}QThreadData * volatile * pdata = &receiver->d_func()->threadData; QThreadData *data = *pdata; <===================================== CRASH HERE if (!data) { // posting during destruction? just delete the event to prevent a leak delete event; return; } // lock the post event mutex data->postEventList.mutex.lock(); // if object has moved to another thread, follow it while (data != *pdata) { data->postEventList.mutex.unlock();@
This is within the drag->exec() function, however looks like it may be due to Qt posting application events.
For more information please see the thread on stack overflow:
-
Could you tells us more on what you try to achieve with drag & drop (It's not really clear from your code)
Are you trying to move Widgets around ?
-
The drag and drop code is quite long and covers a lot of possibilities. But essentially I am moving widgets about yes. I have two drop-able containers, one accepts one type of widget (A), the other takes another type (which is the container for the first type) (B).
The first type (A) requires the newly created widget to be deleted if it is generated from the side bar menu or not if it is dragged from the container (B).
The second type (B) requires the widget to be deleted if dragged from the sidebar, or not if dragged from the second type of droppable container.
Its fairly complex but all works as it should. The intermittent bug occurs rarely but I have written some code to make the mouse move around dragging and dropping which speeds up its occurrence (It still can be replicated without).
I will post up the stack trace from the bottom up (bottom level shown above):
qdnd_x11.cpp
@void QX11Data::xdndHandleFinished(QWidget *, const XEvent * xe, bool passive)
{
DEBUG("xdndHandleFinished");
const unsigned long *l = (const unsigned long *)xe->xclient.data.l;DNDDEBUG << "xdndHandleFinished, l[0]" << l[0] << "qt_xdnd_current_target" << qt_xdnd_current_target << "qt_xdnd_current_proxy_targe" << qt_xdnd_current_proxy_target; if (l[0]) { int at = findXdndDropTransactionByWindow(l[0]); if (at != -1) { restartXdndDropExpiryTimer(); QXdndDropTransaction t = X11->dndDropTransactions.takeAt(at); QDragManager *manager = QDragManager::self(); Window target = qt_xdnd_current_target; Window proxy_target = qt_xdnd_current_proxy_target; QWidget *embedding_widget = current_embedding_widget; QDrag *currentObject = manager->object; qt_xdnd_current_target = t.target; qt_xdnd_current_proxy_target = t.proxy_target; current_embedding_widget = t.embedding_widget; manager->object = t.object; if (!passive) (void) checkEmbedded(qt_xdnd_current_widget, xe); current_embedding_widget = 0; qt_xdnd_current_target = 0; qt_xdnd_current_proxy_target = 0; if (t.object) t.object->deleteLater(); <======================== qt_xdnd_current_target = target; qt_xdnd_current_proxy_target = proxy_target; current_embedding_widget = embedding_widget; manager->object = currentObject; } } waiting_for_status = false;}@
qapplication_x11.cpp
@
X11->xdndHandleLeave(widget, event, passive_only);
} else if (event->xclient.message_type == ATOM(XdndDrop)) {
X11->xdndHandleDrop(widget, event, passive_only);
} else if (event->xclient.message_type == ATOM(XdndFinished)) {
X11->xdndHandleFinished(widget, event, passive_only); <============
} else {
if (passive_only) return 0;
// All other are interactions
}
@qapplication_x11.cpp
@
case ClientMessage: // client message
return x11ClientMessage(widget,event,False); <============
@qguieventdispatcher_glib.cpp
@
// send through event filter
if (source->q->filterEvent(&event))
continue;if (qApp->x11ProcessEvent(&event) == 1) <============ return true; if (event.xany.serial >= marker) goto out; } while (XEventsQueued(X11->display, QueuedAfterFlush));out:
@....
-
Since I have only been debugging with the Qt source today, I have seen it happens in more than one location in the function above.
It seems to me to be the data pointer becomes invalid, if I could find out what this is then I would be able to trace it back, however, it is obtained from
QThreadData * volatile * pdata = &receiver->d_func()->threadData;
and d_func() doesn't seem accessible from the source I have.
@
} QThreadData * volatile * pdata = &receiver->d_func()->threadData; QThreadData *data = *pdata; if (!data) { // posting during destruction? just delete the event to prevent a leak delete event; return; } // lock the post event mutex data->postEventList.mutex.lock(); // if object has moved to another thread, follow it while (data != *pdata) { data->postEventList.mutex.unlock(); <============= CRASH CAN ALSO HAPPEN HERE data = *pdata; if (!data) { // posting during destruction? just delete the event to prevent a leak delete event; return;@
-
First thing that comes to my mind:
Do you use the delete operator or deleteLater function from QObject ? -
Sorry but, yes to what ?
-
I would rather avoid using delete on widgets, unless you're really sure about the state of that widget (parenting etc...)
And since the drag object is a child of your current widget, it should also be automatically deleted.
And last thing, i would set _widget to 0 in the destructor of your custom QMimeData (or use something like a QPointer)
-
I need to delete the widget, if it is not dropped as it is created for being dragged into the container, if the drag fails it should be deleted, otherwise it will sit in memory until the application is closed.
The code that calls the deletion of the drag does not get called, it is only for if the creation of the widget fails, which does not happen.
I will set the widget to 0 in the destruction of the mime data, and see if this helps.
-
Why do you create it there then ? Wouldn't it be safer to serialize your widget properties (i.e. in xml) and then use that to create the widget in the drop function ? So if no drop occurs, no need to handle that widget.
-
Widgets can also be moved, from one place to another. These widgets are connected up to the backend via a (thread safe) shared control object and all setting show on the GUI match up. Due to this, it is far easier to create the widget and then destroy it if required.
I really don't think the issue is with deleting the widgets. As looking into the code, the object getting deleted is the QXdndDropTransaction object. This is handled by Qt itself.
