since upgrade to LO4 this bug is present on my Arch Linux install (Gnome desktop). Basically, because of the fault outlined in the header, Calc is unusable. When it happens (and how to re-create it): Whenever I try to type a "=" or click Function (=) button to create a formula, or change the existing one, Calc crashes. Happens with both existing and new documents. What I tried to get it fixed: Renamed my LO profile, to force the creation of the new one. Created brand new user account and tested there. Neither of these help. Ran Calc from terminal with command: libreoffice --calc. Upon the crash the following error displayed in terminal: terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException' Output of uname -a : Linux home 3.8.4-1-ARCH #1 SMP PREEMPT Wed Mar 20 22:10:25 CET 2013 x86_64 GNU/Linux If you need any extra info, or can suggest any steps to clarify the problem for you, let me know, I'll be happy to assist. Cheers, Vitaliy
Marking it critical, as the software is basically unusable while this bug is present.
A question about this in Ask: http://ask.libreoffice.org/en/question/15519/lo-4-calc-crashes-whenever-is-typed-or-formula/ Changing platform to "All" because some users report the same problem in Windows 8. In Windows XP SP3 everything works without any problems.
On pc Debian x86 with master sources updated today, I don't reproduce this. Also, I don't reproduce this on Win7 64 with LO 4.0.1.2 Vitaliy: could you try to retrieve a backtrace? https://wiki.documentfoundation.org/BugReport#How_to_get_a_backtrace_on_Linux
*** Bug 63055 has been marked as a duplicate of this bug. ***
Vitaliy: what's the UI language? Rainer/Joël: put you in cc, you might be interested since this problem is crucial for Calc using and happens on the 3 platforms, but not for every user.
Similar if not identical bug is fdo#60358, corrective steps are in the comments, see if that solves it. Please backup your profile, if it's corrected we'd love to get a zip of your corrupted profile to try to track down the issue
https://bugs.freedesktop.org/show_bug.cgi?id=60358
NOT reproducible with server installation of "LibO 4.0.1.2 release - German UI / German Locale [Build ID: 84102822e3d61eb989ddd325abf1ac077904985)]" {tinderbox: @6, pull time 2013-02-28 08:53(?)} on German WIN7 Home Premium (64bit) with newly created user profile ….\LibreOffice\4012\ Too few users affected for a general problem. @Vitaliy I am not familar with Linux, what does "Created brand new user account and tested there." mean? Is the result some completely untouched installation with nes User profile? If not you should try a parallel installation due to <https://wiki.documentfoundation.org/Installing_in_parallel#Linux> @hector Same recommendation, <https://wiki.documentfoundation.org/Installing_in_parallel#Windows> It's important to get a common base for the tests, any update or similar might have inherited settings or whatever
Modify Version info due to DUPs.
*** Bug 63099 has been marked as a duplicate of this bug. ***
If we can't get a backtrace. bibisecting <https://wiki.documentfoundation.org/Bibisect> might be a way to narrow down possible roots.
(In reply to comment #3) > On pc Debian x86 with master sources updated today, I don't reproduce this. > Also, I don't reproduce this on Win7 64 with LO 4.0.1.2 > > Vitaliy: could you try to retrieve a backtrace? > https://wiki.documentfoundation.org/BugReport#How_to_get_a_backtrace_on_Linux Julien: thanks for the link. created the backtrace and put it here [code]http://speedy.sh/bgBHM/gdbtrace.zip[/code]
(In reply to comment #6) > Similar if not identical bug is fdo#60358, corrective steps are in the > comments, see if that solves it. Please backup your profile, if it's > corrected we'd love to get a zip of your corrupted profile to try to track > down the issue Joel: by all means. Zipped it up and put here: http://speedy.sh/GjrUH/libreoffice-config.zip
Answering other questions here. Julien: User interface -- english (GB) Rainer: new user account -- I normally work under one login (the only one on this computer). For this testing purpose, I created new user, logged in with new credentials and ran Calc, reproducing the crash. The point was, for the application to create new profile for the user, starting with clean slate, as LO user profile lives in user's home directory. The only common thing when running app from two different user accounts are system-wide defaults (which were never altered, as I don't know where they are). Joel: thanks for the link to the bug #60358. I read it and will attempt to remove and reinstall LO. Profile renaming I tried with same result. Everyone: Thanks for your time and suggestions. Vitaliy
Currently I think we have enough for the experts ... (In reply to comment #14) I think that is not the same "clean thing", at least under WIN the new user will work with a new user profile, but with the same program installation. If the BT does not lead to new and interesting knowledge such a parallel installation might be something you can try.
Created attachment 77410 [details] backtrace
Created attachment 77411 [details] user config folder (zip)
Oops, only now did I realize there's attachment tool available right here! Never mind...
The trace is: #4 0x00007ffff7660fc3 in std::terminate() () from /usr/lib/libstdc++.so.6 #5 0x00007ffff76611ee in __cxa_throw () from /usr/lib/libstdc++.so.6 #6 0x00007fffddc1decb in ?? () from /usr/lib/libreoffice/ure/lib/libgcc3_uno.so #7 0x00007fffddc1bddf in ?? () from /usr/lib/libreoffice/ure/lib/libgcc3_uno.so #8 0x00007fffddc1c441 in ?? () from /usr/lib/libreoffice/ure/lib/libgcc3_uno.so #9 0x00007fffddc24cfa in privateSnippetExecutor () from /usr/lib/libreoffice/ure/lib/libgcc3_uno.so #10 0x00007ffff60add0c in ?? () from /usr/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #11 0x00007fffaf641220 in ScUnoAddInCollection::Initialize() () from /usr/lib/libreoffice/program/../program/libsclo.so #12 0x00007fffaf64221f in ScUnoAddInCollection::GetFuncCount() () from /usr/lib/libreoffice/program/../program/libsclo.so #13 0x00007fffaf5f1025 in ?? () from /usr/lib/libreoffice/program/../program/libsclo.so Out of interest what is printed on the console when it fails ? Can you install the relevant debuginfo package for the code and get a new stack-trace ? :-) Apparently there is some evil problem with void ScUnoAddInCollection::Initialize() which interestingly catches no exceptions. Noel - I wonder if something might jump out of: b30ee83058793ea8fbb020e5ac8f118bd20853d5 for some corner case ?
Nope, sorry, I didn't mess with the Initialize() method.
Michael: Sorry, can not provide any more crash details, as after wiping off existing installation of LO, manual cleanup of some residue files and re-installation of LO, the problem is gone. The only additional detail which I found, is that there were couple of dictionaries I installed long ago, following instructions on then Open-Office wiki (IIRC). I completely forgot about them and they only came visible after LO uninstall -- Locate found some open-libre-office related files in /usr/lib/libreoffice. And those I manually deleted. Also, I restored my original user profile in ~/.config/libreoffice and with it application works, too. So, for me this issue is resolved. I sincerely appreciate your time, guys, and all good (and working) suggestions you provided. Other lowly users like me, who have this or similar problem, I urge to invest an hour of your time and perform this wipeout-cleanup-reinstall cycle before submitting bug reports ;) Can this bug now marked as resolved?
@Vitaliy (In reply to comment #21): We have some DUPLICATES, let's wait what they say when they have tried your workaound. And my suspect is that we here have some fatal interaction between particular (may be very old inherited) LibO installations and current new versions, so we still should try to find out what happens to eliminate vulnerability from LibO. We will care about Status for this bug, currently no need for further actions by you. Thank you for your contribution!
> Nope, sorry, I didn't mess with the Initialize() method. Bear in mind that the stack trace is incomplete, and things may well be inlined; the ReadFromAddIn method had quite a lot of changes in that commit :-) and is called only twice, only from that method. The "com.sun.star.beans.Introspection" creation could previously fail, but now would throw an (un-caught) exception - (I guess) ? Then again - that seems like a pretty core component - no idea why there was code there to cope with it not being around; hmm - still it did in fact crash :-)
re-testing with the user's reported profile: can't reproduce the issue. Rainer - do you have bug numbers for any duplicates ? it's rather frustrating not to be able to reproduce it ... Thanks ! :-)
I tried Vitaliy's user profile with my Current Master, worked without problems, no crash (what matches with Vitaliy's Comment 21) @Michael (In reply to comment #24): Only the ones listed here: Bug 63055, Bug 63099
(In reply to comment #25) > I tried Vitaliy's user profile with my Current Master, worked without > problems, no crash (what matches with Vitaliy's Comment 21) > > @Michael (In reply to comment #24): > Only the ones listed here: Bug 63055, Bug 63099 @Rainer/Michael, I had also put in "see also" fdo#62155 (https://bugs.freedesktop.org/show_bug.cgi?id=62155) I think but I'm not sure (because it could be at another moment than when typing "=") it's a dup and I had no feedback for the moment:-(
*** This bug has been marked as a duplicate of bug 62155 ***