Problem description: Draw Hangs/Freezes or Crashes when attempting to load the example Microsoft Lync Server 2010 Edge Topology files. Steps to reproduce: 1. Start LibreOffice 2.Select 'Open' 3. Dubbel click (one of) the visio sample files Current behavior: Draw either Freezes/Hangs (becomes unrepsonsive), or crashes with the message 'LibreOffice has stopped working. Close the program'. Expected behavior: A import of the visio file in Draw. Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20100101 Firefox/13.0
Uploaded the example visio files to the location mentioned in 'URL' in the bug report.
What I see here is that the files are a mess to render. They have several issues: 1) A file of 9 MB is quite slow to parse for us, since the content of the Visio file is compressed with a custom compression and we have to uncompress them into memory first before being able to parse it. 2) The files have a fair amount of NURBS. There is no NURBS primitive in ODG, or SVG. Instead of approximating them using bezier cubic segments, we approximate them with 200 lines for each two knots. Some of the rendering will be faster once we change this approach. And I will not mind a help of someone who has an experience with that. "The NURBS Book" is a good source of ideas how to do it. There is a workaround if you are interested for the while: disable antialiasing in Draw and it will render faster, albeit it will not be as nice as it could.
Created attachment 62789 [details] Bug 50868 - WinDbg session Confirmed with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Crash while opening Lync_Server_2010_Edge_ScaledConsolidated_DNSLB_Topology.vsd. Attached full WinDbg session with mini dump file loaded generated by procdump soffice.bin -h.
Created attachment 62791 [details] Bug 50868 - WinDbg session - HLB_Topology.vsd Confirmed with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Crash while opening Lync_Server_2010_Edge_ScaledConsolidated_HLB_Topology.vsd. Attached full WinDbg session with mini dump file loaded generated by procdump soffice.bin -h.
Created attachment 62792 [details] Bug 50868 - WinDbg session Consolidated_Topology.vsd Confirmed with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Crash while opening Lync_Server_2010_Edge_SingleConsolidated_Topology.vsd. Attached full WinDbg session with mini dump file loaded generated by procdump soffice.bin -h.
OK, I see the crash and have an idea where it comes from. Will try to fix both libwpd and libvisio for 3.5.5.
Fridrich Štrba committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7575ebe35f6af1cc58e95a804087e7c1e0f06eee Fix potential further crashes like the one in fdo#50868
Fridrich Å trba committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=214c3b9002944ff5d05e249051e45f135e1b4943&g=libreoffice-3-6 Fix potential further crashes like the one in fdo#50868 It will be available in LibreOffice 3.6.
Just for the completion, this patch also was pushed into master and libreoffice-3-6 branch. I verified on windows that before the patch, LibreOffice was crashing, and that it is not crashing with it anymore. http://cgit.freedesktop.org/libreoffice/core/commit/?id=e71749a089fa3e6463b80413b638f7dc32921a07
Just for information, on Pc Debian x86-64 with master sources updated today, I got no crash for each of the 3 files (normal with the Fridrich's fix :-) ) but I noticed lots of these 3 types of logs : warn:legacy.tools:13399:1:/home/julien/compile-libreoffice/libo/sfx2/source/dialog/filtergrouping.cxx:371: ReferToFilterEntry::operator(): already have an element for this name! warn:legacy.osl:13399:1:/home/julien/compile-libreoffice/libo/svx/source/sdr/contact/viewcontactofsdrpathobj.cxx:70: PolyPolygon object without geometry detected, this should not be created (!) warn:legacy.tools:13399:1:/home/julien/compile-libreoffice/libo/sfx2/source/dialog/filtergrouping.cxx:371: ReferToFilterEntry::operator(): already have an element for this name! I don't know if it's important or not, again, just for info.
Fridrich Å trba committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ee606fd51b8975aa67a29dd778d67eb7dd247a2c&g=libreoffice-3-5 Fix crash from fdo#50868 It will be available in LibreOffice 3.5.5.
Fridrich Å trba committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a6ae36d10d08161d81a3d3f8593d8d543daaef13&g=libreoffice-3-5 Fix potential further crashes like the one in fdo#50868 It will be available in LibreOffice 3.5.5.
Is it fixed now?
(In reply to comment #13) > Is it fixed now? I tried opening the files with master 'master~2012-07-14_00.31.17_LibO-Dev_3.7.0.0.alpha0_Win_x86_install_en-US.msi'. Although I do not have a crash, libreoffice does seem to become unresponsive/freeze/hang. The window title bar changes to "LODev (Not Responding)" after a few seconds. I waited for more than a full minute after that with each file, but the file still hasnt opened at that point. Even if the files do open at some point, I guess it will still at least appear that the program is freezing to the average user.
I can open all of the attached three VSD with LO draw 3.6rc1. It takes some time (~3 minutes on my laptop), but doesn't hang or crash. Fridrich, some type of the progress bar would be nice to have for such cases. There is a space for improvements, for these particular files better handling of NURBSes could be the key. I believe initial crash/freeze is fixed.
(In reply to comment #15) > I believe initial crash/freeze is fixed. Yes, there is no longer any real/actual freeze/hang (or crash). If I wait long enough, the files do eventually open.
Fridrich, do we need an enhancement request(s)? We could probably link one to this bug report as a source of stress-testing samples.
(In reply to comment #17) > Fridrich, do we need an enhancement request(s)? > > We could probably link one to this bug report as a source of stress-testing > samples. That would be a really good idea. However, this might require storing the visio files in another, permanent location, as I probably cannot keep them stored in the URL listed for ever. And as we are talking about 9MB files here (about 6MB compressed), adding them as an attachment to this bug report is not really an option either.
There's a link about files bigger than 3MB, see here: http://wiki.documentfoundation.org/QA/Bugzilla-Attachments
Uploaded files to the wiki, and changed URL accordingly.
We need exact and correct target information for automated lists in Wiki and LibO Web Site.