GDB Core dump file: https://mega.nz/file/d25knZQK#wZsN9YtmA1Bybk-dfzD6xK9XY8yl3iK_RXvx7ITdc9o (Had to use a file hosting service because it's still too large to attach here, even compressed) System Info: ------------ OS: Arch Linux x86-64-v3 (https://git.harting.dev/ALHP/ALHP.GO) Kernel: Linux 6.0.8-272-tkg-pds (https://github.com/frogging-family/linux-tkg) CPU: AMD Ryzen 7 3700X (16) @ 4.05GHz GPU: NVIDIA GeForce RTX 2080 Ti GPU Driver Version: 520.56.06 Additional Info: ------------ This bug is reproducible, even from the the vanilla Arch (x86-64) repo Given that this affects opening .xlsx files, I'd think that this is a pretty serious issue GDB Terminal Output: ``` neko-san@ARCH ~> doas gdb -c soffice.bin-core.891951 /usr/lib/libreoffice/program/soffice.bin doas (neko-san@ARCH) password: GNU gdb (GDB) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/libreoffice/program/soffice.bin... warning: Can't open file /memfd:xorg (deleted) during file-backed mapping note processing warning: Can't open file /memfd:/.nvidia_drv.XXXXXX (deleted) during file-backed mapping note processing [New LWP 891951] [New LWP 891952] [New LWP 891953] [New LWP 891955] [New LWP 891975] [New LWP 891976] [New LWP 892217] [New LWP 892236] [New LWP 892237] [New LWP 892238] [New LWP 892239] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". --Type <RET> for more, q to quit, c to continue without paging--c Core was generated by `/usr/lib/libreoffice/program/soffice.bin'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f87886b7aef in s_stub_computeObjectIdentifier () from /usr/lib/libreoffice/program/libgcc3_uno.so [Current thread is 1 (Thread 0x7f878dc37000 (LWP 891951))] (gdb) ```
How did you install LO 7.4.3? From distrib repo or otherwise? Could you give a try at https://wiki.documentfoundation.org/QA/FirstSteps ? Finally, could you create a brand new ods file with just "test" in it in cell A1 and save it as xlxs then try to open this xlsx just for the try? About backtrace, here's a way to retrieve it https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace without it takes dozens of MB.
Created attachment 183965 [details] StartCenter .desktop Example Files I had installed it from the repos, however I should elaborate a bit more on that: the debug symbols for LibreOffice itself aren't provided on Arch, so I had to use ASP (https://wiki.archlinux.org/title/Arch_Build_System#Retrieve_PKGBUILD_source_using_Git) to pull the Arch build process for LibreOffice and compile it from the source code to get the debug symbols myself. That aside, I've attempted what you said about the debug backtrace out of curiosity and noticed something very odd. When launched from a .desktop file, that targets a symbolic link to "/usr/lib/libreoffice/program/soffice" from "/usr/bin", the bug is easily reproducible but, when launched directly from a terminal, it doesn't for some reason that I can't identify. Additionally, modifying the .desktop file to point to "/usr/lib/libreoffice/program/soffice" directly, with and without the --backtrace argument, in the .desktop file also causes this to be reproducible; however, attempting to use the backtrace argument via the .desktop file is pointless because, as soon as the program crashes, the spawned terminal window keeping track of the process immediately exits. That said, the manual debug backtrace I provided (by attaching a gdb process via the terminal separately) is the only way that can reliably track what's happening.
> How did you install LO 7.4.3? From distrib repo or otherwise? > Could you give a try at https://wiki.documentfoundation.org/QA/FirstSteps ? > https://www.libreoffice.org/download/download-libreoffice/ Additionally, the method you mentioned to install LibreOffice on Linux only applies to Ubuntu and Fedora - not Arch Linux.
[Automated Action] NeedInfo-To-Unconfirmed
I don't know what to do with a core file but suppose other people may know. => uncc myself since I can't help here.
Do you mean this affects any xlsx file, even blank ones? I am on Arch and they work fine for me. Does this still happen with 7.5? By the way, Arch now supports debuginfod for downloading symbols on demand: https://wiki.archlinux.org/title/Debugging/Getting_traces#Debuginfod https://wiki.archlinux.org/title/Debuginfod
Dear Neko-san, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Neko-san, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp