Bug 168612 - Hangs when trying to save a complex ods file converted from an xlsx file
Summary: Hangs when trying to save a complex ods file converted from an xlsx file
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.2.7.2 release
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-09-29 14:25 UTC by social
Modified: 2025-10-01 21:20 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
libreoffice in its hung state (178.53 KB, image/png)
2025-09-29 14:30 UTC, social
Details

Note You need to log in before you can comment on or make changes to this bug.
Description social 2025-09-29 14:25:03 UTC
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
Comment 1 social 2025-09-29 14:30:29 UTC
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.
Comment 2 m_a_riosv 2025-09-29 16:38:43 UTC
Opening the program and doing such conversions, no issue.
Comment 3 social 2025-09-29 18:01:09 UTC
(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
Comment 4 m_a_riosv 2025-09-29 20:59:42 UTC
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
Comment 5 social 2025-09-30 17:27:29 UTC
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.
Comment 6 m_a_riosv 2025-09-30 22:22:55 UTC
I don't have Linux to test it, sorry.
Comment 7 social 2025-10-01 21:20:04 UTC
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."