Description: The website www.excel1040.com provides spreadsheets for computing taxes. This bug occurred using the "Federal Income Tax Forecast Spreadsheet (for 2025)", version 4-sep-2025/3:20pm, https://sites.google.com/view/incometaxspreadsheet/home/download#h.x71ssmusyks9. The xlsx spreadsheet was downloaded, converted to fods format using librecalc, converted to ods format using librecalc, and the run in librecalc. (Each conversion took about 30 minutes.) The first action taken was to do a SaveAs to a different file and the operation hung. Steps to Reproduce: 1.download the spreadsheet file 2.Convert to fods: libreoffice --convert-to fods FILE.xlsx 3.Convert to ods: libreoffice --convert-to ods FILE.fods 4.libreoffice FILE.ods 5. SaveAs FILE-2.ods Actual Results: Program hangs. See attached. Expected Results: Program saves spreadsheet into file and exits Reproducible: Always User Profile Reset: No Additional Info: Produce the expected results. Version: 24.2.7.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 4:24.2.7-0ubuntu0.24.04.4 Calc: threaded
Created attachment 203037 [details] libreoffice in its hung state Given the conversion from xlsx to fods to ods, there could be some incompatibilities in the converted file because of the differences in capabilities of the different formats. But no matter what is in the resulting .ods program, libreoffice should NEVER hang or crash in response. All programs should detet and issues with there input and respond to any issues with an appropriate error message and either continue executing or exit.
Opening the program and doing such conversions, no issue.
(In reply to m_a_riosv from comment #2) > Opening the program and doing such conversions, no issue. The problem was not with doing the conversions (it took a long time, 30 minutes, but they worked). The probem was restarting LO, opening the .ods file, and then trying to perform a SaveAs. That operating hung, executing on my Linux Mint environment. YMMV. System: Kernel: 6.8.0-84-generic arch: x86_64 bits: 64 compiler: gcc v: 13.3.0 Desktop: Cinnamon v: 6.4.8 tk: GTK v: 3.24.41 wm: Muffin dm: LightDM Distro: Linux Mint 22.1 Xia base: Ubuntu 24.04 noble Machine: Type: Desktop System: Dell product: XPS 8940 v: N/A serial: <superuser required> Chassis: type: 3 serial: <superuser required> Mobo: Dell model: 0427JK v: A00 serial: <superuser required> part-nu: 09C5 UEFI: Dell v: 2.10.0 date: 09/14/2022 CPU: Info: 8-core model: 11th Gen Intel Core i7-11700 bits: 64 type: MT MCP arch: Rocket Lake rev: 1 cache: L1: 640 KiB L2: 4 MiB L3: 16 MiB Speed (MHz): avg: 800 min/max: 800/4800:4900 cores: 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 8: 800 9: 800 10: 800 11: 800 12: 800 13: 800 14: 800 15: 800 16: 800 bogomips: 79872 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx Info: Memory: total: 16 GiB available: 15.27 GiB used: 3.41 GiB (22.3%) Processes: 434 Power: uptime: 5h 47m wakeups: 0 Init: systemd v: 255 target: graphical (5) default: graphical Compilers: gcc: 13.3.0 Client: Unknown python3.12 client inxi: 3.3.34
You can get the information to paste here on Menu/Help/About LibreOffice (There is an icon to copy) No issue here either Version: 25.8.2.1 (X86_64) Build ID: 345526217a4027cb1b9ab39bd7153c8c141a1d64 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Please test in safe mode, Menu/Help/Restart in Safe Mode
Some more information. 1. The problem with Saving the spreadsheet only happens with this latest version of the tx spreadsheet. This was not a problem with versions of the spreadsheet from previous years and it was not a problem with the 14-aug-2025 version of the 2025 spreadsheet. For all those previous versions of the spreadsheet I have tried, a Save operation took around 5 seconds on my system. 2. LO is not totally hanging. After doing the Save, I found LO eventually completed the command after 30+ minutes. While onversions between formats has taken that long, as indicate above, for other versions of the spreadsheet, a Save completed in a normal amount of time. With that new information, I do not know if this should be classified as a "bug" or not. At the least, it is odd. 3. I tested in safe mode, both by starting LO normally and then changing to safe mode and by calling LO with the --safe-mode argument. Both resulted in Saves taking 30+ minutes to complete.
I don't have Linux to test it, sorry.
I went on the linux Mint forum and asked if anybody could replicate the problem I was having. This is the latest reply. "Very odd. Sometimes LO saves a file in ~30 seconds, other times it takes nearly an hour. I can't figure out any reason why the differences. Anyway, I guess I can confirm your problem. On Mint 22.2 by the way."
'www.excel1040.com' (redirects to Google Sites) is Glenn Reeves' set of excellent, complex, multi-sheeted income-tax spreadsheets, and the problem described here is much like the one I encountered. In my case Calc hung (repeatedly) while saving to an .fods file. (Well, I didn't wait any 30 minutes, just killed LO after 10 minutes. Is that a legitimate "hang"?) In previous years saving took several minutes, but otherwise succeeded. This year I used LO 24.2.7.2 in an Ubuntu environment. The problem has gone away after upgrading to LO 25.8.2.2. It might be interesting to determine whether any intervening versions are susceptible to this, but the basic solution here is: upgrade. As to what was happening: googling "librecalc fails to save large fods file" (or similar) finds some interesting stuff. Like: "The most common reason for LibreOffice Calc failing to save large Flat OpenDocument Spreadsheet (.fods) files is memory exhaustion during the save process." "When you save a file in LibreOffice, it generates a massive temporary XML stream before compressing it. ..." (See https://ask.libreoffice.org/t/trouble-converting-large-excel-spreadsheet/90197/) The problem seems to involve two factors. First, Calc opens the file with the xlsx maximum number of rows (1,048,576) and columns (XFED -- 16,384?). Second, it appears that all those rows are given a height value, which amounts to about 80 chrs of xml code per row, and for each of some 60 sheets. Selecting that last million or so lines and setting the height to "Optimum" reportedly fixes the problem. (Well, for a single sheet.) (See https://superuser.com/questions/777279/openoffice-calc-reduce-file-size-when-saving-as-excel) So: perhaps this problem was just a passing glitch in version 24.2.7.2? But it seems to me that some attention ought to be given to why Calc opens with 1,048,576 rows. I suspect that Glenn's spreadsheets are the most complex that most of us encounter. Perhaps the LibreOffice folks would consider testing Calc on them.
P.S. I forget to mention that some cache sizes on the current version (25.8) are much larger than they were on 24.2.7.2. E.g.: - GlyphCacheSize: 20M -> 64M - ImageCacheSize: 64M -> 400M - GraphicMemoryLimit: 120M -> 300M So perhaps not so much a bug as inadequate configuration? Maybe someone seeing this problem will trying increasing the cache size before upgrading.
There have been many Calc-related performance improvements since 24.2. I don't observe any hang with the forecast from 20-Jan-2026. How does 25.8 perform for you? Arch Linux 64-bit Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 58da9d878db744f871072ef85f643a39e3c71a1f CPU threads: 8; OS: Linux 6.18; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 21 January 2026