Bug 98646 - Hang when double-clicking item in navigator
Summary: Hang when double-clicking item in navigator
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium major
Assignee: Armin Le Grand
URL:
Whiteboard: target:5.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-14 13:16 UTC by Buovjaga
Modified: 2018-05-19 16:16 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Trace of hang (12.28 KB, text/plain)
2016-03-14 14:10 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Buovjaga 2016-03-14 13:16:55 UTC
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
Comment 1 Buovjaga 2016-03-14 13:17:14 UTC
Already confirmed in bug 98140
Comment 2 Buovjaga 2016-03-14 14:10:30 UTC
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.
Comment 3 Armin Le Grand 2016-03-15 12:40:25 UTC
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).
Comment 4 Armin Le Grand 2016-03-15 12:54:28 UTC
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?
Comment 5 Armin Le Grand 2016-03-15 13:28:40 UTC
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.
Comment 6 Armin Le Grand 2016-03-15 13:49:35 UTC
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.
Comment 7 Armin Le Grand 2016-03-15 14:50:00 UTC
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.
Comment 8 Armin Le Grand 2016-03-15 16:21:42 UTC
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.
Comment 9 Armin Le Grand 2016-03-15 16:29:15 UTC
Commit on gerrit, hang fixed.
Comment 10 Buovjaga 2016-03-16 12:32:38 UTC
Sorry I had a stomach sickness. Thanks for the fix. Original reporter was ptr from bug 98140.
Comment 11 Commit Notification 2016-03-22 09:02:52 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=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.
Comment 12 Xisco Faulí 2016-09-15 20:50:17 UTC
Hi,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Regards
Comment 13 Armin Le Grand 2016-09-16 07:43:35 UTC
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..?
Comment 14 Buovjaga 2016-09-16 07:46:17 UTC
(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.