Windows 7 SP1 with dual monitor. Opening an existing spreadsheet (saved under 3.3) - OK Make a change and save - OK (file size remains correct) Re-open that spreadsheet - all data lost, speed and result is like it did File/New, though the spreadsheet file stays as big as it was. This bug has similarities with bug 37855 (Linux, dual monitor, Calc crashes)
Please attach a sample spreadsheet document for which this happens.
RC2 is bit by bit identical with release version, so separate items in the version picker are useless. Changes have been discussed with Michael Meeks.
(In reply to comment #1) > Please attach a sample spreadsheet document for which this happens. I can't supply the spreadsheet because the two I tested contain confidential and I am no longer using 3.4, so cannot easily create other tests for you (3.4 is unusable on my system due to this bug). However, I don't think this will stop you re-creating this bug because it seems unlikely to be dependent on my files. See next. I can make some observations: 1) It is quite likely the bug is independent of the spreadsheet, because I encountered it on the first two of my spreadsheets that I edited after installing 3.4 2) In case it IS related to the spreadsheet I can tell you that both the spreadsheets had several worksheets. One is a large and complex spreadsheet (with about 30 worksheets some quite large), but the other is quite small (about 5 worksheets, each very simple: only very basic formula on each worksheet and only about 200 cells of data/formulae per worksheet). Mark
I've updated this to "blocker" as it makes the software release unusable for those affected, and "high" because a smallish, increasing, and significant number of people will encounter it (being dual monitor specific). Mark
this is not a blocker, please read our definitions for blocker at: http://wiki.documentfoundation.org/Release_Criteria
(In reply to comment #5) > this is not a blocker, please read our definitions for blocker at: > http://wiki.documentfoundation.org/Release_Criteria I had not read the definition of blocker but having done so I see that it DOES fulfill the conditions: 1) data loss 2) reproducable 3) regressive 4) no workaround By all means reset it again, but please explain why. Mark
problem must affect most users or there must not be a reasonable workaround; it is bad to block the release and all users because of a corner case when a reasonable workaround exists It is not a general problem as for example I'm able to use Libreoffice with two monitors, so this seems to be a single case and no general behavior this might be related to your graphic card driver not working correctly together with libreoffice but it is no blocker!
(In reply to comment #7) Thanks for explaining your reasons for not being blocker. So why not critical: "crashes, loss of data, severe memory leak" > It is not a general problem as for example I'm able to use Libreoffice with two > monitors, so this seems to be a single case and no general behavior Are you using Windows 7 64 bit? If not what? (As I recall, I didn't hit this on Windows XP 32 bit, so there may be some clues in this and the similar Linux bug (see ref in my original bug report above).
I'm using a 3-4 build with win 7x64 and master and 3-4 builds with linux and don't have any problems with it. I don't think that this is a general problem as we would have much more bug reports about this already. So I think that it might be the combination of our gui framework with your graphic driver.
I am having this happen with Libre 3.4.1 with two different cases. One where the file size is reverted to the original for the blank doc (16KiB) and several where the file size remains the same, but there is no content left. Tried bringing over the backup of the same doc, it did exactly the same thing. Has anybody found a workaround for this? Since the file (with or without a name change) is automatically rendered empty when we try to bring over the file again.
I also have this problem. I am not using two monitors (just my laptop), and am running the 32-bit Linux version (3.4.3). Like one of the cases Alyssa mentioned above, the file size remained as it did with the data in it, yet all the content disappears. It seems quite serious to me, especially because there is no error message when you save the file. I only discovered it after saving a spreadsheet then realizing a month or two later that all my data was destroyed!! I filed a separate bug before I saw this one, see: https://bugs.freedesktop.org/show_bug.cgi?id=41056
I have a slightly different situation here, but the result is the same: unable to recover the file. This happend to me twice during the last seven days. Actually it is a spreadsheet started back in 2007, and I used it since then with several versions of openoffice and now libreoffice (always under Suse/Opensuse, actual version: LibreOffice 3.4.2 OOO340m1 (Build:1206)). Libreoffice signaled me a reading error in content.xml at position 2,264557 in one file. Extracting content.xml and looking at it with firefox gave the following information: XML-Verarbeitungsfehler: Doppeltes Attribut Adresse: file:///home/evo/Dokumente/finanzen/libreoffice/bugzilla/content.xml Zeile Nr. 2, Spalte 264558: I was unable to see what happend at this position. joe, vi and kwrite were unable such long lines in an effective way. HW: AMD Athlon 64 X2, Nvidia GeForce 6150 LE SW: Linux 2.6.37.6-0.7-desktop x86_64, openSUSE 11.4 (x86_64), KDE: 4.6.00 (4.6.0) "release 6" It might be interesting that the first report mentioned also x86-64 (AMD64). The information contained in the spreadsheet is not intended to go public. Maybe somebody can instruct me about tools and how to find the informations at the position 2,264557.
Created attachment 53272 [details] part of content.xml, position 264433 to 264783
I was finally able to open content.xml and to copy the position of the file, where the fault should lie. See "part of content.xml, position 264433 to 264783".
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
This happened to me in 4.1.1.2 and I lost a large data file. Not going to mess with this anymore. Can't stand programs that corrupt or lose data. <:( LKA