Open attachment 123558 [details] Open navigator. Double-click the item highlighted in attachment 122948 [details] 3.5 crashes when trying to open the file. File taken from bug 98140 Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: b89feb8018bf3610faf01e73995d576f6566e20b CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-07_03:36:17 Locale: fi-FI (fi_FI) 4.3.0.1
Already confirmed in bug 98140
Created attachment 123560 [details] Trace of hang I tried to get a trace of the hang in WinDbg. I first did Debug - Break. Then I did !analyze -v -hang I hope it is worth something.
Also happens in current master, taking a look. Tried with a doc reduced to first two pages, but does not happen there, strange. Problem is definitely the wrong Rectangle for the selected GroupObject on 2nd page. On original BugDoc, it's far out and creates a crash, on reduced BugDoc all is good and it gets the default fallback size for an empty group (0,0,100,100).
Tried to reduce less, same effect. In the reduced versions the group object creating trouble is empty, on the original it is not empty. In the original it is one of the 'Smart Objects', which gets not imported (as empty group object) in the reduced docs I produced. This might depend on the PPT version used to produce this doc. Who originally produced it and is a reduced doc available which also causes the error? E.g. stripped to the first two pages?
I could clearly show that CustomShapes with incredible sizes get created from ooxml import, set breakpoint at SdrTextObj::ImpJustifyRect with condition 'rRect.nRight > 1000000' to see. Nonetheless, this is an import error. Besides that, Office freezes since DrawViewShell::MakeVisible has some loops instead of calculating size/position changes, this makes the office freeze. To fix the freeze, I will have to correct those loops.
Also has nothing to do with navigator, that part works well. Same problem can be achieved by: - Load file - Goto page two, tab -> selects first object, Office hangs That is because each object selection calls MakeVisible() and with malformed/badly imported objects the problem is triggered.
The values involved in loading are so extreme, that Rectangle::GetWidth() creates an integer overflow and returns a wrong (and negative) value. The non-strippable doc hints to the original doc having an error. Looking how these numerical overflows can/may be handled.
Flattened the loops so that no freeze can happen. Tested that the same results are achieved. Added code to detect numerical overflows. Works well. The real error is in *.pptx import of the document or the document has an error. Not sure if to look for that in the same task or in another, maybe the original one (bug 98140). Preparing to commit flattened loops andd secured numerical handling.
Commit on gerrit, hang fixed.
Sorry I had a stomach sickness. Thanks for the fix. Original reporter was ptr from bug 98140.
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=23391fdb5cffb62006415ad1f4c96b6ed5d50cf8 tdf#98646 Fixed freeze by flattening loops 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.
Hi, Is this bug fixed? If so, could you please close it as RESOLVED FIXED? Regards
I was told that as a developer I should not do exactly that - it will be tested for being fixed and closed by QA. Explanation was that QA wants to explicitely check if the task is solved from QA-Perspective (sometimes different from dev one, thus a good thing from my POV). Did that change..?
(In reply to Armin Le Grand (CIB) from comment #13) > I was told that as a developer I should not do exactly that - it will be > tested for being fixed and closed by QA. Explanation was that QA wants to > explicitely check if the task is solved from QA-Perspective (sometimes > different from dev one, thus a good thing from my POV). Did that change..? You can set it to resolved. QA can verify and set to verified, if we like.