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.
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.
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.
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.
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 :(
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."
(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.
"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?
(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!
"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.
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.
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.
Created attachment 133891 [details] picture file for test file picture file for using with test file to be put in newly created folder BILDER.
(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.
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)
Created attachment 133900 [details] Callgrind output from 5.5
(In reply to Buovjaga from comment #6) > (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. Today I've heard a number of problems like that on our Russian forum: http://forumooo.ru/index.php/topic,6645.html A number of people trying to test 5.4.0 RC3 report that they have installer succeeded, but LO failing to start mentioning absent api-ms-win-crt-runtime-l1-1-0.dll. For them, installing VC redist for VS 2015 "fixes" the problem. But as we bundle the redist with LO MSI (that must install directly into LO directory, independent of system vcredist), it is not a solution, but masking the bug. Buovjaga, I wonder if your solution ("completing" some updates for Windows) might be a similar masking (because Windows happened to install system vcredist), or a different thing (e.g., revealing true cause like some system state preventing us from installing vcredist merge module). It is, of course, a different problem that deserves a separate bug report, but I cannot report it since I don't reproduce that myself.
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
Adding CC to Stephan Bergmann
(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.)
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.
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.
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.