Created attachment 198657 [details] Copy of the "USDA Foods Database - January 2025" that caused the Calc to crash. I did not edit the document. I simply opened the file and browsed the various included sheets. File Source: https://www.fns.usda.gov/usda-fis/usda-foods-database Links to relevant crash reports: https://crashreport.libreoffice.org/stats/crash_details/d5cfd11d-f4df-45bb-8f7b-cb3655bb9861 and: https://crashreport.libreoffice.org/stats/crash_details/0e55837e-fa83-455f-acad-d00e7075dce1 ========================================= This bug was filed from the crash reporting server and is br-0e55837e-fa83-455f-acad-d00e7075dce1. =========================================
Just for the record, on pc Debian x86-64 with master sources updated today or with LO Debian package 24.8.2.4, I don't have a crash but it's quite long to open then it hangs.
Hello Kenney Phillis Jr, Thank you for reporting the bug. I can confirm that the bug is present in master. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a8ec21adf255b70bb6eeb0a1717190df303d8b26 CPU threads: 12; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_FI); UI: en-US Calc/Writer: threaded
(In reply to Julien Nabet from comment #1) > Just for the record, on pc Debian x86-64 with master sources updated today > or with LO Debian package 24.8.2.4, I don't have a crash but it's quite long > to open then it hangs. Long load time and sluggish behaviour/hanging is already seen on Linux with versions 7.0, 5.2.
Not reproduced in Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 6f227b0dd912d4c70a01eb3872fff15d52de543a CPU threads: 16; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: threaded
At least in my case, I can reproduce the performance issue on Windows, but it doesn't crash at all. I tried to bisect the performance, unfortunately the issue is reproduced in the oldest bibisect-win64-25.2 and not in the latest bibisect-win64-24.8, sigh
Noting that (a) The freezes are somewhat random. Sometimes the document will in seconds, and then freeze when I resize. (b) The stacktraces indicate that there are two different freezes at work. On Windows, I **think** we are having some kind resize loop, where something keeps triggering a redraw/resize event, and we just never stop attempting to draw the screen. On Linux, we have the tradiontal performance problem in vcl/unx/gtk3/a11y/atklistener.cxx, where the ATK code wants to iterate the entire list of children of complex shapes and attach listeners to them. When we have very complex shapes, that can take a very very long time.
Indeed, the document opens fine with GEN environment Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7da1497aa462e2b719aa9b308a749caf7b9a19b1 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: x11 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded No crash reproduced though. @Kenney, Could you please explain how to reproduce the crash?
(In reply to Xisco Faulí from comment #7) > Indeed, the document opens fine with GEN environment > > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 7da1497aa462e2b719aa9b308a749caf7b9a19b1 > CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: x11 > Locale: es-ES (es_ES.UTF-8); UI: en-US > Calc: threaded > > No crash reproduced though. > @Kenney, Could you please explain how to reproduce the crash? The issue is that on my local system I have a 100% crash rate on the current version of the document with the following steps being done: From Explorer: Double click the document and open. The program crashes. From Libreoffice main selection page: Open document from selection. The document crashes. Open From Libreoffice Calc: Also crashes. System Build Information: Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Note: I am running windows 11 Pro (version 24h2) with all patches applied.
(In reply to Noel Grandin from comment #6) > On Linux, we have the tradiontal performance problem in > vcl/unx/gtk3/a11y/atklistener.cxx, where the ATK code wants to iterate the > entire list of children of complex shapes and attach listeners to them. > When we have very complex shapes, that can take a very very long time. Summary of related discussion on IRC last week: Attaching listeners is needed due to the way that LO's a11y event mechanism currently works. It may be worth reconsidering this. I would see first deduplicating XAccessibleEventBroadcaster (and possibly XAccessibleEventListener) implementations as an important step in that direction (to be able to change things in one place rather than many). The latter is something I have started working on, but which will likely take some time still. If considered critical, a workaround could be to (at least temporarily) introduce an env variable that when set, disables a11y (events) to some extent for those cases where a11y support isn't actually needed. With that said, a11y doesn't seem to be the only reason for slowness on Linux, as I can reproduce slowness and unresponsiveness with the gen VCL plugin as well, which doesn't have any a11y bridge (takes ~03:20 min until I can start interacting with the doc, then switching to a different sheet triggers unresponsiveness again for quite a while, and at some point it even crashed.) So I'd suggest to consider the a11y slowness (while it should be looked into) as something separate from this ticket. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fbdfde26391730216bae230cd6f228a6ae6ee89c CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: x11 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded