I was editing a 150k word document (my novel), with change-tracking turned on, and simply typing in some new text. LO froze, as did all other open LO documents, and after a minute, they all died. I think I may have run out of VM. But when I restarted LO and it tried to recover the four open files, for three of them it complained that there was no backup recovery file in ~/.config/libreoffice/4/user/backup/ (strange, since LO would often do an auto-save, and of course you lose all mouse and keyboard input while that's happening)... Anyway, it said that it finished recovery (yellow tick marks against three files, instead of green) and the files would be saved in my home directory. I opted for that, but discovered that at least the last 20 mins of editing had been lost. Regardless of running out of memory and crashing rather than failing gracefully, the fact that the backup files and auto saves weren't there seems to me a major bug.
can you reproduce the issue again with a test file or was just a "one time only" bug?
It would certainly be difficult to retest - I would need to load up my system once again till it was badly thrashing and nearly out of VM, and then edit my novel for some time. Does LibreOffice carefully check for each new and every other memory allocation, to exit gracefully? If so, certainly another possibility is that the Linux kernel selected LO as the process to kill, when VM was exhausted - although that wouldn't explain why there were no backup files for the restore process when I restarted LO. In summary: it would be difficult to reproduce; but in a few weeks from now, I may have time to experiment and see what I can do.
(In reply to Luke Kendall from comment #0) > I think I may have run out of VM. > Well how much memory do you actually have and why is it so low that you need any VM ??? Normally LO doesn't/shouldn't use that much memory, even when loading a 150K file. Could it be a system error/bug/etc that trashes the memory and make LO behave badly ?
No, I simply was doing a lot of other things at the same time. I have 16GB RAM and 9.8GB of swap. I had something like 60 chromium tabs open, and 40 Firefox tabs, as well as Thunderbird (with 8000 messages in my inbox). So it was genuinely using a lot of memory. "top" showed that almost all the swap space was in use, shortly before. It was a perfectly legitimate out-of-memory situation. I wondered whether I did a lot of editing much faster than it seemed to me, so maybe LO was killed by the kernel before the next autosave (which I think I have set to every 10 mins). But that wouldn't explain why two of the other files I had had open for editing in LO for many days, also had no backup copies available, would it? Note that I couldn't see any differences in one of the other two files (using Compare document...), though the file sizes were slightly different: -rw-rw---- 1 luke kendall 103618 Jun 18 21:35 LostGirl-recovered.odt -rw-rw---- 1 luke kendall 103763 May 29 19:30 LostGirl.odt And I'm reasonably sure that the final document that had no backup, also had lost no work. I hope the above information is helpful.
Oh, in case it's of any help, here's a bit of "top" currently, with only 51 chromium tabs open and 21 Firefox tabs. $ top top - 13:15:19 up 63 days, 21:21, 11 users, load average: 1.19, 1.12, 0.96 Tasks: 308 total, 1 running, 306 sleeping, 0 stopped, 1 zombie %Cpu(s): 13.5 us, 1.4 sy, 0.0 ni, 85.0 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 16101592 total, 15467208 used, 634384 free, 2180660 buffers KiB Swap: 9820156 total, 985208 used, 8834948 free. 3144292 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5186 luke 20 0 1888484 615140 40528 S 35.9 3.8 415:59.11 firefox 1151 luke 20 0 2512392 442748 89928 S 1.3 2.7 122:07.57 chromium-b+ 1362 luke 20 0 1437096 349356 42460 S 1.0 2.2 54:26.27 chromium-b+ 1053 luke 20 0 1329524 321004 35060 S 0.0 2.0 19:36.52 thunderbird 19817 luke 20 0 2504804 263088 71032 S 0.0 1.6 37:42.18 soffice.bin
I don't know if it's the same problem, but LO has currently locked up, and is not responding. It has gone to 100% CPU, and has been like that for the last 15mins. Clicking on the Close icon on the LO window does nothing; and the window does not redraw if I move something in front of it. I'm not sure where it keeps its autosaved documents, but there's nothing there where I'd expect them to be: $ ls -lt ~/.openoffice* /home/luke/.openoffice: total 8 drwxr-xr-x 3 luke kendall 4096 Jul 27 2014 4 drwxr-xr-x 5 luke kendall 4096 Jan 16 2014 1.1.0 /home/luke/.openoffice.org: total 4 drwx------ 3 luke kendall 4096 Jul 27 2014 3 /home/luke/.openoffice.org2: total 4 drwxr-xr-x 17 luke kendall 4096 Jan 16 2014 user $ ls -lat /home/luke/.openoffice/4/user/backup/ total 8 drwxr-xr-x 17 luke kendall 4096 Jul 27 2014 .. drwxr-xr-x 2 luke kendall 4096 May 7 2014 . $ ls -lat /home/luke/.openoffice/4/user/backup/ total 8 drwxr-xr-x 17 luke kendall 4096 Jul 27 2014 .. drwxr-xr-x 2 luke kendall 4096 May 7 2014 . I couldn't attach to the LO process as myself, but as root I could, and FWIW, after many lines of loading and reading symbols for various shared objects: Loaded symbols for /opt/libreoffice4.4/program/../program/libPresenterScreenlo.so 0x00007f198111428c in SwIndex::ChgValue(SwIndex const&, int) () from /opt/libreoffice4.4/program/../program/libswlo.so (gdb) where #0 0x00007f198111428c in SwIndex::ChgValue(SwIndex const&, int) () from /opt/libreoffice4.4/program/../program/libswlo.so #1 0x00007f198113cd40 in SwPosition::SwPosition(SwNode const&) () from /opt/libreoffice4.4/program/../program/libswlo.so #2 0x00007f198113d962 in SwPaM::SwPaM(SwNode const&, int, SwNode const&, int, SwPaM*) () from /opt/libreoffice4.4/program/../program/libswlo.so #3 0x00007f198144c9b8 in ModelToViewHelper::ModelToViewHelper(SwTxtNode const&, unsigned short) () from /opt/libreoffice4.4/program/../program/libswlo.so #4 0x00007f198147056c in SwTxtNode::CountWords(SwDocStat&, int, int) const () from /opt/libreoffice4.4/program/../program/libswlo.so #5 0x00007f19811e225a in sw::DocumentStatisticsManager::IncrementalDocStatCalculate(long, bool) () from /opt/libreoffice4.4/program/../program/libswlo.so #6 0x00007f19811e37ed in sw::DocumentStatisticsManager::UpdateDocStat(bool, bool) () from /opt/libreoffice4.4/program/../program/libswlo.so #7 0x00007f19811e20cd in sw::DocumentStatisticsManager::GetUpdatedDocStat(bool, bool) () from /opt/libreoffice4.4/program/../program/libswlo.so #8 0x00007f19818585a2 in SwView::StateStatusLine(SfxItemSet&) () from /opt/libreoffice4.4/program/../program/libswlo.so #9 0x00007f19b2c7c38e in SfxDispatcher::_FillState(SfxSlotServer const&, SfxItemSet&, SfxSlot const*) () from /opt/libreoffice4.4/program/libsfxlo.so #10 0x00007f19b2c79ed8 in SfxBindings::Update_Impl(SfxStateCache*) () from /opt/libreoffice4.4/program/libsfxlo.so #11 0x00007f19b2c7a4e8 in SfxBindings::NextJob_Impl(Timer*) () from /opt/libreoffice4.4/program/libsfxlo.so #12 0x00007f19b0ebaf22 in Timer::ImplTimerCallbackProc() () from /opt/libreoffice4.4/program/libvcllo.so #13 0x00007f19a3578264 in sal_gtk_timeout_dispatch () from /opt/libreoffice4.4/program/libvclplug_gtklo.so #14 0x00007f19aaf5dce5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x00007f19aaf5e048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x00007f19aaf5e0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x00007f19a357a125 in GtkData::Yield(bool, bool) () from /opt/libreoffice4.4/program/libvclplug_gtklo.so #18 0x00007f19b0eb559e in Application::Yield() () from /opt/libreoffice4.4/program/libvcllo.so #19 0x00007f19b0eb5635 in Application::Execute() () from /opt/libreoffice4.4/program/libvcllo.so #20 0x00007f19b6286e9d in desktop::Desktop::Main() () from /opt/libreoffice4.4/program/libsofficeapp.so #21 0x00007f19b0eb9e21 in ImplSVMain() () from /opt/libreoffice4.4/program/libvcllo.so #22 0x00007f19b0eb9e42 in SVMain() () from /opt/libreoffice4.4/program/libvcllo.so #23 0x00007f19b62ac9df in soffice_main () from /opt/libreoffice4.4/program/libsofficeapp.so #24 0x000000000040076b in main () The system was not running out of VM: top - 13:54:31 up 75 days, 22:00, 11 users, load average: 3.10, 2.18, 1.10 Tasks: 301 total, 2 running, 298 sleeping, 0 stopped, 1 zombie %Cpu(s): 35.0 us, 0.7 sy, 0.0 ni, 64.1 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 16101592 total, 14955948 used, 1145644 free, 1178448 buffers KiB Swap: 9820156 total, 1452112 used, 8368044 free. 3751276 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19817 luke 20 0 2728152 307204 40516 R 98.7 1.9 264:32.96 soffice.bin 2505 luke 20 0 1228164 175068 30888 S 9.3 1.1 356:30.60 chromium-b+ 29169 luke 20 0 1208564 167004 33596 S 7.0 1.0 171:43.50 chromium-b+ 1407 luke 20 0 1321248 202352 68864 S 6.3 1.3 247:53.79 chromium-b+ 1151 luke 20 0 2813892 479956 81656 S 6.0 3.0 353:29.58 chromium-b+ 2246 luke 20 0 1523968 226916 43736 S 4.0 1.4 153:22.03 chromium-b+ 29107 luke 20 0 1267292 204464 36932 S 3.3 1.3 33:53.42 chromium-b+ 1753 root 20 0 578388 170660 101500 S 2.0 1.1 1885:07 Xorg 5186 luke 20 0 1827300 536300 54800 S 1.3 3.3 2134:48 firefox 1379 luke 20 0 1728440 498572 121984 S 1.0 3.1 104:51.56 chromium-b+ 3139 luke 20 0 606812 16712 3092 S 1.0 0.1 30:45.43 bamfdaemon 3796 luke 20 0 715704 25668 7644 S 1.0 0.2 23:22.96 gnome-term+ 3275 luke 20 0 684904 11004 5120 S 0.7 0.1 20:26.08 metacity 3622 luke 20 0 1228828 228560 6280 S 0.7 1.4 929:22.80 indicator-+ 9 root 20 0 0 0 0 S 0.3 0.0 20:54.55 rcuos/1 1248 luke 20 0 1235204 184064 15672 S 0.3 1.1 18:49.48 chromium-b+ 1260 luke 20 0 1054124 37728 14088 S 0.3 0.2 3:43.76 chromium-b+ 2472 luke 20 0 1223380 137688 30204 S 0.3 0.9 7:40.46 chromium-b+ 3143 luke 20 0 18112 416 288 S 0.3 0.0 83:13.21 upstart-db+ 3282 luke 20 0 941620 112960 10360 S 0.3 0.7 124:32.16 gnome-panel 25188 luke 20 0 2168260 71708 12764 S 0.3 0.4 201:13.75 chromium-b+ 26588 luke 20 0 864604 21188 9000 S 0.3 0.1 33:12.58 workrave 32663 luke 20 0 25096 1880 1164 R 0.3 0.0 0:00.15 top 1 root 20 0 34360 2428 828 S 0.0 0.0 0:08.61 init ... After 30 mins I had to just kill it. Running it again I got these error messages, in order: 1: /home/luke/.config/libreoffice/4/user/backup/AToeInTheOceanOfBooks.odt_0.odt does not exist. 2: /home/luke/.config/libreoffice/4/user/backup/AToeInTheOceanOfBooks.odt_0.odt does not exist. 3: Object not accessible. The object cannot be accessed due to insufficient user rights. 4: /home/luke/.config/libreoffice/4/user/backup/reviews.odt_0.odt does not exist. 5: /home/luke/.config/libreoffice/4/user/backup/reviews.odt_0.odt does not exist. 6: Object not accessible. The object cannot be accessed due to insufficient user rights. 7: /home/luke/.config/libreoffice/4/user/backup/WildThing-w.cover-bigtext.odt_0.odt does not exist. 8: /home/luke/.config/libreoffice/4/user/backup/WildThing-w.cover-bigtext.odt_0.odt does not exist. 9: Object not accessible. The object cannot be accessed due to insufficient user rights. After that the recovery process continued, and the three files were listed as Recovered, but each with a yellow tick instead of a green tick. (May I ask, what was LO recovering, if there were no files in the backup area? Where was the recovery data coming from?) Clicking Finish lead to this warning: The automatic recovery process was interrupted [That's not true, BTW] The documents listed below will be saved in the folder noted below if you click 'Save'. Click 'Cancel' to close the wizard without saving the documents. AToeInTheOceanOfBooks.odt reviews.odt WildThing-w.cover-bigtext.odt When I looked at the file I'd been editing, again all my edits had been lost (about 20 mins of work, again). This is quite annoying, as I'm sure you understand. It's doubly annoying because each time the autosave kicks in, you lose all typing and mouse clicks while it happens (about 20 secs), and if it's autosaving every 10 mins, interrupting me, but not actually auto-saving and *not reporting that the autosave is failing*, that's just rubbing salt into the wound. Oh, and I just discovered that LO also misinformed me when it said that it would autosave the documents in /home/luke: after I closed the file (and accepted that LO should save it), the file that it updated was the one in my working directory: the 'recovered' file did not exist in /home/luke, which is quite infuriating, since I would not have let it overwrite the copy in my working directory with the 'recovered' file had I been given the choice. The autosave directory looks fine to me: $ ls -lad /home/luke/.config/libreoffice/4/user/backup/ drwxrwx--x 2 luke kendall 4096 Jul 3 13:40 /home/luke/.config/libreoffice/4/user/backup/ $ ls -lad /home/luke/.config/libreoffice/4/user/ drwxrwx--x 16 luke kendall 4096 Jul 3 14:24 /home/luke/.config/libreoffice/4/user/ $ ls -lad /home/luke/.config/libreoffice/4/ drwx------ 4 luke kendall 4096 Jul 3 14:24 /home/luke/.config/libreoffice/4/ $ ls -lad /home/luke/.config/libreoffice/ drwxrwx--x 3 luke kendall 4096 Jan 28 2014 /home/luke/.config/libreoffice/ $ ls -lad /home/luke/.config/ drwxr-xr-x 53 luke kendall 4096 Apr 18 15:55 /home/luke/.config/ $ id uid=1000(luke) gid=1001(kendall) groups=1001(kendall),4(adm),8(mail),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),27(sudo),30(dip),44(video),46(plugdev),102(netdev),105(fuse),108(scanner),113(lpadmin),124(sambashare) I hope the above information will be helpful. I'm seriously considering switching to OpenOffice instead of LibreOffice. Now to see if I can remember the edits I made and re do them. Otherwise re-invent them. Grr. luke
(In reply to Luke Kendall from comment #6) > > ... > > I'm seriously considering switching to OpenOffice instead of LibreOffice. > > ... I suggest to upgrade to the latest LibO 4.4.4.3 release. before doing that uninstall 4.4.2, reset the user profile and do a clean new install. also consider updating your Linux distro to its latest stable release (if you haven't done it before) you are free to switch to OOo (now called AOO) but consider that the development of AOO is quite stagnant in the last year and some people think that the project is almost dying.... tell if the LibO issue persist after upgrading and try to identify a specific reproducible scenario where you constantly reproduce the bug
I had trouble removing it. I uninstalled the older LO via Synaptic, no problem. That left me with 4.4., which I'd installed from the LO site. It of course didn't show up in Synaptic. I tried this as root, which failed: # dpkg -P libreoffice4.4 dpkg: dependency problems prevent removal of libreoffice4.4: libreoffice4.4-en-us depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-en-us depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-en-us depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-en-us depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-base depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-base depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-base depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-base depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-math depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-math depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-math depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-math depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-dict-es depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-dict-es depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-dict-es depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-dict-es de dpkg: error processing package libreoffice4.4 (--purge): dependency problems - not removing Errors were encountered while processing: libreoffice4.4 (I wonder why the repeated error messages?) Then I tried this, which also failed: # dpkg -P libreoffice4.4-dict-es libreoffice4.4-math libreoffice4.4-base libreoffice4.4-en-us libreoffice4.4 (Reading database ... 860861 files and directories currently installed.) Removing libreoffice4.4-dict-es (4.4.2.2-2) ... Removing libreoffice4.4-math (4.4.2.2-2) ... Removing libreoffice4.4-base (4.4.2.2-2) ... Removing libreoffice4.4-en-us (4.4.2.2-2) ... dpkg: dependency problems prevent removal of libreoffice4.4: libreoffice4.4-dict-en depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-dict-en depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-dict-en depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-dict-en depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-writer depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-writer depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-writer depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-writer depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-calc depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-calc depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-calc depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-calc depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-impress depends on libreoffice4.4 (>= 4.4.2.2). libreoffice4.4-impress depends on libreoffice4.4 (<= 4.4.2.2-2). libreoffice4.4-impress depends on libreoffice4.4 (>= 4.4.2.2). libreoffi dpkg: error processing package libreoffice4.4 (--purge): dependency problems - not removing Errors were encountered while processing: libreoffice4.4 But eventually, after dpkg reported other LO packages, this sequence seemed to succeed: # dpkg -P libreoffice4.4 libreoffice4.4-dict-es libreoffice4.4-math libreoffice4.4-base libreoffice4.4-en-us # dpkg -P libreoffice4.4 # dpkg -P libreoffice4.4-dict-en libreoffice4.4-writer libreoffice4.4-calc libreoffice4.4-impress libreoffice4.4 # dpkg -r libreoffice4.4 # dpkg -P libreoffice4.4-dict-fr libreoffice4.4-draw libreoffice4.4 Then after installing the new 4.4.4 (.3?) .debs, I remembered I hadn't removed my config files. So then I tried to remove the just-installed 4.4.4 packages, and that was even more difficult: everything I tried said there were dependencies preventing the removal. Like this: # dpkg -P libobasis4.4-en-us libobasis4.4-pyuno libobasis4.4-graphicfilter libobasis4.4-base libreoffice4.4-ure libobasis4.4-core dpkg: dependency problems prevent removal of libobasis4.4-en-us: libobasis4.4-en-us-res depends on libobasis4.4-en-us (>= 4.4.4.3). libobasis4.4-en-us-res depends on libobasis4.4-en-us (<= 4.4.4.3-3). libobasis4.4-en-us-res depends on libobasis4.4-en-us (>= 4.4.4.3). libobasis4.4-en-us-res depends on libobasis4.4-en-us (<= 4.4.4.3-3). libobasis4.4-en-us-writer depends on libobasis4.4-en-us (>= 4.4.4.3). libobasis4.4-en-us-writer depends on libobasis4.4-en-us (<= 4.4.4.3-3). libobasis4.4-en-us-writer depends on libobasis4.4-en-us (>= 4.4.4.3). libobasis4.4-en-us-writer depends on libobasis4.4-en-us (<= 4.4.4.3-3). libobasis4.4-en-us-math depends on libobasis4.4-en-us (>= 4.4.4.3). libobasis4.4-en-us-math depends on libobasis4.4-en-us (<= 4.4.4.3-3). libobasis4.4-en-us-math depends on libobasis4.4-en-us (>= 4.4.4.3). libobasis4.4-en-us-math depends on libobasis4.4-en-us (<= 4.4.4.3-3). libobasis4.4-en-us-calc depends on libobasis4.4-en-us (>= 4.4.4.3). libobasis4.4-en-us-calc depends on libobasis4.4-en dpkg: error processing package libobasis4.4-en-us (--purge): dependency problems - not removing dpkg: dependency problems prevent removal of libobasis4.4-pyuno: libobasis4.4-librelogo depends on libobasis4.4-pyuno (>= 4.4.4.3). libobasis4.4-librelogo depends on libobasis4.4-pyuno (<= 4.4.4.3-3). libobasis4.4-librelogo depends on libobasis4.4-pyuno (>= 4.4.4.3). libobasis4.4-librelogo depends on libobasis4.4-pyuno (<= 4.4.4.3-3). dpkg: error processing package libobasis4.4-pyuno (--purge): dependency problems - not removing (Reading database ... 858326 files and directories currently installed.) Removing libobasis4.4-graphicfilter (4.4.4.3-3) ... dpkg: dependency problems prevent removal of libobasis4.4-base: libobasis4.4-postgresql-sdbc depends on libobasis4.4-base (>= 4.4.4.3). libobasis4.4-postgresql-sdbc depends on libobasis4.4-base (<= 4.4.4.3-3). libobasis4.4-postgresql-sdbc depends on libobasis4.4-base (>= 4.4.4.3). libobasis4.4-postgresql-sdbc depends on libobasis4.4-base (<= 4.4.4.3-3). dpkg: error processing package libobasis4.4-base (--purge): dependency problems - not removing dpkg: dependency problems prevent removal of libobasis4.4-core: libobasis4.4-en-us depends on libobasis4.4-core (>= 4.4.4.3). libobasis4.4-en-us depends on libobasis4.4-core (<= 4.4.4.3-3). libobasis4.4-en-us depends on libobasis4.4-core (>= 4.4.4.3). libobasis4.4-en-us depends on libobasis4.4-core (<= 4.4.4.3-3). libobasis4.4-pyuno depends on libobasis4.4-core (>= 4.4.4.3). libobasis4.4-pyuno depends on libobasis4.4-core (<= 4.4.4.3-3). libobasis4.4-pyuno depends on libobasis4.4-core (>= 4.4.4.3). libobasis4.4-pyuno depends on libobasis4.4-core (<= 4.4.4.3-3). libobasis4.4-base depends on libobasis4.4-core (>= 4.4.4.3). libobasis4.4-base depends on libobasis4.4-core (<= 4.4.4.3-3). libobasis4.4-base depends on libobasis4.4-core (>= 4.4.4.3). libobasis4.4-base depends on libobasis4.4-core (<= 4.4.4.3-3). libobasis4.4-kde-integration depends on libobasis4.4-core (>= 4.4.4.3). libobasis4.4-kde-integration depends on libobasis4.4-core (<= 4.4.4.3-3). libobasis4.4-kde-integration depends on libobasis4.4 dpkg: error processing package libobasis4.4-core (--purge): dependency problems - not removing dpkg: dependency problems prevent removal of libreoffice4.4-ure: libobasis4.4-core depends on libreoffice4.4-ure (>= 4.4.4.3). libobasis4.4-core depends on libreoffice4.4-ure (<= 4.4.4.3-3). libobasis4.4-core depends on libreoffice4.4-ure (>= 4.4.4.3). libobasis4.4-core depends on libreoffice4.4-ure (<= 4.4.4.3-3). dpkg: error processing package libreoffice4.4-ure (--purge): dependency problems - not removing Errors were encountered while processing: libobasis4.4-en-us libobasis4.4-pyuno libobasis4.4-base libobasis4.4-core libreoffice4.4-ure Yet dpkg seems to indicate I have *only* libreoffice4.4-ure installed root@pute:/home/luke/linux/downloads/LibreOffice_4.4.4.3_Linux_x86_deb/DEBS# dpkg -l | grep office | cat -tvu pi libreoffice4.4-ure 4.4.4.3-3 i386 UNO Runtime Environment .4.3 I eventually found that I could remove some packages, and I could try to purge some, and it would admit that there were other dependencies, and I could either remove those, or instead it would reveal that there were yet other hidden dependencies, but eventually I found a <sarcasm>simple and obvious chain</sarcasm> that seemed to get everything: # dpkg -P libreoffice4.4 libreoffice4.4-base libreoffice4.4-calc libreoffice4.4-debian-menus libreoffice4.4-dict-en libreoffice4.4-dict-es libreoffice4.4-dict-fr libreoffice4.4-draw libreoffice4.4-en-us libreoffice4.4-impress libreoffice4.4-math libreoffice4.4-ure libreoffice4.4-writer openoffice.org-hyphenation | cat -tvu # dpkg -l | grep office # dpkg -P libobasis4.4-core libreoffice4.4-ure | cat -tvu # dpkg -P libobasis4.4-en-us libobasis4.4-ooofonts libobasis4.4-filter-data libobasis4.4-draw libobasis4.4-core libreoffice4.4-ure # dpkg -P libreoffice4.4-ure libobasis4.4-calc libobasis4.4-pyuno libobasis4.4-extension-nlpsolver libobasis4.4-en-us libobasis4.4-core # dpkg -l | grep office # dpkg -l | grep office | cat -tvu # dpkg -P libreoffice4.4-ure # dpkg -P libreoffice4.4-ure libobasis4.4-core # dpkg -P libobasis4.4-en-us libobasis4.4-pyuno libobasis4.4-graphicfilter libobasis4.4-base libreoffice4.4-ure libobasis4.4-core # dpkg -l | grep office | cat -tvu # pushd ~luke # dpkg -l | grep office | cat -tvu # dpkg -P libobasis4.4-kde-integration # dpkg -P libobasis4.4-base # dpkg -P libobasis4.4-postgresql-sdbc # dpkg -P libobasis4.4-base # dpkg -P libreoffice4.4-ure # dpkg -P libobasis4.4-core # dpkg -P libobasis4.4-en-us libobasis4.4-pyuno libobasis4.4-writer libobasis4.4-extension-pdf-import # dpkg -P libobasis4.4-librelogo # dpkg -P libobasis4.4-pyuno # dpkg -P libobasis4.4-en-us # dpkg -P libobasis4.4-en-us-math # dpkg -P libobasis4.4-en-us-calc # dpkg -P libobasis4.4-en-us-writer # dpkg -P libobasis4.4-en-us-res # dpkg -P libobasis4.4-en-us # dpkg -P libobasis4.4-en-us-base # dpkg -P libobasis4.4-en-us # dpkg -P libobasis4.4-en-us-writer # dpkg -P libreoffice4.4-ure # dpkg -P libobasis4.4-core # dpkg -P libobasis4.4-extension-mediawiki-publisher # dpkg -P libobasis4.4-onlineupdate # dpkg -P libobasis4.4-ooolinguistic # dpkg -P libobasis4.4-writer # dpkg -P libobasis4.4-core # dpkg -P libobasis4.4-images libobasis4.4-python-script-provider libobasis4.4-math libobasis4.4-gnome-integration # dpkg -P libobasis4.4-core # dpkg -P libobasis4.4-extension-beanshell-script-provider libobasis4.4-impress libobasis4.4-extension-report-builder # dpkg -P libobasis4.4-ogltrans # dpkg -P libobasis4.4-extension-beanshell-script-provider libobasis4.4-impress libobasis4.4-extension-report-builder # dpkg -P libobasis4.4-core # dpkg -P libobasis4.4-extension-javascript-script-provider libobasis4.4-xsltfilter # dpkg -P libobasis4.4-core # dpkg -l | grep libo # dpkg -P libreoffice4.4-ure # dpkg -l | grep office My god, dpkg is an abomination as far as usability is concerned! The good thing is, that after that, instead of reporting that it was installing over the top of 4.4.2.2 things, everything was like this: Selecting previously unselected package libreoffice4.4-writer. Preparing to unpack libreoffice4.4-writer_4.4.4.3-3_i386.deb ... Unpacking libreoffice4.4-writer (4.4.4.3-3) ... Selecting previously unselected package libreoffice4.4. Preparing to unpack libreoffice4.4_4.4.4.3-3_i386.deb ... Unpacking libreoffice4.4 (4.4.4.3-3) ... Setting up libreoffice4.4-debian-menus (4.4.4-3) ... Unfortunately, LO no longer appears in the gnome menu. When I try to run it by hand I get: /opt/libreoffice4.4/program/soffice javaldx: Could not find a Java Runtime Environment! Warning: failed to read path from javaldx /opt/libreoffice4.4/program/soffice.bin: error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory I note that Synaptic says I have libdbus-glib-1-2 (v 0.100.2-1) installed and JRE and default-jre (2:1.7-51) installed, so I'm feeling rather lost now. Any suggestion? Since now I have no working LO. Any idea what I've done wrong? Oh, and I'm running Ubuntu 14.04.2 LTS which I believe is sufficiently up to date.
here's some extra info: $ ldd /opt/libreoffice4.4/program/soffice.bin | grep "not found" libdbus-glib-1.so.2 => not found $ locate libdbus-glib-1.so.2/alt-slash32bit/usr/lib/i386-linux-gnu/libdbus-glib-1.so.2 /alt-slash32bit/usr/lib/i386-linux-gnu/libdbus-glib-1.so.2.2.2 /opt/calibre/lib/libdbus-glib-1.so.2 /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2.2.2 $ LD_LIBRARY_PATH=/usr/lib:/lib:/usr/X11/lib:/usr/local/lib:/usr/lib/x86_64-linux-gnu/ /opt/libreoffice4.4/program/soffice javaldx: Could not find a Java Runtime Environment! Warning: failed to read path from javaldx /opt/libreoffice4.4/program/soffice.bin: error while loading shared libraries: libdbus-glib-1.so.2: wrong ELF class: ELFCLASS64 Ah - I've downloaded the 32 bit version, not the 64 bit. Sigh. Now to dpk -P again...
-rw-rw---- 1 luke kendall 229835706 Jul 3 16:23 LibreOffice_4.4.4_Linux_x86-64_deb.tar.gz $ tar xvzf LibreOffice_4.4.4_Linux_x86-64_deb.tar.gz LibreOffice_4.4.4.3_Linux_x86-64_deb/ LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/ LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libobasis4.4-ogltrans_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libobasis4.4-base_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libobasis4.4-onlineupdate_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libobasis4.4-ooolinguistic_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libobasis4.4-en-us-base_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libreoffice4.4-math_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libreoffice4.4-en-us_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libreoffice4.4-dict-es_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libreoffice4.4-dict-en_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libreoffice4.4_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libreoffice4.4-draw_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libobasis4.4-math_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libreoffice4.4-impress_4.4.4.3-3_amd64.deb LibreOffice_4.4.4.3_Linux_x86-64_deb/DEBS/libobasis4.4-en-us-calc_4.4.4.3-3_amd64.deb tar: Skipping to next header tar: Archive contains ‘U\324\346\035t\001\327e8\216\232\v’ where numeric off_t value expected gzip: stdin: invalid compressed data--crc error gzip: stdin: invalid compressed data--length error tar: Child returned status 1 tar: Error is not recoverable: exiting now I'm trying to find a checksum file for the release, or an alternative download site, but no luck so far. I'm not enjoying this.
sorry I can't help you with this specific Linux issues since I have only Windows. I set status back to UNCONFIRMED hoping that some Linux QA user may help you.
Wow, it's not been my lucky day. I downloaded it again; file was the same size, but this time: $ cmp LibreOffice_4.4.4_Linux_x86-64_deb.tar.gz /home/luke/linux/downloads/LibreOffice_4.4.4_Linux_x86-64_deb.tar.gz LibreOffice_4.4.4_Linux_x86-64_deb.tar.gz /home/luke/linux/downloads/LibreOffice_4.4.4_Linux_x86-64_deb.tar.gz differ: byte 11259805, line 41793 And the tar xvzf worked just fine. Still no integration into the Gnome menu, though. Though I can start it correctly from the commandline, and I'm back in action. I'll see how I go with LO 4.4.4.3 Note that a summary of the errors I suffered with 4.4.2.2 were: 1. It locked up (100% CPU) 2. It said it was autosaving at regular intervals 3. When I killed it, it said there was no backup to recover 4. It somehow recovered something anyway, and sai it would save it in /home/luke, but it instead saved it over the top of the file in the working directory. And the main error with the .deb files provided for 4.4.4 x86_64 is that there is not integration into the desktop menus under Ubuntu 14.04 (not Unity, classic style desktop). Anyway, I'll see how I go. I suppose a simple test will be to wait until an autosave has happened, and then look to see if there are any files in ~/.config/libreoffice/4/user/backup/. After waiting to see, I can report that for now, there is one there: $ ls -l ~/.config/libreoffice/4/user/backup/ total 700 -rw------- 1 luke kendall 612964 Jul 3 16:52 WildThing-w.cover-bigtext.odt_0.odt I hope I won't lose more work. But if I do, I'll file a fresh report under 4.4.4.3 version.
Ok, let's go back to NEEDINFO I hope you won't suffer other issues.
Let me just add that although I was feeling grumpy about all this, and the time it cost me, I've had Microsoft Office 10 9and all the earlier versions) crash on me, too, and that usually loses work, and often also leaves the document in a corrupted state that will either crash Word again next time you try to edit the document, or else it'll be so confused you spend hours trying to get it back into a stable shape. So even with what happened, I still prefer LO to Word.
It just happened again. This time I lost an hour and a half of work. (Which is weird: I really thought I was saving, manually, much more frequently because I'm now worried about losing work. Could I have been that focused on the work? I suppose it's possible.) It was with version 4.4.4.3 and apport submitted a bug automatically - so I doubt that I need to do a fresh one for 4.4.4.3 this time, right? Some other info... While apport was running, I did an ls on the backup directory, and noticed there was no backup file for the doc I was editing - even though when I'd checked earlier, there was, and even though LO had been interrupting me every 10 mins with the slow autosave. Again, I got three errors during the "recovery": /home/luke/.config/libreoffice/4/user/backup/WildThing-w.cover-bigtext.odt_0.odt does not exist. /home/luke/.config/libreoffice/4/user/backup/WildThing-w.cover-bigtext.odt_0.odt does not exist. Object not accessible. The object cannot be accessed due to insufficient user rights. Once again, it gave a yellow tick for the document in question and misinformed me when it said that it would autosave the documents in /home/luke: after I recovered the file, there was no such file saved there. And when I did a Save in LO instead of saving it in /home/luke (as promised by the message), the file that it updated was the one in my working directory. This time, though, I had moved the file aside first: -rw-rw---- 1 luke kendall 582189 Jul 4 22:34 WildThing-w.cover-bigtext.odt -rw-rw---- 1 luke kendall 584508 Jul 4 21:15 WildThing-w.cover-bigtext.odt-aside Despite the file I had moved aside being larger, I could see no differences between the two files. I did a "Compare" of the two documents, but I could see no way to detect the result of the comparison. It occurs to me that I have the eLAIX installed. I have now removed that and I will see how I go.
And another crash. Again, no file in the backup area: ~/.config/libreoffice/4/user/backup/ Yet this time it said it recovered the file correctly - and it does look good, only losing perhaps 5 minutes of editing. Note that this happened with the eLAIX extension removed, so that can't be the culprit. Again, apport was running while LO had frozen, so I assumed it reported the bug. I've gotten good at taking a photo of the frozen screen, so at least I can easily redo the edits on the current screen's worth of text.
Oh, I had another crash today, but I only lost a few minutes of work, and teh auto-recovery worked properly again. That's twice in a row, since I removed the eLAIX extension. (Exit status of crash was 139, if that's any help.) This time, apport didn't detect the crash.
This bug doesn't make any progress. Please appreciate the time of us who triage or develop here.
I do appreciate that triage a hard-to-reproduce bug is tedious and takes time. I'd ask you to appreciate that a bug that crashes LO and loses all the work from the previous save is also quite a big problem for a user. Is there anything more I can do? It hasn't happened for a while, but I haven't been editing as many large documents with as many comments. If you have a suggestion for something I can do that would make the triag-ing easier, let me know and I'll see if I can do that. I see you've marked the bug as Resolved. That's very disappointing. I think that's a policy error: it would be better to introduce a new category: Postponed or TooHard or something. But I appreciate your difficulty: tracking down a hard-to-reproduce crash in a big program is enormously difficult.