Created attachment 75625 [details] one of the files that cannot be opened anymore - draw crashes immediately trying to open it. Problem description: A drawing that was created and saved in this version of LO Draw cannoit be opened again after saving it. Steps to reproduce: 1. Create New drawing 2. Fill it with elements (sorry don't know what exactly makes the problem) 3. Save it, Close Draw 4. Try to load the saved document Current behavior: There is no error - draw loads, you get a ver fast glimpse of a window trying to open that disappears immediately without an error Expected behavior: Open the drawing and be able to see and work with it Operating System: Windows 7 Version: 4.0.0.3 release
More or less [Reproducible] with Server Installation of "LibO 4.0.1.1+ - German UI / German Locale [Build ID: 2c0c17a6e4bee0ee28131ea4bdc47edc700d659)]" {tinderbox: @6, pull time 2013-02-1920:00(?)} on German WIN7 Home Premium (64bit) with newly created user profile ….\LODev\4\: File will not be opened, nothing happens when I try to open reporter's sample from LibO start Center File Dialog Same FILEOPEN effect with 4.0.0.3 FILEOPEN Works fine with 3.6.5 That's a little strange. Reporter's sample is valid ODF 1.2 due to <http://odf-validator2.rhcloud.com/odf-validator2/>, so LibO should be able to open it. I saved the document from 3.6.5 as strict 1.2, compatible and extended, all 3 opened fine with 4.0.1.1 and 4.0.0.3, and documents saved from 4.0.0.3 in the same mode opened fine in 4.0.0.3 again. I found out that in my documents saved from 3.6.5 3 three .svg pictures are missing in "pictures" sub folder (because of that all my documents have 423 kB instead of 469 kB), no idea whether that is related to the problem. May be we should open a second Bug concerning the FILESAVE problem? @Andreas Balg: Do these results bring up any ideas concerning the reasons? Can you attach the latest version of the document what can be opened with LibO 4.0.0.3 and an instruction how to created the damaged one?
Created attachment 75628 [details] .svg files used to create the document Unfortunately I cannot provide a former working revision of the document - I created it and tried to open it again after saving and it crashed. No idea which change finally caused it to fail but it's true that I added some .svg graphics from openclipart.org as well as one or two I created/edited in Inkscape (latest 0.48.4) - I could give those missing .svg files to you. I attached the svg files used in this document for you. Hope that 'll help in any way.
I did some tests with a document based on reporter's sample, saved from LibO 3.6.5, with added .svg from att. 2013-02-27 11:54 UTC, Andreas Balg. I can not reproduce the FILESAVE problem. But the fileopen problem should be checked as long as we do not know what happens. Reporter's sample can't be opened with AOOo 3.4.1, either. LibO 3.4.5 and LibO 3.3.3 open the document without problems (others not tested). Currently only normal priority. @Andreas Balg: Please open a separate Bug for the FILESAVE problem if you can make it reproducible (and/or more documents are affected) and leave a comment here. @Radek: Please add Witeboard tag “bibisectrequest” if you think that a bibisect result can ease your work. Please change Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf.
I can confirm this behavior using Linux Mint 14 x64. See bibisect output
Created attachment 75638 [details] bibisect40 log
Created attachment 76474 [details] diff between flat odf exports So - a great technique with this kind of bug is to save as flat-odf, then you can diff -u -w between versions to see what exactly changed. I attach such a sample diff; things like: </style:style> <style:style style:name="P1" style:family="paragraph"> - <style:text-properties fo:font-size="9pt" style:font-size-asian="18pt" style:font-size-complex="18pt"/> - </style:style> - <style:style style:name="T1" style:family="text"> - <style:text-properties fo:font-size="9pt" style:font-size-asian="18pt" style:font-size-complex="18pt"/> + <style:chart-properties/> </style:style> + <style:style style:name="T1" style:family="text"/> <text:list-style style:name="L1"> <text:list-level-style-bullet text:level="1" text:bullet-char="●"> <style:list-level-properties/> Look rather suspicious - this is from before -> after. Why are T1 and P1 much empty styles, missing fo:font-size="9" in this new export ? - most odd.
terribly sorry - comment in wrong bug ;-) ignore me above.
Interestingly, it is the presence of the OLE objects that causes the grief; that (it seems) clobbers the PropertyMap used for serializing the text objects: which is most odd. Still digging ...
and again a comment in the wrong bug - sorry pardon.
No crash on open for me in master / 4.1 and the document looks nicely rendered - it does crash for my 4.0.4 rc1 install - so apparently we need to back-port some fix here.
review for 4.0: https://gerrit.libreoffice.org/4982 *** This bug has been marked as a duplicate of bug 60075 ***