Bug Hunting Session
Bug 98163 - FILEOPEN Draw crashes when opening file created in LO3.6
Summary: FILEOPEN Draw crashes when opening file created in LO3.6
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Armin Le Grand
URL:
Whiteboard: target:5.2.0 target:5.1.4
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-24 21:41 UTC by ben.radu
Modified: 2017-02-07 09:50 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
sample file that crashes LO Draw (35.61 KB, application/vnd.oasis.opendocument.graphics)
2016-02-24 21:41 UTC, ben.radu
Details
LO 5.2.0.4 crash when saving (100.95 KB, image/png)
2016-08-02 19:43 UTC, ben.radu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ben.radu 2016-02-24 21:41:19 UTC
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.
Comment 1 MM 2016-02-24 22:38:40 UTC
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 ?!
Comment 2 Armin Le Grand 2016-04-22 10:47:25 UTC
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.
Comment 3 Armin Le Grand 2016-04-22 10:55:14 UTC
Crashes on win32 when 4921 SdrOutliner and VirtualDevice are created, in VirtualDevice::ImplInitVirDev. A good starting point is SdrOutlinerCache::createOutliner.
Comment 4 Armin Le Grand 2016-04-22 14:23:12 UTC
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...
Comment 5 Armin Le Grand 2016-04-22 15:48:56 UTC
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...
Comment 6 Armin Le Grand 2016-04-22 15:52:36 UTC
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.
Comment 7 Armin Le Grand 2016-04-22 15:58:17 UTC
Patch on gerrit.
Comment 8 Commit Notification 2016-04-26 10:38:57 UTC
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.
Comment 9 ben.radu 2016-05-10 16:59:56 UTC
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.
Comment 10 Commit Notification 2016-05-11 12:56:54 UTC
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.
Comment 11 MM 2016-06-14 20:59:13 UTC
No crash anymore with v5.1.4.1 under windows 10 x64.
Comment 12 ben.radu 2016-07-29 19:42:37 UTC
The file can be opened in LO 5.1.4. Thanks! However, it crashes on save. This is still not 100% fixed.
Comment 13 Heiko Tietze 2016-07-30 07:48:36 UTC
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)
Comment 14 ben.radu 2016-08-02 19:42:12 UTC
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.
Comment 15 ben.radu 2016-08-02 19:43:47 UTC
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.
Comment 16 Timur 2017-02-07 09:50:28 UTC
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.