[Libreoffice-bugs] [Bug 129809] LibreOffice Writer crash while moving one letter with hyperlink in KDE Plasma 5 environement

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=129809

--- Comment #5 from Michael Weghorn <m.weghorn at posteo.de> ---
Created attachment 157718
  --> https://bugs.documentfoundation.org/attachment.cgi?id=157718&action=edit
screencast to show how to reproduce (gtk3)

Turns out that the same happens with gtk3 on X11 (already with some version I
tried from the 5.2 bibisect repo) VCL plugin as well with a similar backtrace,
but not with gen or on Windows.
For both, kf5 and gtk3, it's sometimes required to move the hyperlink twice
until the issue happens, s. attached screencast.

>From a first analysis, the problem seems to be roughly:

* both Qt5TransferData and VclGtkClipboard have a member

    Reference<css::datatransfer::XTransferable>              m_aContents

* a request to handle X11 clipboard selection is received from somewhere and
processed. For the Qt 5 case, that is handled by the Qt5MimeData currently set
for the selection in the application/system clipboard, so
Qt5MimeData::retrieveData is called as follows (upper frames left out here):

> ...
>  10  Qt5MimeData::retrieveData                                               Qt5Transferable.cxx 303  0x7fffe3f89e30
>  11  QMimeDataPrivate::retrieveTypedData                                     qvariant.h          394  0x7fffe5111a2d
>  12  QMimeData::data                                                         qmimedata.cpp       562  0x7fffe51128ee
>  13  QInternalMimeData::renderDataHelper(QString const&, QMimeData const *)                           0x7fffe49d1ce3
>  14  ??                                                                                               0x7fffe1fa6ee8
>  15  ??                                                                                               0x7fffe1f98abb
>  16  ??                                                                                               0x7fffe1f991b3
>  17  QXcbConnection::handleXcbEvent(xcb_generic_event_t *)                                            0x7fffe1f9db51
>  18  QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>)                          0x7fffe1f9e8ca
>  19  ??                                                                                               0x7fffe1fc8cd3
>  20  g_main_context_dispatch                                                                          0x7fffea3fcf1d
>  ...

which uses it's 'm_aContents' member to retrieve the data:

> aValue = m_aContents->getTransferData(aFlavor);

and the critical part is this line in 'SwTransferable::GetData' which updates
selection:

> m_pWrtShell->SelectTextAttr( RES_TXTATR_INETFMT );

since that updates the selection in the system clipoard like

> QApplication::clipboard()->setMimeData(new Qt5MimeData(m_aContents), m_aClipboardMode);

with this backtrace:

>  1   Qt5Clipboard::setContents                                               Qt5Clipboard.cxx    108  0x7fffe3f1e946
>  2   TransferableHelper::CopyToSelection                                     transfer.cxx        974  0x7ffff08376b5
>  3   TransferableHelper::CopyToSelection                                     transfer.cxx        989  0x7ffff0837820
>  4   SwTransferable::CreateSelection                                         swdtflvr.cxx        4051 0x7fffb2b5345b
>  5   SwWrtShell::SttSelect                                                   select.cxx          400  0x7fffb2e843ee
>  6   SwWrtShell::SelectTextAttr                                              move.cxx            684  0x7fffb2e7d577
>  7   SwTransferable::GetData                                                 swdtflvr.cxx        534  0x7fffb2b4321d
>  8   TransferableHelper::getTransferData2                                    transfer.cxx        312  0x7ffff08346a4
>  9   TransferableHelper::getTransferData                                     transfer.cxx        287  0x7ffff0834483
>  10  Qt5MimeData::retrieveData                                               Qt5Transferable.cxx 303  0x7fffe3f89e30
>  11  QMimeDataPrivate::retrieveTypedData                                     qvariant.h          394  0x7fffe5111a2d
>  12  QMimeData::data                                                         qmimedata.cpp       562  0x7fffe51128ee
>  13  QInternalMimeData::renderDataHelper(QString const&, QMimeData const *)                           0x7fffe49d1ce3
>  14  ??                                                                                               0x7fffe1fa6ee8
>  15  ??                                                                                               0x7fffe1f98abb
>  16  ??                                                                                               0x7fffe1f991b3
>  17  QXcbConnection::handleXcbEvent(xcb_generic_event_t *)                                            0x7fffe1f9db51
>  18  QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>)                          0x7fffe1f9e8ca
>  19  ??                                                                                               0x7fffe1fc8cd3
>  20  g_main_context_dispatch                                                                          0x7fffea3fcf1d
>  ...

Since ownership of the QMimeData set in the clipboard belongs to the
application clipboard, the previous QMimeData is deleted, but that one is still
in use (s. frame 10 above), thus the following method calls in
SwTransferable::GetData (frame 7) cause a crash when when trying to access then
already-deleted objects.


Scenario, backtrace and valgrind output are slightly different, but very
similar for the gtk3 case.

It seems a bit unfortunate that the GetData method also changes selection, but
I don't have an immediate solution at hand, so if somebody else wants to take a
look, please feel free. :-)

Version: 7.0.0.0.alpha0+
Build ID: 017ae620604de06414dc3f780804c241b87e45c6
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200207/87bf316d/attachment-0001.htm>