Bug 138229 - Crash when starting any editor with certain formatted clipboard content
Summary: Crash when starting any editor with certain formatted clipboard content
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha1+
Hardware: All Windows (All)
: highest critical
Assignee: Mike Kaganski
URL:
Whiteboard: target:7.1.0
Keywords: bibisected, regression
Depends on:
Blocks:
 
Reported: 2020-11-15 08:29 UTC by Aron Budea
Modified: 2020-11-22 01:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Backtrace (2.77 KB, text/plain)
2020-11-15 08:29 UTC, Aron Budea
Details
Recovery dialog screenshot (9.72 KB, image/png)
2020-11-15 08:39 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2020-11-15 08:29:43 UTC
Created attachment 167310 [details]
Backtrace

- Open WordPad, type a couple of characters (eg. abcd), select and copy them to clipboard using Ctrl+C.
- Open one of the apps (Writer / Calc / Impress).

=> Crash.

No crash in the start center. No crash if the clipboard is empty, or if it contains unformatted content, or similar content copied from Writer. What's LO doing with the clipboard at that point, anyway?

The error is read access violation, attaching backtrace.

Occurs since 11-12 tb77 daily builds, the 11-11 build is still fine.

This yields the following small range:
https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=122d1e391625ca21345c67c90720e971819aa4a6..693553210828538680408832157faad9654758c8

Could it be a fallout from the "make tools::Long 64-bit on Windows platform" change? (completely uneducated guess)
Comment 1 Aron Budea 2020-11-15 08:30:57 UTC
Should be bibisected further once the repo is updated.
Comment 2 Aron Budea 2020-11-15 08:39:30 UTC
Created attachment 167311 [details]
Recovery dialog screenshot

What is especially annoying is that after the crash, you get stuck with an empty recovery dialog, it can't be closed, and has to be killed from the task manager.
Comment 3 Mike Kaganski 2020-11-15 10:18:57 UTC
The problem is in SvPasteObjectHelper::GetEmbeddedName, which casts the byte array returned from anySequence.getArray( ) to OleObjectDescriptor*.

The latter struct is defined in svtools/source/dialogs/insdlg.cxx, and is documented there to "conform to the Microsoft OBJECTDESCRIPTOR" [1]. You may note the MS struct using SIZEL and POINTL, and OleObjectDescriptor using Size and Point - both affected by tools::Long ...

[1] https://docs.microsoft.com/en-us/windows/win32/api/oleidl/ns-oleidl-objectdescriptor
Comment 4 Mike Kaganski 2020-11-16 07:54:35 UTC
https://gerrit.libreoffice.org/c/core/+/105910
Comment 5 Commit Notification 2020-11-16 09:00:33 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/600dfc9d39883b4150b7d773a5a2de483a4c94b6

tdf#138229: make OleObjectDescriptor match OBJECTDESCRIPTOR on _WIN64

It will be available in 7.1.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 6 Aron Budea 2020-11-22 01:13:36 UTC
The crash is verified gone, thanks for fixing, Mike!
LO 7.1.0.0.alpha1+ (x64) (312a33b7636334f6ce3b6d1702bc5d3e45215601) / Windows.