User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko Build Identifier: LibreOffice 5.0.1.2 whenever try to to save calc document its almost always crached 3rd or max4 time i lost my last acts and reopen calc reinput information and it goes crash again 3rd or 4th save time fatalerror. Reproducible: Always Steps to Reproduce: 1.have 2 documents open first ms xls format second my editing calc. 2.getting data from xls to calc as once to once colon copy. 3.its not crash until i try to save calc document but it everytime crashed 2nd 3rd or 4th save time and i lost my last input. Actual Results: its always crash so i could go on very little input so abuse [Information automatically included from LibreOffice] Locale: tr Module: SpreadsheetDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: yes i tyed 64 bit back to 32 bit version but this bug exist 32bit too i will go to install vers 4 i hope i can not see this bug there too. Reset User Profile?No
Please, rename your user profile and try again. https://wiki.documentfoundation.org/UserProfile Best regards. JBF
Created attachment 118460 [details] Fatal error whenever save 3rd time
Comment on attachment 118460 [details] Fatal error whenever save 3rd time tryed user profile reset its still continoue fatal error and always happen afer 3rd time to save or passed 5-6min later for the first save!!
how may i find and add debug info its always crash whenever save 3rd or 4th.
Created attachment 118473 [details] I got this dump from task manager after crash If need any other dump please tell it to me how can i achieve and so i could post back to you if this dump not good (got from task manager after crash). Because its always happen mostly after 3. or 4.th save calc crash and i lost last sesion.
Created attachment 118474 [details] I got this dump from task manager after crash part2
Created attachment 118475 [details] I got this dump from task manager after crash part3
Created attachment 118476 [details] I got this dump from task manager after crash part4
Created attachment 118477 [details] I got this dump from task manager after crash part5
Created attachment 118478 [details] I got this dump from task manager after crash part6
Created attachment 118479 [details] I got this dump from task manager after crash part7
Created attachment 118480 [details] I got this dump from task manager after crash part8
Created attachment 118481 [details] I got this dump from task manager after crash part9
Created attachment 118482 [details] I got this dump from task manager after crash part10latest
Created attachment 118491 [details] this document crash always dont know reson but crash not every document crach but could you please check this.
(In reply to spamkutu from comment #15) > Created attachment 118491 [details] > this document crash always dont know reson but crash No crash for me with LO 5.0.3.0+ under Ubuntu 15.04 x86-64 Opens fine and navigate through the sheets without problem. Changed random values and saved the file, did that 3 times, no crash. You should try on another computer if you can. Best regards. JBF
Cannot reproduce with 5.0.1.2 ID sestavení: 81898c9f5c0d43f3473ba111d7b351050be20261, win7
Did same experiments as JBF + messed around with filters. No crash. Perhaps uninstall LibO completely before reinstalling. Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit) Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: fi-FI (fi_FI)
(In reply to spamkutu from comment #15) > this document crash always dont know reson but crash (In reply to Jean-Baptiste Faure from comment #16) > > No crash for me with LO 5.0.3.0+ under Ubuntu 15.04 x86-64 (In reply to raal from comment #17) > Cannot reproduce with 5.0.1.2 > ID sestavení: 81898c9f5c0d43f3473ba111d7b351050be20261, win7 Still no repro, and it's been over a month. Spamkutu: Can you still reproduce these crashes with a current daily build of LibreOffice? http://dev-builds.libreoffice.org/daily/ Status -> NEEDINFO
I have had this problem since LO 5.0; has continued in each release since then, now in 5.0.3.2, still experiencing the problem. I experience this problem on Windows 7, Windows 8.1 and Linux Mint 17.2. I use 64-bit version on each OS. I either paste data into Calc (typically a column of 6 - 30 values) or type a few values in manually (students' scores for assignments/exercises/quizzes). After 3 - 8 saves, Calc will crash. All data I entered since the last successful save is simply lost. In the past (pre-LO 5.0) I would only save the file after a day's work; now I save the file after each and every update, because I never know when all my data (since the last save) will simply be lost. What further information can I supply to help here? (And if logs, etc. are needed, please provide information on how to access them in Windows and Linux!) Shall I set the status back to UNCONFIRMED?
(In reply to Raould from comment #20) > I have had this problem since LO 5.0; has continued in each release since > then, now in 5.0.3.2, still experiencing the problem. I experience this > problem on Windows 7, Windows 8.1 and Linux Mint 17.2. I use 64-bit version > on each OS. At the moment, this bug report is about MS-Windows. If you have the same crash on each OS while no one can replicate it on Linux, might be the sign of a different issue. That said, please answer the following questions: - Where the files are saved? locally or on a remote server? - Did you try to reinitialize your user profile? If you do not know how to do that, have a look at https://wiki.documentfoundation.org/UserProfile Best regards. JBF
For debugging: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace Note: the Linux debugging instructions will soon receive improvements (for simplicity).
Jean-Baptiste, Thank you for the response. The files I work with are saved locally. The directories where I keep the files I work on daily are Dropbox directories, thus shared with other systems, but are (also) physically stored on the local system. I have not tried to reinitialize my user profile. I will follow the directions provided (probably on Friday, two days from now). I did try more detailed tracking of updates and crashes yesterday; on Windows 7 I updated a file (mostly pasting numbers from Excel files, with a few manual inputs) and crashed twice - both times after 9 cycles of input, then save; some of the "input" the second time were conditional format rule changes. I applied the same updates to a copy of the file in Linux Mint as I worked on the first file; however, on the Linux side I had to copy from one LO Calc file to another, as I don't have Excel in Linux. I don't know if that is significant, but the Linux version did not crash. (This is the first time I've worked on these files in Linux since upgrading to 5.0.3.2).
Jean-Baptiste, I should have read the directions for reinitializing the user profile first - the process is very simple. I reinitialized my user profile on Windows 7 and Windows 8 yesterday, but have had the crashes on both systems since then. Beluga, I did not have time to look into the information on logging, but will get to that tomorrow (Friday, 13 Nov 2015). Thank you both!
In order to produce the various debugging logs in Linux, I need to install the debugging packages libreoffice-dbg. Where would I be able to obtain that? (It is not available for 5.0.3.2 in the LinuxMint repositories, only 4.4.3) Thanks!
Created attachment 120531 [details] Backtrace from Windows 8.1 for crash on save with LO 5.0.3.2 Posting first backtrace file, this one from Windows 8.1.
Created attachment 120532 [details] Backtrace from Windows 7 for crash on save with LO 5.0.3.2
Created attachment 120533 [details] A second backtrace from Windows 7 for crash on save with LO 5.0.3.2
(In reply to spamkutu from comment #0) > Steps to Reproduce: > 1.have 2 documents open first ms xls format second my editing calc. > 2.getting data from xls to calc as once to once colon copy. > 3.its not crash until i try to save calc document but it everytime crashed > 2nd 3rd or 4th save time and i lost my last input. > Actual Results: > its always crash so i could go on very little input so abuse Hello, please could you post xls file too (point 1)? I see only .ods file in attachments. Do you have these two files open in LO or xls file is opened in ms excel? Thanks
Is there any progress on this? This prevents LibreOffice from being a trustworthy application - one can never tell if one is going to lose their data or not. Thanks in advance for any information!
Raould: from the backtraces it seems to be related to the VCL graphical toolkit. Could you test with version 5.0.4, if you can still reproduce the crash? Or even 5.1, which should be released this week.
I can confirm the problem still exists with 5.0.4! I am still experiencing it in both Windows 7 and Windows 10 (I upgraded my 8.1 to 10 since my last note).
(In reply to Raould from comment #32) > I can confirm the problem still exists with 5.0.4! I am still experiencing > it in both Windows 7 and Windows 10 (I upgraded my 8.1 to 10 since my last > note). And is OpenGL disabled, when you go to see Tools - Options - LibO - View - Use OpenGL for all rendering
Beluga, Yes, OpenGL is disabled (Use OpenGL for all rendering is NOT checked).
Beluga, I have installed LO 5.1.0.3 on Windows 7, and am still experiencing the problem.
backtraces look interesting - can we get one from a dbgutil build ? I don't really trust the stack unwind without debugging symbols ? =) Thanks for reporting ! also - 5.0.x is about to drop out of support - it would be great to get a trace from a 5.1.x build with debuginfo. Thanks ! =)
(In reply to Michael Meeks from comment #36) > backtraces look interesting - can we get one from a dbgutil build ? I don't > really trust the stack unwind without debugging symbols ? =) Thanks for > reporting ! also - 5.0.x is about to drop out of support - it would be great > to get a trace from a 5.1.x build with debuginfo. Thanks ! =) I am not sure, which Tinderbox for 5.1 dailies is done with debug info, but at least TB39 building 5.2 has them: http://dev-builds.libreoffice.org/daily/master/win-x86@39/current/ The process is the same, like described in the wiki article. Just make sure your symbol path is like this: CACHE*C:\symbols;SRV*http://dev-builds.libreoffice.org/daily/master/Win-x86@39/symbols;SRV*http://dev-downloads.libreoffice.org/symstore/symbols;SRV*http://msdl.microsoft.com/download/symbols
As a seen the problem only occur on windows (all kind windows 7 to 10) version with LO 5 and dosen't matter 32bit or 64bit version nor dosen't related with profile reset. I have no idea if it caused by glide drive but it must change atleast windows 7 to 10 drivers are very different (windows 8-10 driver very closed but). Yes Its happen whenever try to save calc document but not always in first time at second, third, or fourth time almost absolut crash happens and with crashed recovery tool whenever start you could not have that lost data terrible. If times pass alot sometimes its happens on first save to i think may be that caused by auto save releated 1-2 time before crash happens like normal save procdures but i am not sure on this subjet. Hopply that dosen't existed on linux version and use LO in linux emulator its slow but sure my datas protected. For all day habitual jobs i still use LO on windows but not for important task and not for often changes task which dosen't have backup sides.
Created attachment 122550 [details] Backtrace from Windows 7 for crash on save with LO 5.1.0.3
Michael, I just attached a backtrace from 5.1.0.3 on Windows 7.
(In reply to Raould from comment #40) > Michael, > > I just attached a backtrace from 5.1.0.3 on Windows 7. Could you give a try to a build of 5.2 from Tinderbox no. 39? 5.1 release build does not have the debug symbols. 5.2 will install separately, so you don't have to do any special tweaks.
Beluga, I will do so - I just can't seem to find any information on how to obtain a Tinderbox build. The information I've found so far is aimed at developers concerned creating a build. How do I get the Tinderbox version?
(In reply to Raould from comment #42) > Beluga, > > I will do so - I just can't seem to find any information on how to obtain a > Tinderbox build. The information I've found so far is aimed at developers > concerned creating a build. > > How do I get the Tinderbox version? I mentioned it in comment 37 :) http://dev-builds.libreoffice.org/daily/master/win-x86@39/current/
<sigh> You did indeed! My apologies. Backtrace coming up...
Saving a file in the Tinderbox version of 5.2 takes VERY long. Would this be an effect of it being a Tinderbox build, or is this likely to be a bug in LO 5.2? (Also, the keyboard shortcut for "Paste Special" in the right-click menu for a cell has been changed in this build, from "a" to "s" - hopefully this will not happen in the Production version? Why would someone change that after over what, over 10 years? I end up doing it wrong every time... habits are hard to break!) It is also taking a VERY long time for this version to crash... usually happens after 3-7 saves; now on my 30th save and still no crash.
With the 5.2 Dev version I am not getting the same crashes, but the program hangs - it sits with the toolbars grayed out (in the window I was saving), and I cannot enter data/click with mouse anywhere in that window or any other window of LO that I have open (I normally work with 2 files open). How do I get a backtrace in this situation?
The 5.2 version has hung several times now - I don't know how to save a backtrace in that case, so have had to kill it and start over.
On Windows 7 x86 This no crash on 4.4.7.2 This crash since the 5.0.0.0 dev version. I try on 5.0.0.1, 5.0.5.2 and this is crash anyway.
@Erack - thought you might be interested at looking at the new debug backtrace.
I can't make anything of it. The only thing to see is that during save some error box popped up and there under the ButtonDialog dtor when disposing stuff the process went astray. 00bde7b4 10abf5de 62ddff5e 00000000 1f3900a8 mergedlo!vcl::Window::dispose+0xb54 00bde7dc 10a2789e 62ddf092 19930522 1f38fee0 mergedlo!SystemWindow::dispose+0xbe 00bde810 10a261e8 62ddf0ba 19930522 00000000 mergedlo!ButtonDialog::dispose+0xce 00bde838 612197f2 19930522 00000000 00bde858 mergedlo!ButtonDialog::~ButtonDialog+0x48 00bdf384 10a9b1cd 00000000 02100000 00000000 MSVCR120!_NLG_Return 00bdf3bc 0fb54f72 00000000 02100000 00000000 mergedlo!ErrorBox::ErrorBox+0x5d 00bdf3f0 100a752c 00bdf440 00bdf444 00bdf458 mergedlo!VclPtr<ErrorBox>::Create<vcl::Window * &,__int64 &,rtl::OUString &>+0x62 00bdf46c 1087e745 00000000 00001101 00bdf4a8 mergedlo!aWndFunc+0x22c 00bdf4b8 1087e44d 00000c10 0000ffff 00000000 mergedlo!ErrorHandler::HandleError_Impl+0x2c5 00bdf4ec 0fd5a1e2 00000c10 0000ffff 30e4e380 mergedlo!ErrorHandler::HandleError+0x4d 00bdf870 0fd5c3ae 00000c10 00bdf898 0fc336ee mergedlo!SfxObjectShell::ExecFile_Impl+0x1482 00bdf87c 0fc336ee 15b34b48 09675698 0c57295c mergedlo!SfxStubSfxObjectShellExecFile_Impl+0xe 00bdf898 52b0efaf 09675698 00001581 00000000 mergedlo!SfxShell::ExecuteSlot+0x4e 00bdf8ac 52b05aee 09675698 00bdf908 0fc1ff5c sclo!ScTabViewShell::ExecuteSave+0x3f A real backtrace including symbols and a detailed step by step description of how to reproduce the crash might help. As I see it Calc isn't involved other than it triggered saving the document.
It seems a lot like an issue not related to LibO at all. The Dropbox was mentioned. Is it possible that Dropbox reads/writes the during the save and causes the crash? (Close or uninstall it to see if it makes the difference) Is there an antivirus or any other background program running which could cause it? Can you replicate the issue on a clean install of Windows, maybe in virtual machine (virtualbox)?
Mahfiaz, this problem started occurring after upgrading to LO 5.0 - no other changes to my Windows set-up at the time (Dropbox, anti-virus, etc). This occurred on two different machines, one running Windows 8.1, the other, Windows 10. Eike, I was told by Buovjaga (see 2016-02-12 message) that 5.1 does not have the debug symbols, and asked to use a build of 5.2 from Tinderbox no. 39. Unfortunately, that kept hanging, thus I never got a backtrace. Is there some other way to get that? Thanks!
(In reply to Raould from comment #52) > Eike, I was told by Buovjaga (see 2016-02-12 message) that 5.1 does not have > the debug symbols, and asked to use a build of 5.2 from Tinderbox no. 39. > Unfortunately, that kept hanging, thus I never got a backtrace. Is there > some other way to get that? Maybe try a newer build from TB39 later. Unfortunately, TB39 seems to be having a problem and no builds are available currently :( An other way would be for your to compile 5.2 yourself with --enable-debug, --enable-dbgutil or --enable-symbols options, but it can be a bit overwhelming, if you don't have experience with compiling software on Windows. You have to install Visual Studio and a lot of other stuff. For reference: https://wiki.documentfoundation.org/Development/lode
Just to say that I have this problem also with Writer doc with the 5 versions. I have a Windows 64 bits but LibO 32 bits works a bit better for me than the 64 bits version. Take your time to fix it...
(In reply to Ysabeau from comment #54) > Just to say that I have this problem also with Writer doc with the 5 > versions. I have a Windows 64 bits but LibO 32 bits works a bit better for > me than the 64 bits version. > Take your time to fix it... It would help a lot, if you got a backtrace with this debug build: http://dev-builds.libreoffice.org/daily/master/Win-x86@39/current/ You should of course first test, if the 5.2 build crashes.. Here are bt instructions once more: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg
Arnaud Versini committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2e1a724c2029783e84d7c508c6010afac0d6d10f Try to fix tdf#93967 by using VclPtr to keep the window alive It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I apply this patch on a LO 5-0-5. And the bug still be there. I joint the execution trace and backtrace in the document Execution_and_backtrace_crash_on_save_LO_5-0-5_20160425.odt The class where WinDgb stop is the \vcl\source\window\window.cxx on the line while ( pSysWin->mpWindowImpl->mpFrameData->mpNextFrame.get() != this )
Created attachment 124620 [details] Execution and backtrace after pacth add
An other way to solve this bug. While a debug execution on LO 5-0-5, the crash appeard on the xml export traietement. For the momeent, the most close method when bug appear is in \editeng\source\uno\unotext.cxx uno::Reference< container::XEnumeration > SAL_CALL SvxUnoTextBase::createEnumeration() the line SetSelection( aSelection );
Created attachment 124625 [details] Trace_WHEN_SAL_INFO_ACTIVED
An other trace of the bug reproduction. After actived SAL_INFO debug https://bugs.documentfoundation.org/attachment.cgi?id=124620
Alexis, please add all backtrace data in simple text files and comments in comments only. Did the commit changed the backtrace ? It seems that I fixed the too early delete but not the crash in the destructor. Could you please send us the complete backtrace ? I set this bug to NEW since some people on french list confirmed the issue.
Created attachment 124638 [details] Full BackTrace LO 5-0-5 with patch 2e1a724c2029783e84d7c508c6010afac0d6d10f
I apologize for send backtrace on comment.
Hi, The real problem is inside vcl::Window::ImplInit can't create the SalFrame, throw an exception and this exception leads to a crash. Perhaps we can remove this check, can't do anything else than crash during destructor if this exception is thrown. The exception throwing is here : http://opengrok.libreoffice.org/xref/core/vcl/source/window/window.cxx#986
I did a bibisect and this patch resolves the issue on master : https://gerrit.libreoffice.org/#/c/20274/ .
Backport proposed on 5.1
Big thanks to Markus for this patch, Alexis could you check if https://cgit.freedesktop.org/libreoffice/core/commit/?id=fc29ace3438eea09afe3ddbb5118458cbb531b06 solves the issue on 5.0 and 5.1 ? Thanks
Hi, The patch solves the issue on LO 5-0-5. The build of LO 5-1 with the same patch is in progress. Best regards Alexis
Hi, The LO 5-1 build crash. Because there isn't emum type ScHeaderFooterPart declaration. ScHeaderFooterPart is use in class "textuno.hxx / fielduno.cxx / textuno.cxx" Best regards. Alexis
(In reply to Alexis PAQUIN from comment #70) > Because there isn't emum type ScHeaderFooterPart declaration. You need to backport the patch to the structures/defines that were used in older branches, respectively resolve merge conflicts manually. But apparently you must have done that already for the 5-0 branch if that built. Likely similar changes are necessary for 5-1
Hey ! The patch solve the issues on 5.1 :) but with some adjustement. The modification are on the class (textuno.hxx, textuno.cxx and fileduno.cxx). How can we do to modify the patch, do you want the modify class files or just the modification for each ? Best regards
@Alexis: I don't quite understand, please submit the entire patch as you modified it for the 5-1 branch to gerrit for review.
Alexis, is there any trouble during the fix ? You only need to backport the correction.
@Arnaud No, nothing wrong append after the backport fix. But like i say on comment #72, to build LO 5-0 or 5-1, some other backport are needed. Despite this, the fix is great ! I try to push / modify the patch https://cgit.freedesktop.org/libreoffice/core/commit/?id=fc29ace3438eea09afe3ddbb5118458cbb531b06 but i didn't succes to push my modification (some trailing space errors) :(
'needsConfirmationAdvise' is only used for unconfirmed bugs. Removing it from this bug. [NinjaEdit]
Markus' patch is in -5-2: commit fc29ace3438eea09afe3ddbb5118458cbb531b06 Author: Markus Mohrhard <markus.mohrhard@googlemail.com> Date: Wed May 18 02:47:01 2016 +0200 better fix for memory leak around calc header-footer UNO objects 5-0 is end of life; 5-1 could use a back-port; I back-ported Markus' improved fix manually and pushed to CI here for build testing: https://gerrit.libreoffice.org/29542 Would love to close this =)
Back-ported to -5-1 and closed. Thanks !
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=052f98d0b1a6b0607069f0a50d4e03fcd4a1d52a&h=libreoffice-5-1 tdf#93967 - better fix for leak around calc header-footer UNO objects It will be available in 5.1.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.