Trying to open an existing document crashes LibreOffice. It doesn't matter what document type. All crash with the same error message: "std::bad_alloc". This is from LibreOffice main window. Opening the document from File->Open ... may succeed.
For the test, could you rename your LibreOffice directory profile (see https://wiki.documentfoundation.org/UserProfile) and give it a new try? What is your OS?
This might also be interesting, if you want to investigate deeper https://wiki.documentfoundation.org/QA/BugReport/Debug_Information
@Thomas please give update of the bug status after profile reset as suggested in comment 1 status NEEDINFO
Created attachment 121465 [details] backtrace
OS: Linux: Ubuntu 14.04, 15.10 LibreOffice: Build-ID: 1:5.0.3~rc2-0ubuntu1~trusty2 Seeing these crashes regularly opening files. I've tried: - new, blank profile -> crash opening files - turning off any extensions/plugins -> crash opening files - new profile, no plugins -> chrash opening files - opening a template -> crash opening the template afterwards you're in a document-recovery loop: the document is stated as scheduled for recovery and asked if you want to recover the document. If you say yes, the document is successfully recovered, then, loading the document LO crashes. Next time you will be prompted again if you would like to recover this document. The bug is seen for: - all LO related documents.
Comments from IRC #libreoffice-dev: std::bad_alloc is an out of memory exception the backtrace does not show a std::bad_alloc, it looks like a SIGSEGV in the sidebar code while freeing a window
Created attachment 121479 [details] backtrace (strace.log + gdbtrace.log) This may not exactly the same problem I am encountering, but it certainly sounds very similar. Setup: a newly updated Suse 42.1, with KDE (KDE Frameworks 5.16.0, Qt 5.5.0 (built against 5.5.0), The xcb windowing system) Libre Office Version: 5.0.2.2, Build-ID: 00m0(Build:2) (fom the Suse Repo) (debug packages from http://download.opensuse.org/repositories/LibreOffice:/Factory/openSUSE_Factory/. "libreoffice-debuginfo-5.0.2.2-1.2.x86_64" mentioned in gdbtrace.log appears not to exist anywhere.) LibreOffice crashes Plasma (and/or X) on opening any type of file (tested for .odt and .ods) every time. Starting LO without a file works, as soon as file is opened via menu, it crashes although the file's content is actually visible a split second. Toggling LO options --> Ansicht --> Grafikausgabe --> use(not) openGL has no effect. I initially suspected a version 5 bug. Therefore I downgraded to 4.4.7 which also crashes. (The following refers again to 5.0.2.2) My next suspicion was a Plasma bug: Therefore tried all available KDE-System settings for Compositor (i.e. openGL 2.0, the default; openGL 3.1; XRender) with no result. The attached backtrace info (see caveat on gdbtrace.log above) was created with XRender active. (I have not yet tried renaming the profile.)
To all: you could also verify that the crash is present on 5.0.4 https://wiki.documentfoundation.org/Installing_in_parallel/Linux http://www.libreoffice.org/download/pre-releases/
Ah, now I linked to pre-releases even though 5.0.4 is stable.. well, test with 5.1 RC1 while you're at it :)
Persists with 5.0.4.2 installed from the suse-Tumbleweed Repo.
Same for 5.1rc1
By now, after having used Suse Leap with the Qt5/Plasma desktop for about a week I strongly suspect that the root of the problem is in Plasma/KDEFrameworks or whatever else is new, since several other programmes (e.g. fontforge, ding) also crash in exactly the same way, that is the programme as such starts but as soon as a file is opened a crash occurs.
Adi: ok, I guess you will file a report to KDE's bug tracker. Thomas is probably using Ubuntu with Unity and not KDE..?
Hello, Same problem using Libreoffice 5.0.4.2 with Debian 8.3 and Gnome 3.14 Many odt files cannot be fully opened : loop of recovery tries, then file opening is immediately followed by bad_alloc error and LO crash. Sometimes these files can be opened through the top menu, but not always. Who can fix it ?
Patch <a href="https://www.suse.com/support/update/announcement/2016/suse-ru-20160333-1.html">SUSE-RU-2016:0333-1</a> (References: #679938 #889755 #939996 #945047 #951579 #954345 #9), 2016-02-04 esp. "Calc: Problem opening certain ODS files - Remove RPATH on some 3rd party bundled libs." does NOT fix this problem. (Set up as in comments 7 + 10)
I've the same crash with LO 5.1.2 So, back to 4.4.7.2 Pb occurs only with writer, when working with au document. I can't reproduce way to the crash. I Just noticed, th the document had a lot of formulas, and some of the were blanck. So I double click on the formula => The formula appears and then press ESC => Often but not always Crash. My documents use Graphite fonts If it can help
Interesting; looks like an event / ordering issue quite possibly. To move ahead with this - we will need a trace from: valgrind --num-callers=31 soffice.bin or somesuch - of course for a build with debugging symbols; sadly the builds here didn't have them which makes it rather hard to tackle this =) Thanks !
Created attachment 127276 [details] Valgrind traceback
I found this bug report when investigating near identical symptoms with LO 5.1.3 under OpenSuse Leap 42.1 Linux PHTCM1001 4.1.27-27-default #1 SMP PREEMPT Fri Jul 15 12:46:41 UTC 2016 (84ae57e) x86_64 x86_64 x86_64 GNU/Linux rpm -qa | grep office libreoffice-templates-en-3.3-15.6.noarch libreoffice-branding-upstream-5.1.3.2-8.1.noarch libreoffice-calc-extensions-5.1.3.2-8.1.x86_64 libreoffice-filters-optional-5.1.3.2-8.1.x86_64 patterns-openSUSE-kde_office-20150918-12.1.x86_64 libreoffice-l10n-en-5.1.3.2-8.1.noarch libreoffice-icon-theme-sifr-5.1.3.2-8.1.noarch patterns-openSUSE-office-20150918-12.1.x86_64 libreoffice-templates-labels-a4-1.0.1-12.1.noarch libreoffice-writer-5.1.3.2-8.1.x86_64 libreoffice-base-drivers-mysql-5.1.3.2-8.1.x86_64 libreoffice-icon-theme-breeze-5.1.3.2-8.1.noarch libreoffice-pyuno-5.1.3.2-8.1.x86_64 libreoffice-math-5.1.3.2-8.1.x86_64 I have a partial diagnosis and a cure. I generated a valgrind trace which pointed to "Invalid Read"s in a Python library. Starting LO with an empty PYTHONPATH cures the crash. So it seems that the problem was an interaction with one of the components - quickly narrowed down to /usr/local/lib/python2.7/site-packages and the file "setuptools.pth". -rw-r--r-- 1 root root 33 Sep 12 2012 setuptools.pth Rather incredibly stupidly I managed to nuke the file in the act of narrowing among the files in the directory. So I can't see the contents. D'oh. My guess was that this was a link to a directory which no longer exists. In any case it seems clear that (at least in my case) the cause was LO picking up bad data from the Python environment.
Extremely interesting analysis - thanks ! =) The valgrind trace is unfortunately not useful, since the build has no debuginfo installed - which is a shame ! thanks for generating that. With a new trace with debugging symbols we may be able to get further, and/or perhaps we can find a patch for our python that may avoid this crasher / memory corruption somehow. Thanks !
Keith: I chatted with Michael on IRC about getting debuginfo for openSUSE and he said: "you have to add the debuginfo repository and the updates repository too for some reason" I hope you can find them for Leap. I do remember some difficulty with Leap from another user :(
(In reply to Buovjaga from comment #21) > Keith: I chatted with Michael on IRC about getting debuginfo for openSUSE > and he said: "you have to add the debuginfo repository and the updates > repository too for some reason" > > I hope you can find them for Leap. I do remember some difficulty with Leap > from another user :( Leap Debug: http://download.opensuse.org/debug/distribution/leap/42.1/repo/oss/ Sincerely the "another user" PS: Persists with LibreOffice 5.1.3.2 10m0(Build:2) (thank god for LaTeX!) since the same type of crash also occurs with a few other programs, that seem to use the gtk/gnome graphics (FontForge -v 20150824, veracrypt graphic mode) I by now suspect some problem with the integration into Plasma (which has become a bit more stable those last 6 months)
The same error message occured for me on OpenSUSE Leap 42.1. After search around and realizing that a freshly created useraccount didn't have this problem it turned out to be caused by a set env "PYTHONPATH". unsetting that variabled fixed it.
Created attachment 127999 [details] Python site-package which causes LO to fail
Sorry about the delay with this. I was not yet able to get debugging symbol information. However I have managed to narrow down the cause a lot further, after recovering the "setuptools.pth" in my Python 2.7 local site-packages. This allowed me to identify the single Python package at the root of the crash. Skipping any more tedious details, the conclusion is If my installation of the Python package "enum" is in the PYTHONPATH, LO fails on startup with std::Bad_Alloc. If the installation of the Python package "enum" is NOT in PYTHONPATH, LO startup succeeds. I will upload a tarball containing the offending Python package. Perhaps others can try to see if adding this to your Pythonpath replicates the failure?
(In reply to Keith Refson from comment #25) > Sorry about the delay with this. I was not yet able to get debugging symbol > information. > > However I have managed to narrow down the cause a lot further, after > recovering the "setuptools.pth" in my Python 2.7 local site-packages. This > allowed me to identify the single Python package at the root of the crash. > > Skipping any more tedious details, the conclusion is > > If my installation of the Python package "enum" is in the PYTHONPATH, LO > fails on startup with std::Bad_Alloc. > > If the installation of the Python package "enum" is NOT in PYTHONPATH, LO > startup succeeds. > > I will upload a tarball containing the offending Python package. Perhaps > others can try to see if adding this to your Pythonpath replicates the > failure? As promising as your comments are I must say that n my setup, I can not replicate your solution. That is: 1) I have had NO PYTHONPATH set, 2) even after (temporarily) renaming the folder /usr/lib/python2.7/site-packages/enum/ LO crashe on startup as described earlier, viz.: ksmserver, kdeinit5 and kglobalaccel5 -- each with segmentation faults.
Adi - your symptoms seem different and point to a different bug. I see the same behaviour first reported, namely, LO will start up without any file. However any attempt to open a file opens up the sub-component window, but which immediately fails, displaying an error message window containing "std::bad_alloc". LO exits upon clicking the OK button. You reported that "LibreOffice crashes Plasma (and/or X) on opening any type of file " which is clearly different. I do not see that behaviour, and that is not what the original reporter stated either. I suggest that this is clearly a separate issue, and you should open a new bug report.
Let's set this to NEW per Keith's input.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Any update with a recent LO version (eg last stable one: 6.2.5)? On pc Debian x86-64 with master sources updated today I tried Keith's test with PYTHONPATH but failed to reproduce this. I did: - export PYTHONPATH=<site-packages directory>/site-packages - launch LO - open a docx => no crash also: - export PYTHONPATH=<site-packages directory>/site-packages/enum/enum.py - launch LO - open a docx => still no crash
Last stable LO version is now 6.3.4. Let's put this one to NEEDINFO waiting for feedback and brand new bt if it still crashes. Also, it might be specific to KDE, so it would be interesting someone gives a try with: export SAL_USE_VCLPLUGIN=gen soffice
Dear Thomas Schweikle, 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 INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/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 MassPing-NeedInfo-Ping
Dear Thomas Schweikle, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp