User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 Build Identifier: Version: 5.0.6.3 Build ID: 00m0(Build:3) Locale: en-GB (en_GB.UTF-8) (provided by SUSE) When I save a larger presentation (500 slides, 45 MB) then the save bar moves to the end with 100% CPU load on one core. If all goes right a number of parallel threads is executed then (CPU monitor shows User, IO Wait, and System processes ) and finally the UI is refreshed. In the bad case, which happens, say, every 10th save attempt (could be every other save attempt on bad days) I don't see the parallel processes at the end. The UI is frozen then and I have to kill it forcefully. I saw this behavior in the 4.x.x versions already, even on Windows 8.1, where the behavior was even worse. Interestingly, I used to run SuSE 13.2 in VirtualBox and there the behavior was better. When I moved on to a native SuSE 13.2 installation I saw problems increasing again. Reproducible: Sometimes Steps to Reproduce: 1. Open large document 2. Do some (even minor) modifications 3. Save 4. Repeat until freeze is seen (about 10 times) Actual Results: UI frozen. Needs to be closed forcefully. The document needs to be recovered after the next start. The changes that were supposed to be saved are lost. Expected Results: Save file including changes done after last successful save. This bug looks similar to 100281 and 98750, but I hope I can provide some new information. SuSE Linux 13.2, Kernel 3.16.7-42-desktop, x86_64 => gdb reports a segmentation fault in the freeze case: [New Thread 0x7fffd28c5700 (LWP 25024)] [Thread 0x7fffd28c5700 (LWP 25024) exited] [New Thread 0x7fffd28c5700 (LWP 25025)] [Thread 0x7fffd28c5700 (LWP 25025) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffbadf2700 (LWP 24910)] 0x00007fffb40a7990 in ?? () (gdb) bt #0 0x00007fffb40a7990 in () #1 0x00007fffeeb3c705 in cppu::OWeakObject::release() () at /usr/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3 #2 0x00007fffeeadeb71 in cppu::PropertySetMixinImpl::Impl::setProperty(com::sun::star::uno::Reference<com::sun::star::uno::XInterface> const&, rtl::OUString const&, com::sun::star::uno::Any const&, bool, bool, short) const () at /usr/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3 #3 0x00007fffeeadf332 in cppu::PropertySetMixinImpl::setPropertyValue(rtl::OUString const&, com::sun::star::uno::Any const&) () at /usr/lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3 #4 0x00007ffff58bcbc7 in ZipOutputEntry::createBufferFile() () at /usr/lib64/libreoffice/program/libmergedlo.so #5 0x00007ffff58e63a2 in DeflateThread::doWork() () at /usr/lib64/libreoffice/program/libmergedlo.so #6 0x00007fffef08d66d in comphelper::ThreadPool::ThreadWorker::execute() () at /usr/lib64/libreoffice/program/libcomphelper.so #7 0x00007fffee22ce36 in salhelper::Thread::run() () at /usr/lib64/libreoffice/program/libuno_salhelpergcc3.so.3 #8 0x00007fffee22cffa in threadFunc() () at /usr/lib64/libreoffice/program/libuno_salhelpergcc3.so.3 #9 0x00007ffff41af127 in osl_thread_start_Impl() () at /usr/lib64/libreoffice/program/libuno_sal.so.3 #10 0x00007ffff34930a4 in start_thread (arg=0x7fffbadf2700) at pthread_create.c:309 #11 0x00007ffff3eb1cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Reset User Profile?Yes.
I cannot provide a sample presentation because it is all copyrighted material which must not become public. I could provide such an individual contributor given the recipient understands this restriction and promises to keep this presentation to himself/herself.
Changing it to NEW as the backtrace has been provided
Hello Gizze, Is it possible that you attach a complete backtrace https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace or a minimal document to reproduce the bug?
Created attachment 127722 [details] Backtrace produced with "soffice --backtrace"
I could only provide a sample file on a private basis outside this public bug tracking tool because it is subject to copyright. I can produce further traces if needed.
Created attachment 127990 [details] Backtrace produced with soffice --backtrace
Gizze: would be interesting to hear, if the hangs continue with LibreOffice 5.2.x. (I unpacked the gdbtrace.log and reattached. I don't know why our wiki advised to pack it. I changed the wiki)
(In reply to Buovjaga from comment #7) > Gizze: would be interesting to hear, if the hangs continue with LibreOffice > 5.2.x. > > (I unpacked the gdbtrace.log and reattached. I don't know why our wiki > advised to pack it. I changed the wiki) Thanks for this suggestion, Buovjaga. I did some further tests with LibreOffice 5.0.6.3: On an old 32-bit Pentium M machine (single threaded) with openSUSE 13.2 I was not able to reproduce the problem. With 64-bit openSUSE 13.2 on a virtual machine I saw no crashes in a configuration with just one logical CPU. I observed regular crashes in a configuration with four logical CPUs. Conclusion: Maybe this is a race condition among several processes. This goes in line with the observation that the saving process always crashes towards the end when multiple parallel processes run on separate (logical) CPUs. This is what I found with LibreOffice 5.2.2.2: No crashes seen with 64-bit openSUSE on a virtual machine even in a configuration with four logical CPUs No crashes seen with a 64-bit openSUSE bare bone installation on a four core CPU. Windows 8.1 Frequent crashes still. I don't care about Windows, though. I compiled this presentation on Linux. Maybe we are seeing yet another problem at this point. So this looks good so far. Let me continue my daily work with this setup and see how reliable this LibreOffice version works now.
Ok, I changed the OS field to Windows. You could get a backtrace with WinDbg: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg We should try and care about Windows as well ;)
Created attachment 128151 [details] Windows Backtrace Indeed, we should care about Windows as well if we care about LibreOffice. Note that I usually do not work on Windows. Therefore the problem at hand may be an interoperability issue different from the problem I had on Linux originally. Anyway, I created a Windows backtrace following the instructions on the "How to get a backtrace with WinDbg" page. The symbol resolution does not seem to work properly yet. If this backtrace is not good enough let me know and include some hints to improve its quality.
Created attachment 128181 [details] Debian Backtrace
I have the same problem with Version 5.2.2.2.0+ from the Jessie Backports under Debian 8.6. Impress hangs ALWAYS. For example, when I open a new document and am going to save it, Impress freezes. This bug can be reproduced and makes Impress completely useless. I did not have problems with former versions.
Not sure, how to proceed, but we seem to have a confirmation with bbugs's experience, so setting to NEW.
the stack trace in the description matches bug 94212 same for the one in comment #6 comment #8 is quite clever, yes this crash is a race comment #10 stack apparently shows an error-box being displayed, not sure what to make of that, maybe the race didn't cause a crash but some exception instead... comment #11 back-trace is useless, something killed soffice.bin before the stack could be obtained i think the multi-threaded zip problem reported by "Gizze" should be fixed in current 5.1 / 5.2 releases, so maybe "bbugs" is seeing a different bug, but hard to tell without a proper backtrace.
hello bbugs, could it be possible that you provide a backtrace with debugging symbols? You can download it from http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF-dbg/ and get the backtrace following https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace Setting the bug to NEEDINFO for the time being. Change it to NEW once the backtrace is provided
Bug 103108 could be the same issue.
(In reply to Michael Stahl from comment #14) > i think the multi-threaded zip problem reported by "Gizze" should be fixed > in current 5.1 / 5.2 releases, so maybe "bbugs" is seeing a different bug, > but hard to tell without a proper backtrace. Good news from my side: I have been working on Linux with 5.1 for a week now and I have not seen a single crash on save.
Resolving - as presumed fixed - is that ok Gizze - would love to know if it continues to work for you ? if other similar (or even different ;-) problems recur - it would be great to open new bugs for them and mark this one as 'See Also' if they're related. Thanks !
(In reply to Michael Meeks from comment #18) > Resolving - as presumed fixed - is that ok Gizze - would love to know if it > continues to work for you ? if other similar (or even different ;-) problems > recur - it would be great to open new bugs for them and mark this one as > 'See Also' if they're related. > > Thanks ! I have not seen a single crash on save on Linux ever since I went to version 5.1. So the Linux part of this can be closed from my side. That's what I cared about most, so this ticket could be closed. However, the Windows side does not seem to be clean yet, but that could be another issue (e.g. interoperability since I compiled the respective presentation on Linux). The Windows save operation seems to freeze earlier. So maybe it would be better to follow up on tickets related to the save operation which were submitted by Windows users. I am wondering, though, whether bbugs' observations should be handled further on this ticket. Thanks a lot for your support on this!
(In reply to Gizze from comment #19) > However, the Windows side does not seem to be clean yet, but that could be > another issue (e.g. interoperability since I compiled the respective > presentation on Linux). The Windows save operation seems to freeze earlier. > So maybe it would be better to follow up on tickets related to the save > operation which were submitted by Windows users. The Windows side can be followed up on in bug 103108.
(In reply to Aron Budea from comment #20) > (In reply to Gizze from comment #19) > > However, the Windows side does not seem to be clean yet, but that could be > > another issue (e.g. interoperability since I compiled the respective > > presentation on Linux). The Windows save operation seems to freeze earlier. > > So maybe it would be better to follow up on tickets related to the save > > operation which were submitted by Windows users. > > The Windows side can be followed up on in bug 103108. OK! Thanks again for all the support on this.