In this and all previous versions of LibreOffice I often experience a complete freeze: Frequent use of Ctrl+C and Ctrl+V Then none of the opened documents is accessible and I have to kill the programm in the task manager. Last changes are all lost. I experienced that often in the past and on different versions of windows and LibreOffice.
It would be really useful to get a stack trace of LibreOffice when it is in this state. There should be an 'soffice.bin' process you can attach wingdb to get that data from - with a trace we can start to fix it =) https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg Luckily there is ~no performance impact while you reproduce it. Thanks !
Created attachment 98699 [details] Artificially produced freeze with calc. Arificially produced freeze with calc. I'm looking forward to another one during "normal work".
Comment on attachment 98699 [details] Artificially produced freeze with calc. Artificially produced freeze with calc. I'm looking forward to another one during "normal work".
Looks like an out-of-memory allocating Columns. The 'ColEntry' stuff is obsolete these days; we use MDDS for column storage; please can you retry that with LibreOffice 4.2.4 ? my hope is that that will behave better, and at least we can fix it there. 4.1.x just dropped off the edge of support. I'd love to know what the easy reproducer is for this case though ! is it 'select all cells in a sheet and copy/paste' or something ? Thanks ! 00bce3ac 73dd872d e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58 00bce3e4 73def30f 00bce3f4 73dcc888 73dcc7ec MSVCR100!_CxxThrowException+0x48 00bce404 598a8749 000b4050 ea7e688b 00bce4c4 MSVCR100!operator new+0x7f 00bce438 598b43e4 0001680a 00000000 ea7e68df sclo!std::_Allocate<ColEntry>+0x28 00bce46c 598b44f8 0001680a 0b57e594 00bce490 sclo!std::vector<ColEntry,std::allocator<ColEntry> >::reserve+0x39 00bce47c 598b48a3 00000001 00bce4cc 0b57e594 sclo!std::vector<ColEntry,std::allocator<ColEntry> >::_Reserve+0x46 00bce490 598cbb9c 00bce4c4 0b57e568 0b57e594 sclo!std::vector<ColEntry,std::allocator<ColEntry> >::push_back+0x40 00bce4cc 598c5459 0bd34d50 0000f007 668522a0 sclo!ScColumn::Append+0x1e 00bce51c 598c5b8d 0bd34d50 0000f007 668522a0 sclo!ScColumn::SetCell+0x50 00bce534 598c8917 0bd34d50 0000f007 668522a0 sclo!ScColumn::Insert+0x14 00bce5c8 5999e3ea 00bce7b4 0000f003 0000f016 sclo!ScColumn::CopyFromClip+0x333 00bce630 59911a7b 00bce7b4 00000234 0000f003 sclo!ScTable::CopyFromClip+0x92 00bce6a8 59911e20 00bce7b4 00000234 0000f003 sclo!ScDocument::CopyBlockFromClip+0xce 00bce6ec 59912be3 00bce7b4 00000234 0000f003 sclo!ScDocument::CopyNonFilteredFromClip+0x10f 00bce7fc 59d4eaf6 00bce8d8 00bce880 0000087f sclo!ScDocument::CopyFromClip+0x345 00bceb8c 59ccc455 000008ff 0ba74ca0 00000000 sclo!ScViewFunc::PasteFromClip+0x1139 00bcebf8 59cc151b 0b6014b0 0b5fe748 00000001 sclo!ScClipUtil::PasteFromClipboard+0x12f 00bcf278 59cbd263 00bcf444 00bcf2d0 5d872a9e sclo!ScCellShell::ExecuteEdit+0x7cb
Really freeze in writer and calc. Not easy to debug because not crash, but freeze any session of LibreOffice and OpenOffice ! But it´s not all time. Almost time when using clipboard managers like ClipX on windows and other clipboard managers on Linux. If disable clipboard manager or paste using CTRL+SHIF+V (paste without formatting), freeze is rare.
Created attachment 101677 [details] WinDbg's session output after a "normal" LibreOffice crash. Crashs really do happen rarely. Finally today I got a "real" crash during my usual work. (I had to stop WinDbg with Debug/break. After that I could ask it for "!analyze -v".
This should be UNCONFIRMED.
(In reply to wotto from comment #6) > Crashs really do happen rarely. Finally today I got a "real" crash during my > usual work. (I had to stop WinDbg with Debug/break. After that I could ask > it for "!analyze -v". Sounds like legitimate work is being done here, and there's not much QA can do to help triage, so moving out of UNCONFIRMED -> NEW. (Devs: Feel free to RESOLVE this if there's no interesting activity on it; we can always revive it in the future)
Happens sometimes. I had it today with 4.3.5.2 when I cut text, inserted a comment and pasted that text with Ctrl+V. WinDbg showed "i18nsearchlo.dll".
*** Bug 87300 has been marked as a duplicate of this bug. ***
I have more or less the same problem. and it is happening since 3.x release. i made a bug post (https://bugs.freedesktop.org/show_bug.cgi?id=87300) but I closed it as duplicate after Timur warning.
(In reply to Timur from comment #9) > I had it today with LO 4.3.5.2 in Writer on Win7 x64, after I cut text, inserted a comment and pasted that text with Ctrl+V". I had another hang today, this time in Calc, same LO version 4.3.5.2, when I pasted a cell. Since it's Calc, I may also write to Bug 46406 but I'm not really sure. I cannot use an empty profile because this happens rarely. I think the only solution is that all of us who experience this use WinDbg all the time in hope to catch a hang. I have a question for wotto's WinDbg's session: was WinDbg run only after the hang and so this debug session is not very useful?
** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
on release 5.2 I have not experienced any more this problem
Great! Let's set to WFM.
I have this bug or Bug 46406 rather often, I'm now on 5.1.6 32-bit Windows. I've just had it with procdump on and there was no dump. So, I don't know how to find the cause, other than hope it's solved in some other bug, hopefully in 5.2. This is not WFM for me, but it doesn't make sense to open without any data.
I still have this with Writer 5.2.7.
I still have this with LO 5.3.7. Let's just hope it has sth. to do with Bug 114815.