The above test file can be generated by autofilling A1:ALL10000 then copying and pasting that block then parts of that block down to Row 31808.  The full table is then A1:ALL31808.  It is then only possible to paste 530 values more; in A31809:TJ31809.  Any more cells with values causes a damaged file when saved.  Because the block copy paste method was used, the maximum value anywhere in the spreadsheet is 10999.1

To test if the File Save procedure is producing General Input Output Errors for varying reasons; one might be the process of detecting continguous columns of data to compact the eventual file size.  This additional procedure generates a file that reproduces the Error yet this time by only autofilling (without copying pasting).   The result is a smaller table of numbers that can be saved before General Input/Output Errors occur.  Maximum value anywhere in this new spreadsheet becomes 32481.1 

1. New Spreadsheet. Click on cell A1 and enter value 1.1
2. Click on cell A1 and click the corner dragging down autofill to A1:A31478
3. Click the corner A31478 to autofill right until ZZ31478 (then release)
   This is because autofill has limits to what it can follow
4. Click on ZZ1.  Then Ctrl+Shift+v to select full ZZ column down to ZZ31478.
5. Click corner; drag autofill right again until ALL31478 (has value 32477.1)
6. File> Save As> "A1 to ALL31478 autofilled.ods".  
   This is the starting square table available before Errors
7. Click on A31478 then Ctrl+Shift+> to select that bottom row A31478:ALL31478
8. Click corner to autofill down to learn/test, using File>Save As each time.
9. Here, autofill further down to Row 31482 then File>Save is successful
10. Here, autofill further down to Row 31483 causes File>Save General Input Output Error

The first test file with copied and pasted blocks (using lower decimal values) works until row 31809
This new generated file with autofilled all columns (causing greater decimal values) works until row 31482

The result is reproducible (same cell limit 31808530) with this 

Version: 7.3.0.1 (x64) / LibreOffice Community
Build ID: 840fe2f57ae5ad80d62bfa6e25550cb10ddabd1d
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

Tested
LO 5.4.7.2         No Bug
LO 6.0.0.1         No Bug
LO 6.2.8.2         No Bug
LO 6.3.0.0 alpha1  No Bug; tested saving 100 million values

LO 6.3.0.0 beta1   Crashes when saving 20 million values in A1:ALL20000
LO 6.3.0.0 beta2   Crashes as above
LO 6.3.0.4         Crashes as above
LO 6.3.2.1         Crashes as above
LO 6.3.4.1         Crashes as above
LO 6.3.6.2         Crashes as above
LO 6.4.7.2         Crashes as above
LO 7.0.0.0 alpha1  Gen Input/Output Error Bug Step 22 saving 31808531 values
LO 7.0.0.1         Gen Input/Output Error as above
LO 7.2.2.2         Gen Input/Output Error as above
LO 7.3.0.1         Gen Input/Output Error as above
LO 25.2.4.3        Gen Input/Output Error as above

Last known version to work here (without Bug when saving a table of decimal numbers) is
Version: 6.3.0.0.alpha1 (x64)
Build ID: 547edd20e527fb02900f6174973770d26306e2e7
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

Generating a 50 or 100 million cell table can be saved with 6.3.0.0alpha1
However using a later version of Calc to open that file (using 7.3.0.1 here) it fails to open, showing message "Read Error.  Format error discovered in the file in sub-document content.xml at 2,-1837072437(row,col)."

Is that a clue?  A negative Column number?

I was able to reproduce the bug as reported using the steps in the initial comments (2025-06-25 13:26:54 UTC) using the following environment

Version:        25.2.4.3 (X86_64)
Build:          33e196637044ead23f5c3226c
Environment:    CPU Threads: 8 OS Windows 7 Service Pack 1 X86_64 (6.1 build 7601)
User Interface: UI render: Skia/Raster; VCL:win
Locale:         en-US (en_US);  UI: en-US
Misc:           Calc:threaded


I was also able to reproduce by adding a number into a blank cell of the 31808530 cells by Copy and Paste.ods and trying to save. The position of the new cell does not appear to matter as was able to replicate in one case by entering a "1" in cell A31810 and in another case by entering "1" in cell I31831.  I was also able to replicate if I enter "Text1" in cell A31810.

If I start with a new file and put Text1 in A1 and Autofill to the same points as  "31808530 cells by Copy and Paste.ods" and then add one more item of "Test1810 to cell A31810 the file saves OK. I then added 10 cells to the saved file and it still saves fine if the contents are all text.

It appears that the behavior is different depending on the cell contents data type but if the first 31808530 cells are decimal adding a number or text to another cell will cause the save to fail.  

Possibly related: 

I also noticed that the Error dialog is using the previous file name (seed file name) and not the proposed file name - new name with 31808531... ods

When I try to open the "corrupt" file the behavior depends on how the file is opened as follows:

A. If Calc is closed and I double click the "corrupt" file Calc will start to open and then display a dialog saying the file is corrupt with the option to Repair the file

If you press No the dialog closes and Calc sort of opens with a completely blank window with a title bar with no title, no status bar nothing at all in the window and a small Error  Dialog that says "General Error. General input/output error." - pressing the OK button on this Error dialog closes Calc. 

If you press yes to Repair the file appears to be repaired, macros are disabled and the file opens. If you try to save the repaired file an Error dialog appears saying "Error saving the document ..... General Error" Pressing Ok and deleting the one cell and trying to save the file results in the same Error message.

B. If you open Calc first and open the file by either selecting from the Recent Documents list or File>Open selecting the file a dialog will display saying the file is corrupt with the option to Repair the file:

If you press No (to repair) the Text Import dialog appears

If you press Yes (to repair) it appears to repair the file and once the repair is complete the file will display. 

In both cases if you remove the contents of one cell right after the repair and then save the file it appears to save correctly and the file can be reopened.   



I've attached my test files to aid reproducing

Created attachment 201855 [details]
Zip containing 2 calc files with 31808530 cells one text and one decimal

On further testing I was able to reproduce the "Error on Save" using cells that had text and number contents though at a different total number of cells than the decimal only cells. Further the number of cells depends on the actual text within the cells which may indicate the issue is at a certain memory threshold in the background.

For the attached file (36,722,019 cells text contents.ods) 36,722,019 cells will save OK. If you add contents to a new cell and try to save, an Error message will appears saying "General Error: General input/output error." This file was created using steps following the same pattern as the original decimal file - auto fill followed by copy and paste.

Positioning of the final cell does not appear to matter

Steps to Reproduce (based on the ones originally reported):
1.  New empty Spreadsheet; in cell A1 type Text1 Enter
2.  Click again on A1 cell, then it's corner. Autofill down to A10000
3.  Click on corner again. Autofill across to ALL10000
4.  Selection is A1:ALL10000. Right Click mouse that selection > Copy
5.  Click on empty cell A10001. Right Click, Paste
6.  Click on empty cell A20001. Right Click, Paste
7.  File> Save As> "30 million block text contents.ods"  (size should be 85.605 MB)
8. In the Input box type A1:ALL1000 which results in 1,000,000 cells being selected. Right click mouse that selection > copy
9. Click on empty cell A30001. Right click > Paste Result:31,000,000 cells 
10.Click on empty cell A31001. Right click > Paste Result:32,000,000 cells
11.Click on empty cell A32001. Right click > Paste Result:33,000,000 cells
12.Click on empty cell A33001. Right click > Paste Result:34,000,000 cells
13.Click on empty cell A34001. Right click > Paste Result:35,000,000 cells
14.Click on empty cell A35001. Right click > Paste Result:36,000,000 cells
15. In the Input box type A1:ALL500 which results in 500,000 cells being selected. Right click mouse that selection > copy
16.Click on empty cell A36001. Right click > Paste Result:36,500,000 cells
17. In the Input box type A1:ALL100 which results in 100,000 cells being selected. Right click mouse that selection > copy
16.Click on empty cell A36501. Right click > Paste Result:36,600,000 cells
17.Click on empty cell A36601. Right click > Paste Result:36,700,000 cells
18. In the Input box type A1:ALL10 which results in 10,000 cells being selected. Right click mouse that selection > copy
19.Click on empty cell A36701. Right click > Paste Result:36,710,000 cells
20.Click on empty cell A36711. Right click > Paste Result:36,720,000 cells
21. In the Input box type A1:ALL1 which results in 1,000 cells being selected. Right click mouse that selection > copy
22.Click on empty cell A36721. Right click > Paste Result:36,721,000 cells
23.Click on empty cell A36722. Right click > Paste Result:36,722,000 cells
24. In the Input box type A1:AS1 which results in 19 cells being selected. Right click mouse that selection > copy
25.Click on empty cell A36723. Right click > Paste Result:36,722,019 cells
Save file as 36,722,019 cells text contents.ods 
26. Copy cell A1 and paste in cell T36723 or cell A36724 and Save file with name "36,722, 020 text contents.ods  and should result in an Error message - note the file will be saved when you OK the Error message but will cause an error message if you close and reopen Calc and try to open that file. 


If the file is created slightly different the cell count where the Save Error appears is different. The following steps will create a File Save Error at 36,464,853 cells slightly less than above with very similar cell contents.

Steps to Reproduce 
1. New empty Spreadsheet; in cell A1 type Text1 Enter
2. Click again on A1 cell, then it's corner. Autofill across to ALL1
3. Click on corner again. Autofill down to A36464 (note I had to do this in steps)
4. In the Input box type A36464:AFT36464 which selects the first 852 cells in the last row
5. Click on the corner. Autofill down to A36465
6. File> Save As> "36,464,852_autofill_text&number_contents.ods" 
7. Select cell AFU36464. click on the corner. Autofill down to AFU36465.
8. File> Save As> "36,464,853_autofill_text&number_contents.ods" - the file save should result in an Error dialog showing a message saying:  
Error saving the document 36,464,852_autofill_text&number_contents: 
General Error. 
General input/output error.

Note that the name in the Error message is the old name and not the one just entered.

I have attached the file I created as a seed file along with the first file in a zip file.

Possibly related to the file size but for text and number files, though the number of filled cells is higher (than when using decimal cell values) the file size is less 104.565 MB for the first case above and 103.883 MB for the second case in Windows 7.

Also in Windows 7 the file size did not change when the last 9 cells were filled for the first case and for the last 52 cells for the second case so possibly it is on a memory required change as the memory fills up.

Wasn't sure if I should create a new bug as the file size and contents are different than original bug but the end result is the same so have added to the original bug. I have also added files that can be used as starting points (last good saves) in a zip file called Bug167295_textandnumber_seedfiles.zip

Created attachment 201965 [details]
Zip containing 2 seed files with text and number contents to create Error

USER WORKAROUND

Using the first step by step example of sheet of decimal numbers:
The limit found for *.ods is 1000 columns by 31808 Rows (less than 200MB).

For a file that is to store or examine or filter or display more, a workaround:
1.  Open the .ods spreadsheet file that works.
2.  Increase it's quantity of functions or data or both as usual.
3.  File> Save As> name. . . .use V change from ODF to Office Open XML.
4.  Confirm Use Office Open XML Spreadsheet Format
5.  The file will save as type name.xlsx (and can go far larger)

I've tested this as far as decimal numbers in an array 1000 columns by 90000 Rows;  i.e. a block of 90 million cells (Calc 25.2.4.3).  The file saves and opens without difficulty (465.3 MB) at more than twice the array of the *.ods version.

I've tested it further as far as 1000 columns by 100 thousand and 200 thousand Rows (two hundred million cells occupied).  The files save also (516 MB and 1GB respectively without Gen IO Error).  However, after closing and reopening those two largest files, Calc starts with a new warning (on opening) that it finds corruption with an offer to repair the very large xlsx.

Notes on the workaround:

A message appears that the source *.ods file may contain formatting or content that cannot be saved in the xlsx format.  There's work to do to check if this Workaround will be adequate.  

For example, in the case of medical research done here:

90 thousand rows of records suffice (so got lucky).

Charts elsewhere keep their plotting and colours but lose the Data Label choice; xlsx places alternative symbols and numbers instead of the text.  Both can be simplified or switched off and saved to avoid the nuisance.

However, while using the file it's also possible to provisionally place the Data Label range back into the Chart parameters (takes a minute), see the names, study etc.  That repair is lost at the next Save as xlsx yet is a very minor inconvenience;  once Labels are up in RAM the full large xlsx study file is precisely the same use as for it's smaller *.ods source file (including Charts).

I've learnt not much about what other content or format might get "lost".  Formulae here are quite varied; statistics, indirect addressing, Truth tables and those all work just fine.  I've not yet noticed a risk by switching to xlsx to get by (yet here all files will move back to ODF *.ods when this Bug is fixed).