Bug 97129 - No feedback while saving a large Writer document, dumps on fileopen and filesave
Summary: No feedback while saving a large Writer document, dumps on fileopen and filesave
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Save
  Show dependency treegraph
 
Reported: 2016-01-14 11:41 UTC by Urmas
Modified: 2019-10-23 12:03 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
15k page writer document (987.88 KB, application/vnd.oasis.opendocument.text)
2016-01-16 15:10 UTC, FutureProject
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Urmas 2016-01-14 11:41:27 UTC
After 2016, the master version started to show this behavior when saving. The window becomes irresponsible, and the progress bar does not move.
Comment 1 FutureProject 2016-01-14 12:15:05 UTC Comment hidden (obsolete)
Comment 2 Urmas 2016-01-14 12:39:21 UTC
Create any large Writer document and check. Progress bar was working before, it is broken now.
Comment 3 FutureProject 2016-01-16 15:10:57 UTC
Created attachment 121996 [details]
15k page writer document

I have done some testing and can confirm the described behaviour.

Using Windows 7 Professional; Version 6.1 (Build 7601: Service Pack 1)

A. The following version still works fine:

Version: 4.4.0.1
Build ID: 1ba9640ddd424f1f535c75bf2b86703770b8cf6f
Locale: de_DE

B. When using the following build:

Version: 5.0.4.2
Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
Locale: de-DE (de_DE)

Loading the attached file produces a progress bar at the bottom of the main window that steadily grows until the document is ready to display. Works as intended. When saving the document, the main window becomes unresponsive until the saving is done.

C. Using a later build still:

Version: 5.1.0.2 (x64)
Build ID: ecd3574d51754b043f865cf5bafee286d24db7cc
CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; 
Locale: de-DE (de_DE)

Now the main window also freezes while loading the document, additionally to the behaviour from B. Neither saving nor loading display any progress because of this.

Therefore, assume that one part of the issue (freezing while saving/loading) was introduced after 4.4.0.1, but at the latest with 5.0.4.2. The freeze on load was introduced somewhere after 5.0.4.2.

I've attached the file I used for testing and will mark this issue as NEW. I'll also add the regression keyword since it's a newly emerged behaviour.
Comment 4 Joel Madero 2016-01-16 16:12:28 UTC
@Urmas - in the future please just attach a document....you've been around long enough to know that QA usually is not going to "create any 'large' writer document." Thanks
Comment 5 QA Administrators 2018-05-19 02:35:37 UTC Comment hidden (obsolete)
Comment 6 Buovjaga 2018-05-22 18:54:49 UTC
(In reply to FutureProject from comment #3)
> Created attachment 121996 [details]
> 15k page writer document

I tested this with 4.3.0 beta1, 4.4.7.2, 5.0.2.2 and 5.3.0 alpha1 and all show the same behaviour: Saving document... then finally the progress bar shows up and advances quite quickly from beginning to end.

Testing with 6.1 on Win 10, I get Repagination... with a progress bar advancing only like 5% and then stopping. Finally after a longer time than the older versions, a progress bar for the actual saving whizzes by quite quickly.

6.1 on Linux shows the Repagination... progress bar consistently, advancing from beginning to end. Actually, it repaginates twice, with a separate progress bar in the middle.

So I cannot bibisect this as the behaviour is the same in the old versions and has now changed.
Comment 7 QA Administrators 2019-05-23 02:50:15 UTC Comment hidden (obsolete)
Comment 8 Thomas Lendo 2019-05-24 07:36:07 UTC
Still window freezing.

Version: 6.3.0.0.alpha1+ (x64)
Build ID: c3245cfd54f391111afb424867ab483096d9de5e
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-19_22:59:06
Locale: de-AT (de_AT); UI-Language: en-US
Comment 9 Timur 2019-10-23 12:03:44 UTC
Repro 6.4+ in Windows and Linux, so I set All. 
Using procdump.exe I see dumps both on fileopen and filesave. That would be a different bug for this ODT but let's not separate until something is done and fixed here, either loading either dumps. So far it's not trivial but seems major. 
Dumps and no feedback happen all the way from OO, so that's Inherited. 
I see that reporter said this started after 2016 but we can reproduce only for attached document. Maybe it felt different for some others. 
As for Comment 3 that LO 4.4 works fine, I don't know how, maybe repeated, all should be first time load and save. 
I remove bibisectRequest, regression.

FOLLOWUP_IP: 
swlo!SwFrame::CheckPageDescs+779
1ee5e9e9 8b45ec          mov     eax,dword ptr [ebp-14h]
SYMBOL_STACK_INDEX:  0
SYMBOL_NAME:  swlo!SwFrame::CheckPageDescs+779


FOLLOWUP_IP: 
icuuc63!utext_setNativeIndex_63+0
5dc5a170 55              push    ebp
SYMBOL_STACK_INDEX:  0
SYMBOL_NAME:  icuuc63!utext_setNativeIndex_63+bbd784

I have troubles with WinDbg, it gives errors (ERROR: Symbol file could not be found), so I don't attache backtrace.