Description: Fileopen: 165 pages DOC with simple table non responsive Steps to Reproduce: Open and scroll to end. Actual Results: LO non responsive, up to 5.4+ master. Expected Results: LO opens file. Reproducible: Always User Profile Reset: Additional Info: Looks like it worked before. I mark as 4.3 but it would be great to bibisect this. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Created attachment 130791 [details] Test DOC WinDBG doesn't catch the exception. Procdump makes dump.
Reproduced in Version: 5.4.0.0.alpha0+ Build ID: fc53cce64400430cdc21f79c959d75fb9a26d13d CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group I tried to bisect it and it pointed me to 849c3d59f9838516b5e0d56a2630928629384ad3 but reverting the commit didn't fix the problem...
In a local build of commit 9ba5eb22, pulled on 2017-02-03, after CPU usage 58 minutes, I see the program looping in the outermost call of SwTabFrame::MakeAll, in the loop starting at sw/source/core/layout/tabfrm.cxx line 1874 ... while ( !mbValidPos || !mbValidSize || !mbValidPrtArea ) Some iterations take about 0.01 CPU seconds, and some about 10 CPU seconds.
I used bibisect-43all version oldest to open the attached .ods and poke around and to create a file that daily Linux dbgutil version 2017-02-05 can open successfully. A couple of observations ... (*) When I open the file, the status bar shows 140 pages, 25 pages less than what Timur reports. (*) If I delete column 4 of the spreadsheet, then the recent LO opens the resulting file without problem. (*) In column 4 of the spreadsheet, one merged cell spans from page 15 to page 86.
Created attachment 131381 [details] Test DOC saved from MSO
Created attachment 131506 [details] Strange behavior It happens when "allow row to break across pages and columns" table property is disabled. While opening the .doc format the property was enabled by default in oldest versions. So bisect can not help us. --- If I remove all shape lines from table cells in the document then it opens successfully but slowly (There are lags from cells that are having their content height more than page height. Overflowing height is a consequence of the table property). --- This happens when a table have merged cells in a column which split between pages --- Strange behavior at splitting. Current way: 1) Open the attachment 2) Put a new line in last column and write something You are on page 4 3) Remove the line and put again You are on page 3 4) Repeat You are on page 2 5) Repeat You are on page 2 .. 6) Remove all lines in last column and put some new lines You are on page 4 .. Right way: 2) Put a new line in last column and write something You are on page 2 3) Put many lines You are on page 3 ..
oh.. another one strange thing. Open the attachment 131506 [details] Put new lines in R2C2 cell. Is shows R3xx fluctuations in splitting.
Created attachment 131508 [details] Test DOC - WinDbg from procdump vcllo!WinSalGraphics::ImplDoSetFont+14d
Raal or Baron, can you try with this not-so-easy bibisect? Vitaliy, I guess you have other bugs too, but please see if you can solve this one or remove yourself from Assignee. Thank you all.
(In reply to Timur from comment #9) > Raal or Baron, can you try with this not-so-easy bibisect? > Vitaliy, I guess you have other bugs too, but please see if you can solve > this one or remove yourself from Assignee. > Thank you all. Hi Timur, I tried in comment 2 but the bisect result was incorrect
I don't see evidence that this is really a regression, i.e. a version of libreoffice that opens this as a table and when the "don't split row property" is set then behaves without the slowness, so I'll clear regression of bibisectrequest and checking older OpenOffice.org I see the same problem once the row split thing is unset so its an inherited problem as far as I can see. Realistically problem only mstahl or vmlikos has a clue about the table splitting layout code
I'll try to take a look, but I can't promise it. SwTabFrame code is complex enough that usually any change where the consequences are understood are taking days.
Repro 6.2+
Still exists in version Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
Dear Timur, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro 6.5+.
The document is filled with images anchored to character.. Copy/paste doc from Word to LibreOffice, or open the file with navigator open) So probably a layout loop caused by to character anchoring. And the multiple page split table isn't helpful either.
Repro 7.4+. I see "1 of 31 pages" and hang. DOCX also hangs, differently. As for images, fileopen hang not reproduced if images from DOC or DOCX deleted in MSO (only after more scroll).
I see no more looping in 7.5 after https://git.libreoffice.org/core/+/18f259482782a3b3c44e01ca6ea0e98fe00973a0 author Miklos Vajna <vmiklos@collabora.com> Fri Dec 09 16:52:48 2022 +0100 committer Xisco Fauli <xiscofauli@libreoffice.org> Wed Dec 14 08:48:32 2022 +0000 sw layout: invalidate margins of body content when moving a fly from page This appears to be a regression from commit b9ef71476fd70bc13f50ebe80390e0730d1b7afb (tdf#134298 sw: layout: remove left-over page frame without content, 2020-11-13).