Bug 159683 - Crash on closing LibreOffice with certain content on the clipboard
Summary: Crash on closing LibreOffice with certain content on the clipboard
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.6.0.0 alpha0+
Hardware: All All
: medium critical
Assignee: Miklos Vajna
URL:
Whiteboard: target:24.8.0 target:24.2.4
Keywords: bibisected, haveBacktrace, regression
Depends on:
Blocks: Clipboard Crash Exit
  Show dependency tree / graph
 
Reported: 2024-02-11 18:25 UTC by Telesto
Modified: 2024-05-08 08:58 UTC (History)
6 users (show)

See Also:
Crash report or crash signature: ["SwHTMLWriter::GetCSS1Selector(SwFormat const *,rtl::OString &,rtl::OUString &,unsigned short &,rtl::OUString *)"]

Attachments
Sample (114.99 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2024-02-11 18:25 UTC, Telesto 		Details
dmp file (822.46 KB, application/vnd.tcpdump.pcap)
2024-02-11 20:19 UTC, BogdanB 		Details
bt (8.84 KB, text/plain)
2024-02-12 19:02 UTC, Julien Nabet 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2024-02-11 18:25:26 UTC 
Description:
Crash on closing LibreOffice with certain content on the clipboard

Steps to Reproduce:
1. Open the attached file (modified version of attachment 143131 [details] from bug 118392)
2. CTRL+A
3. CTRL+C
4. CTRL+Q -> Crash

Actual Results:
Crash

Expected Results:
No crash


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 4d381b54d1c598c181b4a21a8bf0db86eb4668d1
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded
Comment 1 Telesto 2024-02-11 18:25:37 UTC 
Created attachment 192508 [details]
Sample
Comment 2 BogdanB 2024-02-11 20:17:05 UTC 
No crash in
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: c170d1364be56d91fd16f255ffdc406b8e822732
CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 3 BogdanB 2024-02-11 20:19:18 UTC 
Created attachment 192509 [details]
dmp file

With debug version
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 2cedb1a19ad605df4e148589e9027512e4dd9265
CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

I get this at step: Ctrl+A

warn:desktop:483957:483957:desktop/source/app/crashreport.cxx:61: minidump generated: /home/bogdan/.config/libreofficedev/4/crash//49730bf4-5d95-4aed-9007b8ac-65d9beac.dmp
Comment 4 Telesto 2024-02-11 20:58:38 UTC 
FWIW: I forgot to mention bug 124647 which is using the same file for a different crash
Comment 5 Telesto 2024-02-11 21:00:45 UTC 
(In reply to BogdanB from comment #2)
> No crash in
> Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
> Build ID: c170d1364be56d91fd16f255ffdc406b8e822732
> CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3
> Locale: ro-RO (ro_RO.UTF-8); UI: en-US
> Calc: threaded

I guess it's Windows only issue; clipboard handling is OS-specific.

--
Comment 3 is likely something different or related to bug 124647
Comment 6 m_a_riosv 2024-02-12 02:05:11 UTC 
Reproducible
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 17fc445938dedb05125a6d6a5b4ce7f34ea95f59
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Enable skia doesn't solve the issue.

Also with Ver 3.3
Aoo directly crash after open the file.
Comment 7 Julien Nabet 2024-02-12 19:02:38 UTC 
Created attachment 192529 [details]
bt

On pc Debian x86-64 with master sources updated today, I got an assertion.

I noticed that if I wait a bit more once the file is opened (I mean until there's no extra log in console), I don't get the assertion.
Comment 8 Stéphane Guillou (stragu) 2024-02-27 09:14:29 UTC 
No crash in:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d2fa44db6f8a1badece63856ee0f12db4cba9b28
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

However, crashed as described on Windows 11:

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 4; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

Crash report: https://crashreport.libreoffice.org/stats/crash_details/ddf410e0-0f9d-45a8-81a2-9e32f4f39844

As Telesto said, let's keep it Windows-specific.
Comment 9 Stéphane Guillou (stragu) 2024-02-28 12:11:23 UTC 
Also reproduced on 7.6.5.2 (win 11).
Comment 10 Matt K 2024-03-20 01:53:57 UTC 
(In reply to Stéphane Guillou (stragu) from comment #8)
> As Telesto said, let's keep it Windows-specific.

I was able to repro with:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 53c5d570cab036b23f4969b858a648c8f0c24f93
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-US (C.UTF-8); UI: en-US
Calc: threaded

So, not OS-specific.  Not sure how to solve it either.  Interesting lines of output:

warn:sw.core:2542771:2542771:sw/source/core/attr/format.cxx:217: ~SwFormat: format still has clients on death, but parent format is missing: Character style
warn:sw.core:2542771:2542771:sw/source/core/attr/calbck.cxx:155: lost a client of type: 18SwFormatCharFormat at 0x606000e6f258 still registered on type: 8SwModify at 0x613000207c40.
warn:sw.core:2542771:2542771:sw/source/core/attr/calbck.cxx:155: lost a client of type: 18SwFormatCharFormat at 0x606000e6f3d8 still registered on type: 8SwModify at 0x613000207c40.
warn:sw.core:2542771:2542771:sw/source/core/attr/calbck.cxx:155: lost a client of type: 18SwFormatCharFormat at 0x606000e92d18 still registered on type: 8SwModify at 0x613000207c40.
warn:sw.core:2542771:2542771:sw/source/core/attr/calbck.cxx:155: lost a client of type: 18SwFormatCharFormat at 0x606000e91f98 still registered on type: 8SwModify at 0x613000207c40.
Comment 11 Stéphane Guillou (stragu) 2024-03-20 07:09:04 UTC 
It seems we can only crash it on Linux with a debug build (comment 3, comment 7, I assume comment 10 too, Matt?).

That's the case on my end, only crashes with debug build:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a1a1d8edb9d4a62b747aa7069b3026e2ba75704d
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

---

On Windows 11, no crash in 7.5.0.3 -> regression.
Comment 12 Matt K 2024-03-20 23:20:33 UTC 
(In reply to Stéphane Guillou (stragu) from comment #11)
> It seems we can only crash it on Linux with a debug build (comment 3,
> comment 7, I assume comment 10 too, Matt?).

Yes, that's correct.
  
> On Windows 11, no crash in 7.5.0.3 -> regression.

I bibisected this using win64-7.6 repo and got the following result:

bad commit is c804c5354855188b5a37219cfe11dc079dc235f4

which is:

Author: Miklos Vajna <vmiklos@collabora.com>
Date:   Fri Mar 10 13:36:37 2023 +0100

    sw content control: fix lost properties on copy&paste

Adding Miklos to CC
Comment 13 Miklos Vajna 2024-03-27 07:15:10 UTC 
I think what happens here (based on Julien's backtrace) is that we have an original document with char styles and we create a clipboard document, but the SwFormat instances in the clipboard document refer to char styles in the original document, so it's important the full SwDoc is only deleted once the clipboard document is deleted.

Normally the SwView has a weak reference to these clipboard documents, so these transferable instances are disposed/invalidated by the time the original SwDoc gets deleted, but not in this case, because we have some kind of leak.

It's not yet clear to me how the above commit changes anything in this mechanism, given that the failing assert is all around char styles and their usage, not around content control.
Comment 14 Commit Notification 2024-04-30 08:12:49 UTC 
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/06aeb9c61d50bba7edafe17f9d3513af26b0782f

tdf#159683 sw content controls, plain text: fix crash with the clipboard doc

It will be available in 24.8.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 15 Commit Notification 2024-05-08 08:58:25 UTC 
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/32616609c788aa1cf0837af0f387390a23de1766

tdf#159683 sw content controls, plain text: fix crash with the clipboard doc

It will be available in 24.2.4.

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.