Bug 129809 - LibreOffice Writer crash while moving one letter with hyperlink (gtk3/kf5)
Summary: LibreOffice Writer crash while moving one letter with hyperlink (gtk3/kf5)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.4.2 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.0.0 target:6.4.2 target:6.3.6
Keywords:
: 129926 130312 131079 (view as bug list)
Depends on:
Blocks: KDE GTK3 Hyperlink
  Show dependency treegraph
 
Reported: 2020-01-05 14:29 UTC by opensuse.lietuviu.kalba
Modified: 2020-03-03 06:58 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
crash backtrace (25.31 KB, text/plain)
2020-01-05 14:29 UTC, opensuse.lietuviu.kalba
Details
ODT for testing. Please try move character "5" with hyperlink. (8.21 KB, application/vnd.oasis.opendocument.text)
2020-01-05 18:56 UTC, opensuse.lietuviu.kalba
Details
screencast to show how to reproduce (gtk3) (2.13 MB, video/webm)
2020-02-07 07:32 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description opensuse.lietuviu.kalba 2020-01-05 14:29:56 UTC
Created attachment 156943 [details]
crash backtrace

I worked with ODT document in openSUSE Leap 15.1 Linux system with KDE Plasma 5.12.8 system (KF 5.55, Qt 5.9.7). 
I accidentally selected and moved hyperlink (pointing to local object in document) that contained single letter. Selecting of text automatically copies text into clipboard in my system.

Versija: 6.3.4.2
Darinio identifikatorius: 60da17e045e08f1793c57c00ba83cdfce946d0aa
Procesoriaus gijos: 4; OS:Linux 4.12; Sąsajos pateikimas: numatytasis; VCL: kde5; 
Lokalė: lt-LT (lt_LT.UTF-8); Sąsajos kalba: lt-LT
Calc: threaded
Comment 1 opensuse.lietuviu.kalba 2020-01-05 18:56:35 UTC
Created attachment 156949 [details]
ODT for testing. Please try move character "5" with hyperlink.

I can consistently reproduce this bug with this ODT
Comment 2 Michael Weghorn 2020-01-07 17:21:32 UTC
I can reproduce with current master that hovering over the link then left-clicking and dragging to the end of the line causes that crash.

Version: 6.5.0.0.alpha0+
Build ID: ecb5130e16898c0d2485e99564c57882b5ef25b0
CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded
Comment 3 Michael Weghorn 2020-01-23 12:38:40 UTC
*** Bug 129926 has been marked as a duplicate of this bug. ***
Comment 4 Julien Nabet 2020-01-31 10:54:50 UTC
*** Bug 130312 has been marked as a duplicate of this bug. ***
Comment 5 Michael Weghorn 2020-02-07 07:32:02 UTC
Created attachment 157718 [details]
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
Comment 6 Caolán McNamara 2020-02-07 09:41:39 UTC
I find it difficult to reproduce this but I wonder if https://gerrit.libreoffice.org/c/core/+/88168 solves it
Comment 7 Michael Weghorn 2020-02-07 11:03:15 UTC
(In reply to Caolán McNamara from comment #6)
> I find it difficult to reproduce this but I wonder if
> https://gerrit.libreoffice.org/c/core/+/88168 solves it

It does, thanks a lot!

(Doing D'n'D on the hyperlink multiple times no longer crashes with that patch. It still behaves oddly, but that's unrelated and happens e.g. just the same with gen).
Comment 8 Commit Notification 2020-02-07 11:47:55 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/dbcdc5cd98df5756a96559e467cad95c629343ca

tdf#129809 take a reference in case m_aContents is replaced

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2020-02-08 02:45:19 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/696c29c1db48d5504a0929b3b11eec649de27fd2

tdf#129809 take a reference in case m_aContents is replaced

It will be available in 6.4.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2020-02-08 02:45:26 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1d7b1a15059a77fde9afa14d0b9a508142bfc247

tdf#129809 qt5: take a reference in case m_aContents is replaced

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Commit Notification 2020-02-08 02:45:38 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/b6a0dd44e5862471ef7804951b01570700d2e33c

tdf#129809 take a reference in case m_aContents is replaced

It will be available in 6.3.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Stephan van den Akker 2020-02-09 21:14:08 UTC
Confirmed fixed in:

Version: 7.0.0.0.alpha0+
Build ID: dd0dda17c9984ce29b674f7ba903cd1d3fe73ab5
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded
Comment 13 Commit Notification 2020-02-10 07:13:53 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/c51cada3dc0496fb2bcaa0d1360a202ce0efae80

tdf#129809 qt5: take a reference in case m_aContents is replaced

It will be available in 6.4.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Commit Notification 2020-02-10 07:14:00 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/966a02f2152528bef2e3ea75e8ac1a955dc897cc

tdf#129809 qt5: take a reference in case m_aContents is replaced

It will be available in 6.3.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Ming Hua 2020-03-02 22:37:44 UTC
*** Bug 131079 has been marked as a duplicate of this bug. ***