Created attachment 147380 [details] ODS file where the bug can be reproduced Hello. On 2 files produced by converting an Excel xlsx file to ODS and then modifying it, LibreOffice often freezes at saving the document when a sheet has been added or deleted. This doesn't occur always, but often on that 2 files. The computer becomes extremely slow and, sometimes I have to reboot it, but often Gnome proposes to force quit. For at least one of these 2 xlsx files (I don't remember well for one of them), at opening it the 1st time, I got the following message "Impossible to load all the data: exceeding the maximum number of columns per sheet." (I'm translating the message from French, so the original English message may be slightly different.) The problems remains in LibreOffice save mode. Here enclosed is such a file. Steps to reproduce : Open it with LibreOffice. Right click on the "Liste" sheet tab, choose "Insert a sheet...", then "After the active sheet", name the new sheet "tours" and validate. Then click on the "save" button.
It looks like bug #117927 (in NEEDINFO state) except that in my case the computer nearly freezes. I forgot to say in the description that, although LibreOffice warned about too many columns, the used columns seemed correctly imported (no data were lost).
Using Ubuntu 18.04 (AMD 64 bit) and LO 6.1.2 and 6.1.3 Unable to confirm. Added sheet, save, all fine. Removed sheet, save, all fine. Repeated couple of times each, never a problem. Saved the ODS as xlsx. Opened, added sheet, saved as xlsx, no problem. Opened, removed sheet, saved as xlsx, no problem. Any chance you could offer one of the original xlsx files as an attachment?
Thank you for your quick testing. I work with Fedora 29 workstation. That xlsx file contains sensitive data, but I emptied a copy with LO and could reproduce the problem. Steps: + open the file with LO + save it in ODS format + close and reopen it (just to be sure the problem doesn't depend directly on the history, for instance) + delete the "mon ancienne liste" sheet (right-click on the tab, then "delete sheets") + click on the "save" button. So far no problem. + delete the "Tours" sheet (right-click on the tab, then "delete sheets") + click on the "save" button. Result: LO freezes.
Created attachment 147384 [details] An xlsx file from which the problem can be reproduced.
well, good news; bad news and they are both the same. It works without a problem for me here (tried multiple times, with different versions of LO without) All the binaries on my machine are downloaded from TDF, by chance are you using the binary from the distro and if so then it would be good to get someone with the same setup to give it a try.
(In reply to Fiable.biz from comment #3) > Thank you for your quick testing. I work with Fedora 29 workstation. That > xlsx file contains sensitive data, but I emptied a copy with LO and could > reproduce the problem. > Steps: > + open the file with LO > + save it in ODS format > + close and reopen it (just to be sure the problem doesn't depend directly > on the history, for instance) > + delete the "mon ancienne liste" sheet (right-click on the tab, then > "delete sheets") > + click on the "save" button. So far no problem. > + delete the "Tours" sheet (right-click on the tab, then "delete sheets") > + click on the "save" button. > > Result: LO freezes. don't repro in Версия: 6.1.3.2 ID сборки: 86daf60bf00efa86ad547e59e09d6bb77c699acb Потоков ЦП: 4; ОС:Linux 4.13; Отрисовка ИП: по умолчанию; VCL: gtk2; Локаль: ru-RU (ru_RU.UTF-8); Calc: group threaded Fiable.biz, please say us info from your dialogue Help->About
Created attachment 147518 [details] File which cannot be opened at all I recently received an XLS file I couldn't open at all with LO 6.1.2.1 in French on Fedora 29 workstation: LO freezes and, if not forced to quit quickly, Gnome freezes. I could open the file with LO 5.4.4.2 on Microsoft Windows 10. I emptied the file and save it with the same format. I was warned that the number of rows was too high for that format (which surprised me because the original file was already an XLS file) and that the extra rows would not be saved. I couldn't open the modified file with LO 6.1.2.1 in French on Fedora 29 workstation. Here it is.
Here is what the help says: Version: 6.1.2.1 Build ID: 6.1.2.1-3.fc29 Threads CPU : 4; OS : Linux 4.19; UI Render : par défaut; VCL: gtk3; Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded If I remember well (which is not sure), LibreOffice is only in English by default on Fedora workstation, even if French is chosen as one of the system languages, so I probably installed the French package later by hand by launching "dnf install libreoffice-langpack-fr" (dnf is the package management command of Fedora). I tried the above XLS file and one of the XLSX files on another computer with the same configuration (and where I had probably also installed the French package by hand), and unsurprisingly got the same results. If I launch now the package installation command, I get: # dnf install libreoffice-langpack-fr Dernière vérification de l’expiration des métadonnées effectuée il y a 19:21:34 le jeu. 13 déc. 2018 23:07:48 +08. Le paquet libreoffice-langpack-fr-1:6.1.2.1-3.fc29.x86_64 est déjà installé. Dépendances résolues. Rien à faire. Terminé ! which means the package is already installed.
I also didn't reproduce with LO 6.1 and 6.3+ in Mint 18.3 following Comment 3 with attachment 147384 [details]. Since 3 of us couldn't reproduce, I'm afraid I'll have to close the bug. If you manage to reproduce on some other system, feel free to notify. As for attachment 147518 [details] "File which cannot be opened at all" I also open it without issue. This all looks like a local issue on your workstation. You may start with profile reset https://wiki.documentfoundation.org/UserProfile and start in safe mode. It's also a good idea to test with https://libreoffice.soluzioniopen.com/daily/86/LibreOfficeDev-daily-x86_64.AppImage.
Thank you for the "insufficient data" tag: I provided all the data I was asked for. If you had read correctly, you would have read that I already tried in safe mode, that it seems the same bug has already been reported (bug #117927) , and that nobody tried with my configuration.
*** This bug has been marked as a duplicate of bug 121855 ***