Bug 108005 - Writer hangs several seconds after saving
Summary: Writer hangs several seconds after saving
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.6.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Stephan Bergmann
URL:
Whiteboard: target:6.1.0 target:5.4.6 target:6.0.2
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2017-05-22 17:24 UTC by Dr. Matthias Weisser
Modified: 2018-02-15 20:48 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
test file showing saving delay, slow scrolling, picture position problem (465.99 KB, application/vnd.oasis.opendocument.text)
2017-06-07 10:11 UTC, Dr. Matthias Weisser
Details
picture file for test file (20.01 KB, image/png)
2017-06-07 10:14 UTC, Dr. Matthias Weisser
Details
Callgrind output from 5.5 (9.49 MB, application/x-xz)
2017-06-07 16:22 UTC, Buovjaga
Details
Bibisect log (2.91 KB, text/plain)
2017-10-29 10:35 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dr. Matthias Weisser 2017-05-22 17:24:26 UTC
Its a Win7 64bit dual core system using 4GB RAM.

I am writing books with pictures included as extra files. Therefore the file size of the odt itself should not be an issue.

One text is 472kB in odt size - 367 pages and 405 pictures. 
 
Unfortunately this now works not so responsive as should be.

I have another text with 768 pages and also pictures which seemed to give no problem with the older LO versions I used for editing.

Saving the 472kB odt without changing any picture gives a bar in the status line. When this bar disappears it seems to be that the odt is saved. But unfortunately still working is not possible. It takes several seconds (~5s) before being able setting the cursor again.

I resaved the text to another name. Same problem. It takes about 5 seconds need to wait before something can be done. This really is a frustrating experience.

I did a test file and copied to another PC - without the picture files. Therefore LO is not able loading and showing those pictures. The problem with saving is then not to see. 

Therefore it does not seem to be so easy showing the problem. I am not able giving all those pictures from my book. I hope you will understand.

I really hope there will be a solution for this. May be someone has an idea.
Comment 1 Timur 2017-05-23 11:51:06 UTC
Thank you, but this can't be conformed like this, even that I'm seeing some unresponsability myself. 
You should either attach minimal test case to reproduce a bug or test this yourself. 

I'm suggesting that you:
- get http://tdf.io/siguiexe to easily get and run "parallel" LO in Windows (extract without installation)
- run different extracted versions (here it would be fresh 5.3.3.2 and 5.4 beta and master 5.5+) and architectures (32-bit or 64-bit) related to this bug in order to test crash
- note crash report link for crash with LO 5.2 and higher, sth. like crashreport.libreoffice.org/stats/crash_details/.... (not applicable here but a general advice)

and, if possible, since it's not overly complicated, but gives some clues:
- use procdump (part of free and useful Sysinternaly Suite) during LO run in order to get a dump (soffice.bin.dmp)
- run procdump manually after LO start (path-to\SYSINTERNALSSUITE\procdump.exe soffice.bin -h path-to\soffice.bin.dmp) for reproducible bugs like this one, OR via simple batch file like attachment 129814 [details], that is used instead of LO icon to start LO, for intermittent bugs (which seems to be the case here)

and even this - or just upload previous crash dump with LO "Master x86 39":
- analyze dump with WinDbg configured per https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg (set "Symbol File Path")
- attach here as an attachment result of "!analyze -v" command in WinDbg (that's "backtrace") 
- if "!analyze -v" is empty, which comes after "ntdll!NtTerminateProcess" error, go with "kb" that prints stack trace and "~* kp" to dump the whole stack.
Comment 2 Dr. Matthias Weisser 2017-05-31 19:48:56 UTC
I do not feel that there is a real crash here. It looks like a delay.

To clarify some more where the problem comes from I had a test with the previous versions 4.3.7.2 and 4.4.7.2.

Both versions do not show this delay. They seem to be ok.

The delay is there in version 5.1.6. It does not matter if 32bit or 64bit installation. Both are showing the problem. I hope this helps a bit. 

Seems to be that version 5 does have this problem - may be in all versions.
Comment 3 Dr. Matthias Weisser 2017-06-01 08:50:26 UTC
I now checked different versions with this text:

LO 4.3.7.2 is ok - no problem with 5s waiting time after saving
LO 4.4.7.2 is ok.
LO 5.1.6 not ok.
LO 5.2.7 not ok.
LO 5.3.3 not ok. This version seems to load less fast.
LO 5.4.0 not testable on my system. Install produces a message "Das Programm kann nicht gestartet werden, da api-ms-win-crt-runtime...dll auf dem Computer fehlt.
Installieren Sie das Programm erneut.."

Reinstall fails with the same message.

So its not so easy for me at the moment. The newer versions do seem to have problems that the 4 series did not have. 

Unfortunately also the 4.4.7.2 showed a problem. I reported this as https://bugs.documentfoundation.org/show_bug.cgi?id=100103.

Thank you Timor, but I am not a software specialist using test tools.
Comment 4 Buovjaga 2017-06-04 18:35:03 UTC
It will be difficult to test without having access to the file. I guess you don't want to share it publicly. It would be pretty hard to anonymise with so many pictures :(
Comment 5 Dr. Matthias Weisser 2017-06-04 19:16:35 UTC
Its no problem for me giving the odt file. But its not possible making all those pictures in the separate folder public.

I did some tests with a stop watch:
LO4.3.7.2 open file ~5s, ~30s until scroll down stops. ~13s until save finished
LO5.1.6.2 open file ~5s, ~30s until scroll down stops. ~13s until save finished
LO5.2.7.2 open file ~5s, ~30s until scroll down stops. ~13s until save finished
LO5.3.3.2 open file ~5-6s, ~2min until scroll down stops. ~13s until save finished

There is clear to see that LO shows that saving is complete much too early. After ~5s the bar for saving the file disappears, but only after ~13s its really finished.

Using LO5.3.3.2 the time needed to scroll increases factor 4 to ~2min. 

LO5.4.0.0 is not possible getting to work on my system for testing. There comes a message: "Prozedureinsprungpunkt ucrtbase.terminate in DLL
api-ms-win-crt-runtime...dll nicht gefunden."
Comment 6 Buovjaga 2017-06-05 04:20:35 UTC
(In reply to Dr. Matthias Weisser from comment #5)
> LO5.4.0.0 is not possible getting to work on my system for testing. There
> comes a message: "Prozedureinsprungpunkt ucrtbase.terminate in DLL
> api-ms-win-crt-runtime...dll nicht gefunden."

I've fixed that message on Windowses by doing Windows updates. I read that it is because of some incomplete update and yep, it fixed it.
Comment 7 Dr. Matthias Weisser 2017-06-05 18:22:07 UTC
"I've fixed that message on Windowses by doing Windows updates. I read that it
is because of some incomplete update and yep, it fixed it."

Thank you very much for this hint !
Do you know which of the many updates did do this?
Comment 8 Buovjaga 2017-06-05 18:49:36 UTC
(In reply to Dr. Matthias Weisser from comment #7)
> "I've fixed that message on Windowses by doing Windows updates. I read that
> it
> is because of some incomplete update and yep, it fixed it."
> 
> Thank you very much for this hint !
> Do you know which of the many updates did do this?

Not sure, but I think it might even be an "optional update", ie. not one of the Very Important ones.
I do remember some people talking about lacking some VC++ runtime update being the cause for the error.. you never know with this mystical Windows stuff!
Comment 9 Dr. Matthias Weisser 2017-06-05 19:05:24 UTC
"you never know with this mystical Windows stuff!"

yes - unfortunately this seems to be the case quite often.
more updates not always is the best.
Comment 10 Dr. Matthias Weisser 2017-06-07 09:54:01 UTC
here now is a test file similar to my text. Several points can be seen with this.

Its possible to see
- that there is a delay after the saving bar has gone.
- that there is an increase in time needed to scroll after loading the file when using LO 5.3. This should be put to a new issue.
- that there are problems using LO 5.3 when putting the picture on other pictures in order to replace them. I have seen this quite often when replacing all my pictures with the new one. This should be put to a new issue.
Comment 11 Dr. Matthias Weisser 2017-06-07 10:11:51 UTC
Created attachment 133890 [details]
test file showing saving delay, slow scrolling,  picture position problem

opening the file (with the one picture in folder BILDER) in LO5.3.3.2 takes about 4s on my system. Holding the "Bild down" button the text scrolls downward. This takes ~2min using LO5.3.3.2 - in comparison to ~30s with versions before LO5.3.3.2. like LO5.2.7.2.

When saving the file the bar disappears after some seconds - but the system is still busy and does not react in this time when trying to mark text by using clicks with left mouse button.
Comment 12 Dr. Matthias Weisser 2017-06-07 10:14:00 UTC
Created attachment 133891 [details]
picture file for test file

picture file for using with test file to be put in newly created folder BILDER.
Comment 13 Dr. Matthias Weisser 2017-06-07 10:16:34 UTC
(In reply to Buovjaga from comment #4)
> It will be difficult to test without having access to the file. I guess you
> don't want to share it publicly. It would be pretty hard to anonymise with
> so many pictures :(

I tried doing so. Instead of using so many different pictures I used just one. This clearly is different but also the problems can be seen.
Comment 14 Buovjaga 2017-06-07 16:21:29 UTC
I confirm the few seconds of unresponsiveness after progress bar finishes. In this regard this is the same as bug 98731, but I will let developers decide whether to close as duplicate or not.

3.6 does not have the lag on opening or saving.

I did not notice any lag on scrolling in any version.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.5.0.0.alpha0+
Build ID: 88d3c067831dac8cf69ebaa079f1d809d727a342
CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on June 7th 2017

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)
Comment 15 Buovjaga 2017-06-07 16:22:38 UTC
Created attachment 133900 [details]
Callgrind output from 5.5
Comment 16 Mike Kaganski 2017-07-29 18:20:54 UTC Comment hidden (off-topic)
Comment 17 Telesto 2017-10-29 10:35:38 UTC
Created attachment 137354 [details]
Bibisect log

The mismatch between finalized saving progress bar & and the moment that writer gets responsive writer started with: 

author	Stephan Bergmann <sbergman@redhat.com>	2015-04-22 12:06:37 (GMT)
committer	Stephan Bergmann <sbergman@redhat.com>	2015-04-22 12:06:37 (GMT)
commit	017f250764ec7b4ecb82ac19f5b3f68cadf1bf56 (patch)
tree	1f953589877514c08c591f6df020694d890a03a3
parent	deaed8aff6de824a76d939a02edb0d2ff4a4ccec (diff)
Ensure WakeUpThread is joined before exit
Change-Id: If50fe94875b29043c75b581bf39ca9deea59dbe3
Comment 18 Telesto 2018-02-13 14:06:24 UTC
Adding CC to Stephan Bergmann
Comment 19 Stephan Bergmann 2018-02-14 12:30:43 UTC
(Removed keyword "perf".  This is not a performance issue.  The time it takes to save is not affected by this; just the progress bar stopped prematurely, giving the impression that LO got stuck after saving, when in fact it had just not finished saving yet.)
Comment 20 Commit Notification 2018-02-14 20:31:53 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=57574c2bcc60d37620288c403267c34d960f5863

tdf#108005: Problems with progress bar while saving document

It will be available in 6.1.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 21 Commit Notification 2018-02-15 20:48:03 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=831c4f1874f01bcd7282cdf08b1446acc5c4760e&h=libreoffice-5-4

tdf#108005: Problems with progress bar while saving document

It will be available in 5.4.6.

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 22 Commit Notification 2018-02-15 20:48:13 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=56b96f3cc1f03313afade4f642861efb76d0bb54&h=libreoffice-6-0

tdf#108005: Problems with progress bar while saving document

It will be available in 6.0.2.

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.