My sister's accountant has switched to a newer version of MS Office and "enhanced" her stock XCell spreadsheet. The first observation is that LO warns of truncation due to the maximum number of columns being exceeded. Then when saving the document, LO produces a zero length tmp file and promptly crashes. I've tried this on two Macs and Ubuntu, haven't been able to try Windows. I can shed nothing more on this at the moment. I'll seek permission to share the document with the LO dev team. Is there any more info I can gather? If so, how? Sorry this a bit vague at the moment, hopefully I'll be able to add more soon.
Running libreoffice --backtrace crashes out of gdb when first importing the document
Created attachment 181363 [details] gdb crash log when importing the document Crash happens with OpenJDK-11 and Oracle JDK 12
Hi Owen, thanks for reporting. What version of LibreOffice are you running? Please copy and paste the version information from Help - About LibreOffice. Also, we need to have a test file to check if it is indeed a bug and pinpoint its cause. Maybe you can anonymize the data in the file (change their actual value but not the file structure). If that's not possible, try creating a smaller file where the error also happens.
Realised I was backtracing 7.3.0, however 7.3.5.2 crashes in gdb when starting up so unable to get a backtrace. Both 7.3.0 and 7.3.5.2 hang in the same way.
It would be best to get the original to you as I don't have any copies of Office after Office 2000! and we use Office 2007 at work, so any editing may remove the bug
[Automated Action] NeedInfo-To-Unconfirmed
Please attach here the problem file. Thanks
Dear Owen Savill, 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
I'm not clear what extra info is required. Please let me know and I'll attempt to suply it.
Sorry, I made the last comment in haste. I never received the spreadsheet less confidential data. I'll attempt to get it again.
(In reply to Owen Savill from comment #0) > My sister's accountant has switched to a newer version of MS Office and > "enhanced" her stock XCell spreadsheet. > > The first observation is that LO warns of truncation due to the maximum > number of columns being exceeded. I don't know if the crash is in any way related to this, but with a newer version (7.4 or later) you would have support for a bigger number of columns: http://llunak.blogspot.com/2022/03/enabling-calc-support-for-16384-columns.html Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Yes, that appears to have fixed it, but it took a full eight minutes to save it! XCell is spoofing the columns, in that the actual data is 23 columns and 65520 rows, but XCell seems to store a huge number of each. Would there be a way of either pruning out empty columns or rows? LO appears to be using one core and one process, is there a way to make saving multi threaded? LO is still largely unusable with files of this size, taking 8+ minutes to save a file is not great.
We still need the example file
(In reply to Owen Savill from comment #13) > LO is still largely unusable with files of this size, taking 8+ minutes to > save a file is not great. FWIW, it happened to me too, but I was never able to pinpoint what triggered such huge time and file size (from tens of KB to tens of MB). The next time I saved it, the size was reduced again, and also the time it took to save it. Is the size of the file much bigger than expected? This is probably not the right way to investigate bugs systematically, but considering that there is no access to the original file... Perhaps it would be worth a test: changing something minimal (e.g. one number), and saving it again. Does the file size change? And the time to finish saving it? It is up to you to decide whether the test is worth anything; I'm just sharing one experience I had some time ago. Sometimes clearing the format and content of all cells beyond the last cell in real use helps. Again, I'm just a user sharing experiences (probably more appropriate for ask.libreoffice.org than to a bug report).
Dear Owen Savill, 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