Problem description: I'm using LO 4.0.2.2 on a slackware/Linux box. I started the extension manager (tools->extension manager) and then clicked "check for updates". LO crashes (leaving a core file). I see: terminate called after throwing an instance of 'com::sun::star::deployment::DeploymentException' on the console. This is 100% reproducible. Steps to reproduce: 1. tools->extension manager->check for updates.... Current behavior: Crash Expected behavior: Extension Status Operating System: Linux (Other) Version: 4.0.2.2 release Last worked in: (See in Summary)
I CAN"T repoduce this bug running LibreOffice 4.0.2.2 on Ubuntu 12.10 or Mac osx 10.8.3.
I also can't reproduce this behavior using Linux Mint 14 x64 with LibreOffice 4.0.2.2 and master Version: 4.1.0.0.alpha0+ Build ID: 7b515a57eb6a644860715018656ac0b843b62ba It seems like an individual problem. Therefore I think this is caused by an extension we don't have installed. @bug reporter: 1) what extensions do you have installed? 2) what extension does cause this behavior? You can determine this by reseting your user profile (guide: https://wiki.documentfoundation.org/UserProfile#Resetting_the_user_profile) and install all extensions again one by one. After each installation check for updates. If this is still reproducible with an user profile reset, we need to look for another cause I guess. Kind regards, Joren
OK I think that I've narrowed down the problem. First, I have no additional extensions installed (I've just switched to LO from OO). Even with me moving my profile away, I get the "Installation extensions" English spelling dictionaries,.... French spelling dictionary, ... Presentation Minimizer Report Builder Solver for nonlinear programming Spanish spelling dictionary wiki publisher If I run as root and check for updates things work as expected, so I suspect that this is related to the lack of write-access to the installed ones or the lack of any shared/user extensions. On the other hand, adding some extensions doesn't fix the problem (even with "installation" unchecked.
David's assumption concerning write access problems seems plausible and has to be solved by him, but of course LibO may not crash because of such a problem, but give a useful error message. Following David's ideas I found and submitted "Bug 63288 - CONFIGURATION: CRASH if user profile sub folder "extensions" is write protected" fow WIN, what at least might be related (or even a DUP, we will see ...) David: It would be great if you could contribute an instruction how to make your problem reproducible like "make folder xyz 'read only' doing this and that ..."
David: could you try to retrieve a backtrace? (see https://wiki.documentfoundation.org/BugReport#How_to_get_a_backtrace_on_Linux)
Created attachment 77704 [details] strace output I've attached the strace -f libreoffice4.0 output. Basically, I opened LO, went to the extension manager and triggered the bug. Note that the file is 72M log (compressed), and so I've split it into 100000 line chunks and have uploaded the last two (100099 lines).
David: your strace may be useful (I haven't taken a look yet) but could you retrieve a backtrace (= stacktrace)? see https://wiki.documentfoundation.org/BugReport#How_to_get_a_backtrace_on_Linux
The stack-trace was easy--a full back-trace is not since I'm on Slackware not Ubuntu etc. I'll see what I can do, but please have a look at the stack-trace on the unlikely chance that it will point to where the problem lies
David: Was the installation of 4.0.2.2 an upgrade or an install from scratch? If upgrade, could you try to uninstall every LO part and install again?
I'm not 100% sure how to respond to comment 9. I'm on Slackware which doesn't use RPM as it's main update tool. Here's what I did: 1. moved /opt/libreoffice4.0 away; 2. Installed the rpm's manually with "-U --force --nodeps -h" as the options. I've also played with moving ~/.configure/LO away--nothing changes.
Created attachment 77829 [details] Backtrace I ran libreoffice4.0 --backtrace, started the extension manager, and checked for updates. The backtrace looks more useable than I'd expected.
David: thank you for your feedback and sorry for the delay. I noticed this line in your strace file: 99986 6866 access("/home/ronis/.config/libreoffice/4/user/uno_packages/cache/uno_packages/lu2rmmz0.tmp_/dict-en", F_OK) = -1 ENOENT (No such file or directory) Could you confirm you renamed your LO directory profile as you indicated in comment 10? if not, just do: mv ~/.config/libreoffice ~/.config/libreoffice_back then test again If yes, could you attach a new strace (we shouldn't see anymore the line I quoted)? The goal is to try to reproduce the problem with a brand new LO directory profile.
I tried again (moved ~/.config/lilbreoffice away and restarted from scratch). I added various extensions and then tried to crash LO. This time it worked! It seems that LO is very sensitive to finding temporary files like those in the cache. That makes even more sense in my setup in that I use rsync to synchronize the ~/.config/libreoffice tree across my work and home machines and my laptop. I suspect that if one of them gets broken (e.g., a cache file is corrupted during a crash) then they all go down. As a test, I made .config/libreoffice/4/user/uno_packages/cache unreadable and unwritable with (chmod 0 cache), the crash comes back. Several suggestions/questions: Shouldn't LO check to see if there is a usable cache file (or directory) and if not simply create it? As an extreme example, shouldn't I be able to delete all of .config/libreoffice/4/user/uno_packages/cache and still start a fresh LO session? A better error message is required (perhaps as a popup) giving an option to make cache read/write enabled or to recreate it from scratch. In any event, thanks for all you help.
Thank you David for your interesting feedback! Michael: I put you on cc as the last David's comment may interest you. I'm pretty sure I've already read a discussion or another bug with the read-only element which triggers the crash.
Yes - looks rather like that calc enter '=' into the formula bar crashes after upgrade - the root cause of which is still not known or well understood; it looks like this happens in a thread: Thread 25 (Thread 0x93321b70 (LWP 20190)): #0 0xb7c7b2d7 in raise () from /lib/libc.so.6 #1 0xb7c7ccee in abort () from /lib/libc.so.6 #2 0xb7e4556d in __gnu_cxx::__verbose_terminate_handler() () from /usr/X11/lib/libstdc++.so.6 #3 0xb7e431b3 in ?? () from /usr/X11/lib/libstdc++.so.6 #4 0xb7e431ef in std::terminate() () from /usr/X11/lib/libstdc++.so.6 #5 0xb7e434e5 in __cxa_rethrow () from /usr/X11/lib/libstdc++.so.6 #6 0xb79b8d9b in salhelper::Thread::run() () from /opt/libreoffice4.0/program/../ure-link/lib/libuno_salhelpergcc3.so.3 #7 0xb79b900a in threadFunc () from /opt/libreoffice4.0/program/../ure-link/lib/libuno_salhelpergcc3.so.3 #8 0xb7fa5fa9 in osl_thread_start_Impl () from /opt/libreoffice4.0/program/../ure-link/lib/libuno_sal.so.3 Which is unusual. Stephan might be interesting for you too ? :-)
* Note that "I use rsync to synchronize the ~/.config/libreoffice tree across my work and home machines and my laptop" might be a source of various problems. * I can /not/ reproduce the problem when doing "chmod 0 ~/.config/libreoffice/4/user/uno_packages/cache"; for me, that leads to "Tools - Extension Manager..." silently doing nothing (instead of opening the Extension Manager dialog). (And note that "cache" is somewhat of a misnomer there---the data stored there is not strictly merely an optimizing cache.) * Thread 25 terminating with a com::sun::star::deployment::DeploymentException (as per comment 0) is apparently the dp_gui::UpdateDialog::Thread (desktop/source/deployment/gui/dp_gui_updatedialog.cxx). Unfortunately, in a non-debug LO build, it is not possible to get at the interesting part of that exception, namely its Message (we would need to derive com::sun::star::uno::Exception from std::exception in order for __gnu_cxx::__verbose_terminate_handler to show a message, but we cannot do that for UNO compatibility reasons).
Dear Bug Submitter, 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 INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/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
I'm not sure what needed information is referred to in comment 17. In any event, I've moved on to LO 4.2.4.2 and the problem doesn't recur.
David: indeed you're right, it because this tracker hadn't been put to NEW (since you retrieved a backtrace). Now last stable LO version is 4.2.4 (or 4.1.6 for 4.1 branch). Could you give a try to a more recent LO version? For this, uninstall any LO part you have. Install last LO version you can retrieve with your distrib and try as a mere user (I mean not root:-))
(In reply to comment #18) > I'm not sure what needed information is referred to in comment 17. In any > event, I've moved on to LO 4.2.4.2 and the problem doesn't recur. (In reply to comment #19) > David: indeed you're right, it because this tracker hadn't been put to NEW > (since you retrieved a backtrace). > > Now last stable LO version is 4.2.4 (or 4.1.6 for 4.1 branch). > > Could you give a try to a more recent LO version? > For this, uninstall any LO part you have. Install last LO version you can > retrieve with your distrib and try as a mere user (I mean not root:-)) I'm using LO 4.2.4.2 which is the most recent version, no? With it I don't get the crash.
David: so the bug seems fixed:-) So I put it as WFM.