Created attachment 122966 [details] sample file that crashes LO Draw Draw crashes without any message when I open a file created in an older Libre Office version (3.6). The file still opens fine with that version. I have more than one such file. Sample file attached.
Unconfirmed with v5.0.5.2 under ubuntu 14.04 x64. Unconfirmed with v5.1.1.1 under ubuntu 14.04 x64. Confirmed with v5.1.1.1 under windows 10 x64. Seems like a windows only problem ?!
Took a look. The document is made of too many CustomShapes which allocate too many SdrOutliners which create too many VirtualDevices. This is probably double to bug 93994. The solution there was to flush UNO API implementations of SdrObjCustomShape at end of page load (SdXMLDrawPageContext::EndElement()). This does not work here since it's a single page. What will/should work is a win 64bit version of LO. I will take a 2nd look why all these SdrOutliners are created - there must be a better way, it's blocking ressources massively. CustomShapes are and will be used in huge amounts in the future, it cannot be that one per CustomShape gets created, plus one VirtualDevice.
Crashes on win32 when 4921 SdrOutliner and VirtualDevice are created, in VirtualDevice::ImplInitVirDev. A good starting point is SdrOutlinerCache::createOutliner.
Debugged throgh that stuff again, but found no goood solution. CustomShapes (and the doc has thousands of them) need much more ressources then the builtin shapes need (factor 100?), but these are no longer available to the normal user, so they create docs like this one. In principle, VustomShapes are the better shapes, but when hiding the old ones they would first have to be optimized/reworked to get some speed and need less ressources. For now, I would suggest to do the flush of SdrOutliners/VirtualDevices durling load not when the page is loaded, but after each single CustomShape is loaded. Experimentally added this change, and can load the file. The same problem may surface again at runtime when someone edits 5000 CustomShapes, aka activate, text and other changes. That may again create these SdrOutliners/VirtualDevices and let them live probably. Thinking about possibilities...
Added flush to SdXMLCustomShapeContext::EndElement() and execution to SvxCustomShape::setPropertyValue, removed the page oriented stuff. Still more than one SdrOutliner gets created. Overhauled SdrOutlinerCache to handle more than one cached of each type, one is used for this bugdoc, 303 for the bugdoc from the older task (see comment 2). Also checked if 64bit win version could load the bugdoc, it can not. This shows that it is a ressource problem (probably VirtualDevices) and the patch is also needed for the 64bit version. It even crashes on the 2nd try to load...
Preparing patch. With the overhauled SdrOutlinerCache the SdrOutliner get better buffered, too. The cache has the same lifetime as the document, so should work well. Interestingly access to all active SdrOutliner's is taken in svgexport (SVGFilter::implExport) which is a hack and leads to make that info globally available at SdrModel, including to remember the 'active' (non-cached) outliners, argh.
Patch on gerrit.
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e6adb3e8b4de3c0f78d249b83de19b849ef65b59 tdf#98163 Flush ressources at CustomShapes during import 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.
Using nightly build libreoffice-5-1~2016-05-10_08.43.03_LibreOfficeDev_5.1.4.0.0_Win_x86_en-US_de_ar_ja_ru_qtz.msi 10-May-2016 12:02 146M Draw doesn't crash immediately but it still doesn't open the document.
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea0951bcc0d66db288e4723e3147a04ef47eca50&h=libreoffice-5-1 tdf#98163 Flush ressources at CustomShapes during import It will be available in 5.1.4. 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.
No crash anymore with v5.1.4.1 under windows 10 x64.
The file can be opened in LO 5.1.4. Thanks! However, it crashes on save. This is still not 100% fixed.
No problem with 5.2, neither on loading nor saving. Someone running 5.1.4 should double-check comment 12. Version: 5.2.0.3 Build ID: 7dbd85f5a18cfeaf6801c594fc43a5edadc2df0c CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; Locale: de-DE (en_US.UTF-8)
I downloaded 5.2.04 And it still crashes when saving. I let it send a crash report to LO. Computer config is Win 7x64.
Created attachment 126526 [details] LO 5.2.0.4 crash when saving Screenshot showing LO Draw crashing when trying to save the file uploaded in the initial bug report.
I cannot repro crash on open or save with master 5.4+ 32-bit on W7-x64. I was able to repro crash on save with 5.3.0.1. Since there was fix here, I'll close as Fixed. Feel free to reopen, but only in case of testing that will make clear when crash is made.