Bug 162004 - [CRASH] Enabling the Notes Pane and closing the document will crash LibreOffice
Summary: [CRASH] Enabling the Notes Pane and closing the document will crash LibreOffice
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
25.2.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:25.2.0
Keywords: bibisected, regression
Depends on:
Blocks: Crash
  Show dependency treegraph
 
Reported: 2024-07-11 17:16 UTC by Rafael Lima
Modified: 2024-08-22 07:25 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Backtrace (8.57 KB, text/plain)
2024-07-11 17:25 UTC, Rafael Lima
Details
bt (6.08 KB, text/plain)
2024-07-25 10:46 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Lima 2024-07-11 17:16:43 UTC
In current master, on a debug build (built with --enable-debug), the following series of steps will crash LO.

1) Open Impress on a clean profile
2) Enable the Notes Pane (View - Notes Pane)
3) Click the area where notes should be written (but do not write anything)
4) Close the document
5) Crash

If you write anything, no crash will happen.

Tested with master from today. The bug happens both in kf5 and gtk3

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 05d304ce155bb8a967c55f7b037dfbfe3ad6a416
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: CL threaded
Comment 1 Rafael Lima 2024-07-11 17:25:07 UTC
Created attachment 195243 [details]
Backtrace

Here's the backtrace of the crash.
Comment 2 m_a_riosv 2024-07-11 19:40:29 UTC
No crash signature. Reproducible.
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 37217909f2e7c042eab9a8b5eb1ab0a88cdda513
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded


Not reproducible with
Version: 24.8.0.1 (X86_64) / LibreOffice Community
Build ID: 6fd6cae02baed1e82d14ed2da1f2458092354dab
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 3 Julien Nabet 2024-07-12 08:10:46 UTC
Just for the record, on pc Debian x86-64 with master source updated today + gtk3 or kf5 rendering, I don't reproduce this.
Comment 4 Rafael Lima 2024-07-12 12:56:02 UTC
(In reply to Julien Nabet from comment #3)
> Just for the record, on pc Debian x86-64 with master source updated today +
> gtk3 or kf5 rendering, I don't reproduce this.

Are you on a debug build?

I have just pulled the code and still get the crash.

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 410da49f0116dc76f9b8438af8109501e8a9dcd4
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: CL threaded
Comment 5 BogdanB 2024-07-20 04:08:08 UTC
 a4434ee87cf2b77d89ab50863ddee1aeed808206 is the first bad commit
commit a4434ee87cf2b77d89ab50863ddee1aeed808206
Author: Jenkins Build User <tdf@maggie.tdf>
Date:   Fri Jun 28 23:16:52 2024 +0200

    source d900a952eb2267717797c7e91326a0ce3f222063
    
    source d900a952eb2267717797c7e91326a0ce3f222063

 instdir/program/libbasctllo.so          | Bin 2513632 -> 2513632 bytes
 instdir/program/libchartcontrollerlo.so | Bin 4680712 -> 4680712 bytes
 instdir/program/libchartcorelo.so       | Bin 5259456 -> 5259456 bytes
 instdir/program/libcuilo.so             | Bin 6416624 -> 6416624 bytes
 instdir/program/libmsfilterlo.so        | Bin 1175808 -> 1175808 bytes
 instdir/program/libmswordlo.so          | Bin 3540632 -> 3540632 bytes
 instdir/program/libooxlo.so             | Bin 7696328 -> 7696328 bytes
 instdir/program/librptlo.so             | Bin 2702216 -> 2702216 bytes
 instdir/program/librptuilo.so           | Bin 2110864 -> 2110864 bytes
 instdir/program/libscfiltlo.so          | Bin 7148744 -> 7148744 bytes
 instdir/program/libsclo.so              | Bin 26373752 -> 26373752 bytes
 instdir/program/libscuilo.so            | Bin 1369928 -> 1369928 bytes
 instdir/program/libsdlo.so              | Bin 12404880 -> 12404880 bytes
 instdir/program/libsduilo.so            | Bin 2593944 -> 2593944 bytes
 instdir/program/libsvgfilterlo.so       | Bin 1072896 -> 1072896 bytes
 instdir/program/libsvxcorelo.so         | Bin 14239416 -> 14241424 bytes
 instdir/program/libsvxlo.so             | Bin 6579488 -> 6579488 bytes
 instdir/program/libswlo.so              | Bin 27549184 -> 27549184 bytes
 instdir/program/libswuilo.so            | Bin 3954976 -> 3954976 bytes
 instdir/program/setuprc                 |   2 +-
 instdir/program/versionrc               |   2 +-
 21 files changed, 2 insertions(+), 2 deletions(-)

Noel, I added you here, please can you take a look?

https://cgit.freedesktop.org/libreoffice/core/commit/?id=d900a952eb2267717797c7e91326a0ce3f222063


author	Noel Grandin <noel.grandin@collabora.co.uk>	2024-06-26 11:57:42 +0200
committer	Noel Grandin <noel.grandin@collabora.co.uk>	2024-06-28 14:55:54 +0200
commit d900a952eb2267717797c7e91326a0ce3f222063 (patch)
tree 7ab351a54a49d27d358612648f8c6a5f83108a5c
parent c519de229627f3c6bb7736c810405b441c07f369 (diff)
reduce number of SvxUnoShape listeners on SdrModel
when we have a lot of shapes, the number of listeners attached to
SdrModel becomes a serious bottleneck because of the number of
broadcast/notify function calls.

So
(1) make SvxUnoShape listen to the SdrObject
which achieves the same end, and reduces the bottleneck on the SdrModel.
(2) repurpose the maAllIncarnatedObjects set, which tracks all
objects linked to the SdrModel, so we can shut down the associated
UNO shapes during ClearModel. There is no other good way of doing
this, and if we don't do it, we get various use-after-free
issues during shutdown.

This takes the load time of a large DOCX with lots of shapes,
from 35s to 17s on my machine.
Comment 6 Noel Grandin 2024-07-23 06:26:35 UTC
On current master, I cannot get this to crash on Windows, Linux(kf5) or macOS.

Has this been silently fixed by something else, or is it just my setup?
Comment 7 m_a_riosv 2024-07-23 09:37:22 UTC
Reproducible
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a7de9cc5e89cd0d0c2f6363b2c0cc265c528b121
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 8 Noel Grandin 2024-07-24 15:17:22 UTC
Could anyone see if this helps:
   https://gerrit.libreoffice.org/c/core/+/170970
?
Comment 9 Julien Nabet 2024-07-25 10:46:31 UTC
Created attachment 195495 [details]
bt

On pc Debian x86-64 with master sources updated today, I could reproduce this.

I'm gonna test the patch.
Comment 10 Julien Nabet 2024-07-25 10:52:38 UTC
(In reply to Julien Nabet from comment #9)
> Created attachment 195495 [details]
> bt
> 
> On pc Debian x86-64 with master sources updated today, I could reproduce
> this.
> 
Forgot to tell I had this on console:
/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/debug/vector:442:
In function:
    reference std::vector<SfxListener *>::operator[](size_type) [_Tp = 
    SfxListener *, _Allocator = std::allocator<SfxListener *>]

Error: attempt to subscript container with out-of-bounds index 1, but 
container only holds 1 elements.

Objects involved in the operation:
    sequence "this" @ 0x55ae30b29510 {
      type = std::debug::vector<SfxListener*, std::allocator<SfxListener*> >;
    }
Unspecified Application Error


Fatal exception: Signal 6


> I'm gonna test the patch.

Patch works for me.
Comment 11 Commit Notification 2024-08-22 07:22:44 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/53b834fc44abe04bbfd3cdfc844149e233acc645

tdf#162004 crash after notes pane loses focus in impress

It will be available in 25.2.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.