Created attachment 188570 [details] spindump.txt I have couple Writer docs open and one Calc. Typically I have Writer doc active and then it spinwheels (spindump attached) and crashes frequently. Reinstall changed nothing. MacOS does not pick up this crash. Rectangle 0.69 in use. No, I'm not attaching any of the docs. Version: 7.5.5.2 (AARCH64) / LibreOffice Community Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e CPU threads: 8; OS: Mac OS X 13.4.1; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Please test in safe mode, Menu/Help/Restart in Safe Mode
Also, please upgrade to LO 7.5.5
Additional data: It typically spinwheels when attempting to save. The files are KBs in size. Sometimes it ultimately saves, sometimes crashes. No other programs have this issue. I don't have any 3rd party extensions, modifications, etc. Vanilla install. Reproduced in: Version: 7.4.7.2 / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 8; OS: Mac OS X 13.5; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Also reproduced in: 7.6.0 (In reply to m.a.riosv from comment #1) > Please test in safe mode, Menu/Help/Restart in Safe Mode Tried in Safe Mode via below, not reproducible: Version: 7.4.7.2 / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 8; OS: Mac OS X 13.5; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded (In reply to Julien Nabet from comment #2) > Also, please upgrade to LO 7.5.5 You might have been looking at the "Version:" drop down as I already tested this.
Created attachment 188580 [details] spindump.txt Scratch the Safe Mode not demonstrating. Just reproduced spinwheeling (not crashing) for a few minutes straight in Safe Mode with: Version: 7.4.7.2 / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 8; OS: Mac OS X 13.5; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to Chris Peñalver from comment #3) >... > (In reply to Julien Nabet from comment #2) > > Also, please upgrade to LO 7.5.5 > > You might have been looking at the "Version:" drop down as I already tested > this. Oups, you're right indeed! uncc myself, I can't do anything here.
Created attachment 188583 [details] Spindump.txt Same thing same problem in Safe Mode with: Version: 7.5.5.2 (AARCH64) / LibreOffice Community Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e CPU threads: 8; OS: Mac OS X 13.4.1; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Patrick, are the attachments useful? Maybe related to bug 150962 and bug 153285.
(In reply to Stéphane Guillou (stragu) from comment #7) > Patrick, are the attachments useful? > Maybe related to bug 150962 and bug 153285. Here is what I see in the 3 attached spin dumps: Writer is saving a file and is laying out text. I assume that the text width and height is being measured for a lot of text so my initial guess is that this is a Writer export performance bug. @Chris Peñalver: are you saving as an .odt file or a different file format?
(In reply to Patrick Luby from comment #8) > (In reply to Stéphane Guillou (stragu) from comment #7) > > Patrick, are the attachments useful? > > Maybe related to bug 150962 and bug 153285. > > Here is what I see in the 3 attached spin dumps: Writer is saving a file and > is laying out text. I assume that the text width and height is being > measured for a lot of text so my initial guess is that this is a Writer > export performance bug. > > @Chris Peñalver: are you saving as an .odt file or a different file format? I'm saving as .odt but the file is one page worth of text at 12pt (i.e. not a lot of text by any means). Couple caveats is the text is inside a frame so maybe that's part of the performance snag?!
(In reply to Chris Peñalver from comment #9) > I'm saving as .odt but the file is one page worth of text at 12pt (i.e. not > a lot of text by any means). Couple caveats is the text is inside a frame so > maybe that's part of the performance snag?! The frame could be. I am no expert on the Writer code, but from the limited data in the spin dumps my first guess is that the Writer save-to-odt code is in an infinite loop calculating text width and height. If we could reproduce this bug in a debugger would be ideal, but I understand if you don't want to share your document. So, here are a couple of things to try to narrow down what content and/or formatting triggers this bug: 1. Make a copy of your document and replace the content (but not any formatting) with random text. If the bug still occurs, then upload the "anonymized" document. If the bug stops occurring, then try step 2 below. 2. Make a copy of the document and try removing content in the document's frameuntil you can save successfully. Then close the document, make a new copy, and remove ever increasing chunks of text until it can save again. Alternatively, if you have Xcode installed on your machine and you are comfortable using Terminal commands, I can provide steps to get a detailed dump that has source code line numbers.
Created attachment 188626 [details] test.odt If one opens attached and double clicks in the bottom frame, then while the cursor is active in the frame and attempts to save, that's when the spinwheeling happens. However, if one clicks outside of the frame, so the cursor is not inside it then save, it saves immediately. Hence, there is both a workaround and reproduction scenario.
(In reply to Chris Peñalver from comment #11) > Created attachment 188626 [details] > test.odt > > If one opens attached and double clicks in the bottom frame, then while the > cursor is active in the frame and attempts to save, that's when the > spinwheeling happens. > > However, if one clicks outside of the frame, so the cursor is not inside it > then save, it saves immediately. Hence, there is both a workaround and > reproduction scenario. Thank you for the sample document. Unfortunately, I cannot reproduce the bug with LibreOffice 7.5.5.2 or the nightly master build. What I did notice is that the font in the bottom frame is set to Inconsolata. I don't have that font on my machine so I wonder if that particular font is the cause of the slowness. If you double-click on the bottom frame, select all the text in the frame, and change to the font to Arial, does that stop the hanging? If yes, do you have a link that I can download the Inconsolata font from?
(In reply to Patrick Luby from comment #12) > (In reply to Chris Peñalver from comment #11) > > Created attachment 188626 [details] > > test.odt > > > > If one opens attached and double clicks in the bottom frame, then while the > > cursor is active in the frame and attempts to save, that's when the > > spinwheeling happens. > > > > However, if one clicks outside of the frame, so the cursor is not inside it > > then save, it saves immediately. Hence, there is both a workaround and > > reproduction scenario. > > Thank you for the sample document. Unfortunately, I cannot reproduce the bug > with LibreOffice 7.5.5.2 or the nightly master build. > > What I did notice is that the font in the bottom frame is set to > Inconsolata. I don't have that font on my machine so I wonder if that > particular font is the cause of the slowness. > > If you double-click on the bottom frame, select all the text in the frame, > and change to the font to Arial, does that stop the hanging? If yes, do you > have a link that I can download the Inconsolata font from? Strangely, when I open the file, and do font changing as suggested no reproduction. There appears a more subtle dependency that is messing up the root cause here. Specifically, when I use the production doc that reproduces, and pare it down, I can still reproduce. However, after a save and close, not reproducible. Hence, I think the spindumps will have to suffice as a review point given the issue is also reproducible in 7.6. Further, I tried master a few days and today, each time install was corrupt with multiple download attempts (not local issue): https://dev-builds.libreoffice.org/daily/master/MacOSX-aarch64@tb94-TDF/
(In reply to Chris Peñalver from comment #13) > Hence, I think the spindumps will have to suffice as a review point given > the issue is also reproducible in 7.6. Further, I tried master a few days > and today, each time install was corrupt with multiple download attempts > (not local issue): > https://dev-builds.libreoffice.org/daily/master/MacOSX-aarch64@tb94-TDF/ The nightly builds are not codesigned so you have to invoke the following Terminal command on the .dmg file before you open it: xattr -d com.apple.quarantine /path/where/you/downloaded/dmg/file
Created attachment 188642 [details] Spindump.txt Reproduced in below, same workarounds apply: Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: e26aeb882dd236adf19679d5df9b7ba5da1ed226 CPU threads: 8; OS: Mac OS X 13.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Thank you for your spin dump for 24.2. Unfortunately, it looks the same to me as the earlier spin dumps. After looking through the spin dumps earlier today, it appears to me that LibreOffice is spending a lot of time in GetTextArray() in SvxFont::QuickGetTextSize() so I have uploaded the following patch that adds optional logging before and after the GetTextArray() calls in SvxFont::QuickGetTextSize(): When this new logging is enabled and you run LibreOffice in a Terminal, it will display pairs of messages for each GetTextArray() call when you double click in the frame and when you save with the cursor in the frame like below: info:editeng.quicktextsize:22053:7678595:editeng/source/items/svxfont.cxx:482: SvxFont::QuickGetTextSize before GetTextArray(): Case map: 0 Fix kerning: 0 info:editeng.quicktextsize:22053:7678595:editeng/source/items/svxfont.cxx:485: SvxFont::QuickGetTextSize after GetTextArray(): Text length: 222 Text size: 31119x295 What will be interesting to see is if the bug filer sees any pauses between the "before" and "after" messages or if the "Text size" returned has any unusual (e.g. negative) values. I will post again when the logging code is in the nightly 24.2 build along with instructions on how to enable this new logging in a Terminal.
I forgot to include the link to the logging patch: https://gerrit.libreoffice.org/c/core/+/155072
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ccc31ed4d96bada134d08046f22f64c095a29041 tdf#156470 add SAL_INFO calls for debugging It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
So the new logging should be available starting tomorrow's 01 August 2023 nighty master builds: https://dev-builds.libreoffice.org/daily/master/ The nightly builds are not codesigned so you have to invoke the following Terminal command on the .dmg file before you open it: xattr -d com.apple.quarantine /path/where/you/downloaded/dmg/file @Chris Peñalver Would it be possible to install the above nightly master build when it becomes available and do the following steps?: 1. Open a Terminal window and execute the following command. This enables the new log messages: export SAL_LOG="+INFO.editeng.quicktextsize+WARN" 2. Run LibreOfficeDev.app in the same Terminal by executing the following command: /Applications/LibreOfficeDev.app/Contents/MacOS/soffice 3. Open the attached test.odt, double-click in the bottom frame, and save. You should see lots of messages in the Terminal. The ones that we are interested in will be pairs in the following format: info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:482: SvxFont::QuickGetTextSize before GetTextArray(): Case map: 0 Fix kerning: 0 info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:485: SvxFont::QuickGetTextSize after GetTextArray(): Text length: 80 Text size: 11172x295 4. If LibreOffice hangs, watch the log messages in the Terminal window. The first of each pair of messages has "before" in the message and the second of the pair has "after". Do you see at any point, a noticeable pause between the "before" and the matching "after" message appear in the Terminal? Or, does an endless number of these message pairs keeping appearing in the Terminal?
(In reply to Patrick Luby from comment #19) > Do you see at any point, a noticeable pause between the "before" and the > matching "after" message appear in the Terminal? Or, does an endless number > of these message pairs keeping appearing in the Terminal? I forgot to add: can you try to copy the last 10 or so lines of these message pairs during the hang and paste them into this bug? For example, here are the last lines while I was saving test.odt. Note, though, that it did not hang so your output may (I hope) be slightly different than my output: info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:482: SvxFont::QuickGetTextSize before GetTextArray(): Case map: 0 Fix kerning: 0 info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:485: SvxFont::QuickGetTextSize after GetTextArray(): Text length: 145 Text size: 20302x295 info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:482: SvxFont::QuickGetTextSize before GetTextArray(): Case map: 0 Fix kerning: 0 info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:485: SvxFont::QuickGetTextSize after GetTextArray(): Text length: 80 Text size: 11172x295 info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:482: SvxFont::QuickGetTextSize before GetTextArray(): Case map: 0 Fix kerning: 0 info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:485: SvxFont::QuickGetTextSize after GetTextArray(): Text length: 15 Text size: 2041x295 info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:482: SvxFont::QuickGetTextSize before GetTextArray(): Case map: 0 Fix kerning: 0 info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:485: SvxFont::QuickGetTextSize after GetTextArray(): Text length: 4 Text size: 562x295 info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:482: SvxFont::QuickGetTextSize before GetTextArray(): Case map: 0 Fix kerning: 0 info:editeng.quicktextsize:98043:8833589:editeng/source/items/svxfont.cxx:485: SvxFont::QuickGetTextSize after GetTextArray(): Text length: 9 Text size: 1186x295
Created attachment 188725 [details] warn.txt Snipped out what appears desired. Rest is just repeat of same for 600MB until I force quit terminal command. Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 47ca3f1f762352b488d58b3bf23d5776576f1cca CPU threads: 8; OS: Mac OS X 13.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to Chris Peñalver from comment #21) > Snipped out what appears desired. Rest is just repeat of same for 600MB > until I force quit terminal command. So it sounds like GetTextArray() isn't blocking or slow. Instead, the problem appears to be that LibreOffice is invoking GetTextArray() for the same three paragraphs repeatedly. In other words, there is an infinite loop higher up on the call stack. I have seen this type of bug in a different portion of the Writer code in tables with lengthly text in cells. In that case, the Writer code would keep measuring the size of text within a cell and would repeat the measuring over and over as it tried to find the "right" place to put line breaks. I suspect that something similar is going on here. So, next step is to see if we can narrow down which function higher up the stack is going into an infinite text layout loop. From your last spin dump, the following are the next functions for me to look at: XMLTextParagraphExport::exportParagraph() in xmloff SvxUnoTextRangeEnumeration::SvxUnoTextRangeEnumeration() in editeng Adding @Mike Kaganski and @Noel Grandin in case they have any suggestions for where to look in these two functions. From their commit comments, it seems there is some cases of duplicate IDs when exporting. Maybe this is another case that we need to handle?
(In reply to Patrick Luby from comment #22) > > I suspect that something similar is going on here. So, next step is to see So this is most likely some kind of writer layout loop. I am afraid that without a reproducer document there is nothing useful we can do to debug it.
(In reply to Noel Grandin from comment #23) > So this is most likely some kind of writer layout loop. > I am afraid that without a reproducer document there is nothing useful we > can do to debug it. I agree. Of course, the problem is that we can't reproduce it even with the bug filer's document. This makes me think that whichever code is going into an infinite loop is very sensitive to font metrics. GetTextArray() appears to be returning quickly for the bug filer so I suspect that once we find where the infinite loop is occurring, I'll have to use Writer's infamous "quit after N tries" approach in sw/source/core/layout/layact.cxx. I may be wrong, but this fix is just so similar to the Writer "text too long, try again with shorter text, now text too short, so try again with longer text" loops that crop up every so often. My feeling is that this type of bug is more common on macOS than other platforms but who knows. I think I will need to walk through the above two functions in a debugger and see if I find any conditions that look anything like a loop restart *or* an invalidate call of some sort.
(In reply to Chris Peñalver from comment #11) > Created attachment 188626 [details] > test.odt The drawing object, "Text frame 2", uses an less common font: Inconsolata Likely the font needs to be installed, to be able reproduce the problem. Font substitution mask the problem. The font itself could contain wrong information, about spacing and such. May even depend on the exact font version Didn't test the hypothesis myself. Font appears to be open source https://github.com/googlefonts/Inconsolata
(In reply to Telesto from comment #25) > The drawing object, "Text frame 2", uses an less common font: Inconsolata > Likely the font needs to be installed, to be able reproduce the problem. > Font substitution mask the problem. The font itself could contain wrong > information, about spacing and such. May even depend on the exact font > version > > Didn't test the hypothesis myself. Font appears to be open source > https://github.com/googlefonts/Inconsolata Thank you for the link. I had found that font earlier and installed it. Font rendering changed noticeably in LibreOffice so I assumed that LibreOffice was actually rendering with that font, but I still couldn't reproduce the bug which made me even more curious. The interesting thing is that logging messages that you posted aren't unreasonable values. So, I think this is a very, very subtle bug so I'll continue to look for a "stop the loop, it isn't getting to get any more precise" fix. One question for you: in https://bugs.documentfoundation.org/attachment.cgi?id=188626, there are no spaces within paragraphs. Is this the same in your private document? I ask because multi-line text with no spaces would support my theory that LibreOffice is getting in an infinite loop trying to find the ideal line break. Not that that would fix the bug, but it is one more data point that might help.
(In reply to Patrick Luby from comment #26) > One question for you: in > https://bugs.documentfoundation.org/attachment.cgi?id=188626, there are no > spaces within paragraphs. Is this the same in your private document? I ask > because multi-line text with no spaces would support my theory that > LibreOffice is getting in an infinite loop trying to find the ideal line > break. Not that that would fix the bug, but it is one more data point that > might help. Apologies for the accidental wild goose chase w/ attached doc. There are spaces within paragraphs. If you have access, please feel free to delete it as to not confuse others. Thanks for the attention on this issue.
(In reply to Chris Peñalver from comment #27) > Apologies for the accidental wild goose chase w/ attached doc. There are > spaces within paragraphs. If you have access, please feel free to delete it > as to not confuse others. > > Thanks for the attention on this issue. No worries. I am a retired volunteer who specializes in debugging (don't ask me to write a new feature, I'll literally have blank page syndrome). This bug is intriguing because it triggers an infinite loop. Thank you for your patience. I can't promise that I'll fix this bug, but my gut feel is that this is solvable. The fix will likely be one line of code, yet finding that magic line is the slow, tedious part.
If the spindumps are accurate, this is looping in XMLTextParagraphExport::exportTextContentEnumeration which is very odd, because that is not a layout loop. Patrick, is there no way to do some kind of core dump analysis of the crash on Chris' machine?
I don't think that's the problem. There is no crash. The spin dumps are really just samples. From the spin dumps, I'm seeing it as an infinite loop. The format of spin dumps on macOS is really tricky to parse, but it is clear that there is no blocking. The spin dumps are full of repeating "measure text size" calls and the bug filers experience is the same.