I have a 35 Mb .odp file produced with LO 4.1.4. After upgrading to 4.2.0.4, no way to open it: Impress freezes at about 50% of "Load Document". I have uninstalled 4.2.0.4 and reinstalled 4.1.4: everything works fine again. I can provide the file on request, I do not think it is possible to upload a 35 Mb file here and in any case I would not like to have it available to the whole planet Earth.
Hm having the file would be crucial. Can you replace sensitive information and try to upload the file on some dropbox or other hosting service?
Not really sensitive information but work in progress (public presentation for a general public conference, the text is in French). I can upload to a server for a short period and I can remove it once you have downloaded (I get info when the file is downloaded). Would that be OK?
Confirmed on two more PCs: one Win7 32b French and one Win8.1 64b Japanese. I can provide the file.
Hi, Unless you upload a copy of your file, we won't be able to reproduce the freeze and to confirm the bug. So I set it on need info until we got the file - Sophie
You can download the file from the following link https://filex.univ-lorraine.fr/get?k=JX7D0piHlyHfQeyti1f Available only for a few days. I would like to remove it once you've got it, unless it has to remain available for different developers to check the bug.
Hi, So I can confirm the freeze with Version: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 under Ubuntu 13.10 x64. After slide 12, the file becomes unresponsive. I've also tried to increase the memory dedicated to LibreOffice and the per object value with no change. I confirm also that there is no freeze using version 4.1.5.3 under Debian. Change plateform to all - add regression key - decrease importance as there is no dataloss - set as new - sophie
Thank you Sophie. Do I need to keep the file available, or can I remove it from the server?
Hi, I'll keep the file locally on my side until a developer needs it, so you can remove the file from a public repository. Sophie
The bug is still there, in 4.2.1. Have again to downgrade to 4.1.....
Nobody among the developers willing to have a look at this bug? It completely freezes LO, it's not a minor bug!
Again, without a file this is hard to fix. If you can strip all the sensitive information and keep just as much that the crash is still reproducible, attaching a test file still would be most useful to move things forward here.
(In reply to comment #11) > Again, without a file this is hard to fix. If you can strip all the > sensitive information and keep just as much that the crash is still > reproducible, attaching a test file still would be most useful to move > things forward here. Sophie has the file waiting for somebody willing to test it. It's available since February 10. What else should I do?
Nobody willing to have a look at my file? This bug is CRASHING LO, it's not a minor bug!
It may be a duplicate of bug 75622. Does the presentation have many tables in it? Anyway, a (permanent) link to the bugdoc is essential, we cannot proceed, until we have it.
Some tables, but especially a large number of slides (near 200), figures and animations. I cannot provide a permanent link, our host service is limited to one month, I think. If that is enough, I'll re-upload the file.
(In reply to comment #15) > If that is enough, I'll re-upload the file. Please re-upload. Thanks.
Here it is: https://filex.univ-lorraine.fr/get?k=gN0C278nKgY0stoFY8l The file is in French but you don't have to bother with the content: if it freezes LO 4.2 as it does on my side, you have something to work with. The file is available until May 4th. But if it becomes useless before (bug fixed, for example),I would appreciate a word so that I can remove it from the server.
Created attachment 96376 [details] crasher bugdoc Thanks for the file, Massimo, I saved it, so you can remove it from your site. I saw two problems. 1) Slow loading. It is duplicate of bug 75622. It's been fixed already. 2) Crash. It crashes when it tries to load slide 12 with the svg image. I saved this slide to a separate doc (attached), which reproduces the crash. If I revert commit 1d89cd08ab3566375e30b17f1b17bc240ca907a4, then crash does not occur. commit 1d89cd08ab3566375e30b17f1b17bc240ca907a4 Author: Chr. Rossmanith <ChrRossmanith@gmx.de> Date: Sun Nov 3 13:41:40 2013 +0100 Use CSS style attributes for top level svg node Change-Id: I1f1958e0e03868167a65a2186f955a085676f9d9 Reviewed-on: https://gerrit.libreoffice.org/6563 Reviewed-by: Christina Roßmanith <ChrRossmanith@web.de> Tested-by: Christina Roßmanith <ChrRossmanith@web.de>
Dear Christina, I'm CC-ing you, because you are an svg expert, and one of your commits in svgio caused a crash with the attached bugdoc.
Does anybody know if this bug has been fixed in 4.2.3?
Still happening with latest nightly Version: 4.3.0.0.alpha0+ Build ID: f9cc0daec26016722bf5260e4e2634e6dcfe25a2 TinderBox: MacOSX-x86@49-TDF, Branch:master, Time: 2014-04-12_01:40:37 So not fixed.
So, basically, the call seems to create a recursion (SvgStyleAttributes::getParent()), because the parent styles become looped. the checkForCssStyle() seems to cause that. Need to know the reason behind the change, before this can fixed properly (or the patch reverted). Not much info from the patch log-message as well :(
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3b7472b284131c09d91b69f26d5d26d54648f939 fdo#74743 avoid infinite loop when gathering "svg" element styles 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.
Basically, what that commit tried to fix was that styles defined on <svg> element under "svg" style are taken into account when processing the child elements. But this caused a infinite loop when looking at the parent and the styles it contains. I worked around the issue but the code now is not that elegant as it could have been.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d15b2c3dbad718782d3923ece0eb6816beafab0&h=libreoffice-4-2 fdo#74743 avoid infinite loop when gathering "svg" element styles It will be available in LibreOffice 4.2.5. 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.
Joren De Cuyper committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3d3401a6397e893808309ec374f5d8f890144906 Revert "fdo#74743 avoid infinite loop when gathering "svg" element styles" 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.