Committed r146713: <http://trac.webkit.org/changeset/146713>

Is there any way to get symbolized backtraces from the bots?

The best one I can give you is: http://build.webkit.sed.hu/results/x86-64%20Linux%20Qt%20Debug/r146711%20(28239)/results.html crash log for DumpRenderTree (pid 10543): STDOUT: <empty> STDERR: ASSERTION FAILED: m_readableData STDERR: /home/webkitbuildbot/slaves/debug64bit/buildslave/qt-linux-64-debug/build/Source/WebCore/platform/qt/ClipboardQt.cpp(190) : virtual WTF::ListHashSet<WTF::String> WebCore::ClipboardQt::types() const STDERR: 1 0x7f8a4bff549f /home/webkitbuildbot/slaves/debug64bit/buildslave/qt-linux-64-debug/build/WebKitBuild/Debug/lib/libQt5WebKit.so.5(+0x11f649f) [0x7f8a4bff549f] STDERR: 2 0x7f8a4b3a7b74 /home/webkitbuildbot/slaves/debug64bit/buildslave/qt-linux-64-debug/build/WebKitBuild/Debug/lib/libQt5WebKit.so.5(+0x5a8b74) [0x7f8a4b3a7b74] STDERR: 3 0x7f8a4c415c73 /home/webkitbuildbot/slaves/debug64bit/buildslave/qt-linux-64-debug/build/WebKitBuild/Debug/lib/libQt5WebKit.so.5(+0x1616c73) [0x7f8a4c415c73] STDERR: 4 0x7f8a4b384651 /home/webkitbuildbot/slaves/debug64bit/buildslave/qt-linux-64-debug/build/WebKitBuild/Debug/lib/libQt5WebKit.so.5(+0x585651) [0x7f8a4b384651] STDERR: 5 0x7f8a4b3f215d /home/webkitbuildbot/slaves/debug64bit/buildslave/qt-linux-64-debug/build/WebKitBuild/Debug/lib/libQt5WebKit.so.5(+0x5f315d) [0x7f8a4b3f215d] STDERR: 6 0x7f8a4cb49f34 /home/webkitbuildbot/slaves/debug64bit/buildslave/qt-linux-64-debug/build/WebKitBuild/Debug/lib/libQt5WebKit.so.5(+0x1d4af34) [0x7f8a4cb49f34] STDERR: 7 0x7f8a4cb53791 /home/webkitbuildbot/slaves/debug64bit/buildslave/qt-linux-64-debug/build/WebKitBuild/Debug/lib/libQt5WebKit.so.5(+0x1d54791) [0x7f8a4cb53791]

Maybe Ossy can help you.

Oh I see... thanks for the symbolized trace! It's because the Qt clipboard expects to have a m_readableData always when it attempts to read, but this is not set when a mutable ClipboardQt is created (in dragstart/copy/cut events). The proper fix here is to just combine m_readableData/m_writableData into m_mimeData and just use that for all operations. Until then, a crash is the expected result due to the null dereference (and assert).

(In reply to comment #5) > The proper fix here is to just combine m_readableData/m_writableData into m_mimeData and just use that for all operations. Until then, a crash is the expected result due to the null dereference (and assert). That doesn't sound right. A program crash should NEVER be an expected behavior. Did this crash exist your patch? If not, this is a regression.

That doesn't sound right. A program crash should NEVER be an expected behavior. Did this crash exist *before* your patch? If not, this is a regression.

Hmm, you're right. As a temporary workaround until someone more familiar can implement the work, I will change the ASSERTs to early returns.

(In reply to comment #8) > Hmm, you're right. As a temporary workaround until someone more familiar can implement the work, I will change the ASSERTs to early returns. Great. Thanks. Meanwhile, we need to find a Qt port contributor who can address issue...

Created attachment 194724 [details] Patch

Comment on attachment 194724 [details] Patch Thanks!

Committed r146723: <http://trac.webkit.org/changeset/146723>

I will take a look.

Created attachment 194820 [details] Patch

Created attachment 195102 [details] Patch

Comment on attachment 195102 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=195102&action=review > Source/WebCore/platform/qt/ClipboardQt.cpp:146 > if (!canReadData()) > return String(); This can be merged into the below if (!data). > Source/WebCore/platform/qt/ClipboardQt.cpp:187 > if (!canReadTypes()) > return ListHashSet<String>(); ditto > Source/WebCore/platform/qt/ClipboardQt.cpp:203 > + if (!canReadData()) > + return FileList::create(); ditto > Source/WebCore/platform/qt/ClipboardQt.cpp:347 > +const QMimeData* ClipboardQt::readClipboardData() const Nit: I'm not sure about the name, it sounds like it's actively fetching data from the clipboard.

Created attachment 195112 [details] Patch

Committed r146910: <http://trac.webkit.org/changeset/146910>

editing/pasteboard/can-read-in-dragstart-event.html test timeout on wk1.

(In reply to comment #19) > editing/pasteboard/can-read-in-dragstart-event.html test timeout on wk1. Yeah, it is skipped and moved to "missing drag-and-drop support" section in http://trac.webkit.org/changeset/146910/trunk/LayoutTests/platform/qt/TestExpectations