In my document, a footnote is somewhere wrong. As the documend has nearby 500 pages, it's not easy to find the stucking one. I have compiled LO from the sources and debugged it with VisualStudio and found out, that the function is in wsfrm.cxx (sw\source\core\layout). The warning is on line 3084 (warn:sw.layout:26048:36420:sw/source/core/layout/wsfrm.cxx:3084: footnote frame on different page than ref frame?). The problem is, that LO now generates 100% CPU, as it could not go on further and generates this warning 10 times/second. I try now, to find out, if I could add some informations about the stucking footnote, but I think, LO needs to be optimized, that this case did not happen or LO could fix it for itself. As my file gots 4MB, I could not attach it here. I have put it on my space, if someone wants to analyze it: https://dict.ch/allgemein/ (Assembler-Grundlagen - vom Mikrokontroller zum Grossrechner.odt). Sincerely, Markus Grob
(In reply to Markus Grob from comment #0) > I have compiled LO from the sources and debugged it with VisualStudio and > found out, that the function is in wsfrm.cxx (sw\source\core\layout). Can you copy the build information from Help > About , in versions with which you've seen the bug manifest?
I can't reproduce with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 92815f3a464b447898ecf52492247335228e4a72 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US nor with: Version: 24.2.0.2 (X86_64) / LibreOffice Community Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US I've opened the file, scrolled back and forth, selected some text... is there a specific sequence of actions after which LO hangs?
Hi Eyal That's strange. I first got it in Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 28; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-CH (de_CH); UI: de-DE Calc: CL threaded Then compiled it: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 92815f3a464b447898ecf52492247335228e4a72 CPU threads: 28; OS: Windows 10 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: de-CH (de_CH); UI: en-US Calc: CL threaded It hapens on my laptop after about 3 seconds. LO freezes and in VS I see the repeating line with the footnote I posted. Markus
Now I have loaded it with OpenSuse Leap 15.4 and there it starts. When I save it there and run it again on Windows, It starts with blocking. Now I get a lot of unknown property warnings, but the document is editable for about 1 Minute. After this it freezes again, while it stucks in an endless loop (see screenshot). In Linux this doesn't happen. Maybe it renders with another process or something else. Maybe I have to compile it on Linux and check, which warnings wre generated in debug-Mode.
Created attachment 194077 [details] Error-Window of Visual Studio while LO is running Error-Window of Visual Studio while LO is running with a lot of warnings...
I have checked now with debug mode on OpenSuse. Same as on Windows. Because it runs into this function: SwTwips SwLayoutFrame::ShrinkFrame( SwTwips nDist, bool bTst, bool bInfo ) x times/second (defined in: wsfrm.cxx line 3084) it runs at 100% CPU time and doesn't react. It warns (in the background), that there are unknown properties and the bookmark is on the wrong page. The unknown properties are in lngprophelp.cxx line 636: unknown property 'HyphNoLastWord', unknown property 'HyphKeepType', unknown property 'HyphKeep' My problem is, that it doesn't tells me, where exactly in the document and why it happens. Maybe I could unzip and wipe it out manually or use the ooxml-viewer-vscode on github: https://github.com/yuenm18/ooxml-viewer-vscode Somebody any hints? At the moment I will find out, if LO runs through this function even if an empty document is open, but for this, I have to insert timestamps and recompile. Let's see, I never programmed c++ until now ;-) Sincerely, Markus
(In reply to Markus Grob from comment #0) > In my document, a footnote is somewhere wrong. As the documend has nearby > 500 pages, it's not easy to find the stucking one. Very slow loading, UI interaction and/or converting the files is in itself a problem, which falls into the category of "Performance", categorized as meta bug tdf#136524. You can measure the time needed to convert the file using command line, even without building LibreOffice: $ time libreoffice24.2 --convert-to pdf input.odt Or with the LibreOffice built from sources: $ time instdir/program/soffice --convert-to pdf input.odt The amount of time needed to convert your 500 pages PDF files should be a few seconds. If it takes more than a minute, it means that this is actually a bug around performance. Converting using LibreOffice 24.2 was also possible, withing a few seconds. I could also convert the file using the latest LO dev master (debug build is slower) in 2m38s. On the other hand, when opening the file, and immediately trying to export the file to PDF via "File > Export as > Export as PDF", waiting a few seconds lead to LibreOffice hang. This happens in LibreOffice 24.2, but not 24.8 dev master: Reproducible with: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Not reproducible with: (it warns me about missing hyphenation data for de-CH) Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 9422879a5cf74120c1057b0f8150529e304f7c95 CPU threads: 20; OS: Windows 11 (10.0 build 22631); UI render: default; VCL: win Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded One thing to mention is that some hanging shapes and formulas are displayed on the top of the first page for a small amount of time, but they disappear very fast.
I now have tested it on my Win10. New Laptop with 28 cores. Export with DEv-version from 18th of Mai needed 2 minutes and 4 seconds to build the pdf. WHen I start the build with the document as argument, it needs the same time. First it seems to stuck with the message "repagening", but after 1 minute it changed to "export" and from the start until it's on the directory, it's the same time. For me, the time to read and analyze the document is the point where the problem needs to be searched. Now I try to get the "bad" parts of the document, as I now have found I way to display the nodenumber in the warning window.
(In reply to Markus Grob from comment #8) > I now have tested it on my Win10. New Laptop with 28 cores. Export with > DEv-version from 18th of Mai needed 2 minutes and 4 seconds to build the pdf. > WHen I start the build with the document as argument, it needs the same > time. First it seems to stuck with the message "repagening", but after 1 > minute it changed to "export" and from the start until it's on the > directory, it's the same time. > For me, the time to read and analyze the document is the point where the > problem needs to be searched. Now I try to get the "bad" parts of the > document, as I now have found I way to display the nodenumber in the warning > window. In LibreOffice Bugzilla, there is even a dedicated meta bug for re-pagination, which is an important issue: tdf#107396. You can see a tree of these issues here: https://bugs.documentfoundation.org/showdependencytree.cgi?id=107396&hide_resolved=1 I add this issue to the Performance meta bug, and also remove "(endless loop)" from the title to describe the fact that this does not always lead to a complete hang.
One of the problems is, that it's not only the slow loading. When the document should be edited, the style properties are not changed for about 30 seconds. After this, when I try to change the style, LO crashes: Failed vulkan call. Error: -4,QueueSubmit(queue, 1, &submitInfo, fence)
Created attachment 194228 [details] error when calling font in style