We have a payroll spreadsheet that won't save after we make changes to it. It originated (years ago) in Quattro, was saved as an Excel spreadsheet(years ago) and now we would like to save it as an .ods file. We CAN save it as an .ods file, but only after cutting out the vast majority of the data. The file is less than 300k, so I don't think size is the issue. I'm including two sample files: An .ods file that I managed to save and and excel file that I saved after I made some changes and FAILED to save as an ods file. The platform is Windows7 64bit OS with 8GB of ram. However, we've experienced this same problem on XP in the past. To reproduce the problem, copy the contents of Template Hourly 2 into one of the employees sheets and try to save the file.
Created attachment 111786 [details] ODS file that won't save after copying the template page to a worksheet.
Created attachment 111788 [details] ODS as before but not password protected
Hello, I can reproduce with 4.3.5.2, win7. I can copy data from "Template Hourly 2" into new sheet and save it without problems, so I think this bug should be closed as wontfix. As you wrote "It originated (years ago) in Quattro, was saved as an Excel spreadsheet(years ago) and now we would like to save it as an .ods file." Are you able to copy data into new file if bug still occurs in new file?
I've been able to reproduce the error from scratch in a blank calc document. The issue seems to be related to the number of cells in spreadsheet that have comments. I haven't found a consistent number EXACTLY, but somewhere between 3200 and 3300 comments in a spreadsheet will cause the file to not save as ODS. This bug does not appear to be related to the number of characters of the comment field. I've reproduced it with large comments and small comments at about the same number of total comments in the sheet. To reproduce this bug: * Create a new calc document * Create a comment in cell A1 such as "test comment". * Copy this cell down through A3200 and save the file. * Copy cell A1 from A3201 through A3300 and save the file. You should get the error - "Error saving the document <MyDoc>:Write Error. The file could not be written."
(In reply to Jonathan Kreider from comment #4) > > To reproduce this bug: > * Create a new calc document > * Create a comment in cell A1 such as "test comment". > * Copy this cell down through A3200 and save the file. > * Copy cell A1 from A3201 through A3300 and save the file. > > You should get the error - "Error saving the document <MyDoc>:Write Error. > The file could not be written." I can confirm with LO 4.3.5, win7.
(In reply to raal from comment #5) > (In reply to Jonathan Kreider from comment #4) > > > > > To reproduce this bug: > > * Create a new calc document > > * Create a comment in cell A1 such as "test comment". > > * Copy this cell down through A3200 and save the file. > > * Copy cell A1 from A3201 through A3300 and save the file. > > > > You should get the error - "Error saving the document <MyDoc>:Write Error. > > The file could not be written." > > I can confirm with LO 4.3.5, win7. I've reconfirmed this bug with LO 4.4.0 win7
Confirmed the bug still exists in 5.0.0.2 Windows X64
Created attachment 125573 [details] Backtrace gdb when saving document with more than 3200 comments Here is the backtrace when LO crash when save file
Hey, I found some new informations on this bug. I test with LO 5.0.6 and use Visual Studio 2013. An exception is thrown on during the XML export, exactly on "content export" treatement in xmlwrap.cxx class. This append on a specific note, the 3274th, on the 1627th row and 0 col. The exception come from the class virdev.cxx, line 152, mpVirDev is valued with NULL. The method whose return NULL is WinSalInstance::CreateVirtualDevice in salvd.cxx The problem come from the hBmp variable, valued with NULL after the call of WinSalVirtualDevice::ImplCreateVirDevBitmap(pGraphics->getHDC(), nDX, nDY, nBitCount, &pDummy); I hope this will be help Best regards Alexis
Hi, I find a bypass for this issue. With Win7, modify the key register GDIProcessHandleQuota in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows. Set the value to 65536 (max value) and file can be save. The default value was 10000, so it mean that LO use more than 10000 GDI objects when saving a file with more than 3200 comments and crash. Best regards Alexis
Hello everyone, The problem is during saving, we create a GDI object for each comment, this is done by collectTextAutoStyles, wich call exportToText wich indirectly call CreateVirtualDevice. I'll put the complete backtrace in this bug. I don't think the GDI object is necessary for the export, but I can't see a way to not create the GDI object, or to free it before the next comment.
Created attachment 130635 [details] GDI trouble backtrace This is the backtrace of the GDI allocation that causes this bug
Created attachment 130637 [details] Backtrace of the problematic GDI creation
I've tested it with a build that contains fix for Bug 103927, and I can't reproduce this problem.
Someone please test and confirm this. If not, I'll assume it is fixed.
I confirm, you fixed this commit ! Do you plan to backport this commit to 5.2 and 5.3 ? If not I can ?
The backports are here: 5.3: https://gerrit.libreoffice.org/#/c/33640/ 5.2: https://gerrit.libreoffice.org/#/c/33641/