Description: I can reliably cause LO to crash by opening a simple ods file, pressing Enter, and then typing text. key word: EDITING Steps to Reproduce: 1. Open my test ods file (attached). It has just the word "test" in A1 and the cursor is on A1 upon opening the file. 2. Press the Enter key; the cursor moves to A2. 3. Type any letters (I usually type "test"). Actual Results: No letters show up, the 'whirly' busy cursor shows up for a few seconds, and the application window disappears. Attempting to reopen the file brings up the document recovery window. Expected Results: The word "test" appears in cell A2 and the application continues to function. Reproducible: Always User Profile Reset: Yes Additional Info: It seems that if I am careful to always click the input line before entering text, it works fine. In this respect this is similar to 158714, although no diacritical characters are involved here, and I'm on Windows 11. I tried resetting my profile. The problem went away while running in Safe Mode. However, after resetting to factory defaults and ticking the two boxes there, the problem came back after leaving safe mode. My environment: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-AU (en_AU); UI: en-US Calc: threaded Processor 13th Gen Intel(R) Core(TM) i7-1360P 2.20 GHz Installed RAM 32.0 GB (31.6 GB usable) System type 64-bit operating system, x64-based processor Pen and touch Touch support with 10 touch points Edition Windows 11 Pro Version 22H2 Installed on 27/08/2023 OS build 22621.2861 Experience Windows Feature Experience Pack 1000.22681.1000.0
Created attachment 191664 [details] Test file to reproduce the problem
Created attachment 191665 [details] Backtrace of the crash The Crash Report Tool wasn't showing up, so I followed the instructions for getting a backtrace.
Since the pb seems related to Skia rendering, could you follow https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_(_Skia_) ?
Not the clearest document to follow, however this is what I did. 1. Updated my Iris XE driver from 31.0.101.4032 to ...4575, the latest version supported by my OEM. This made no difference in the problem. 2. Set "Force Skia software rendering" in Tools>Options>LibreOffice>View. This seems to have fixed the problem; my crash reproduction steps no longer work. The file skia.log contains only these two lines: RenderMethod: raster Compiler: Clang
(In reply to Greg Skyles from comment #4) > Not the clearest document to follow, however this is what I did. > > 1. Updated my Iris XE driver from 31.0.101.4032 to ...4575, the latest > version supported by my OEM. This made no difference in the problem. > > 2. Set "Force Skia software rendering" in Tools>Options>LibreOffice>View. > This seems to have fixed the problem; my crash reproduction steps no longer > work. > > The file skia.log contains only these two lines: > > RenderMethod: raster > Compiler: Clang Could you provide the skia.log when it crashes (so not after "Force Skia software rendering")? Indeed, the goal is to retrieve technical info from the graphic card so we can blacklist it for Skia hardware rendering.
Ah, that makes more sense. Here you go- RenderMethod: vulkan Vendor: 0x8086 Device: 0xa7a0 API: 1.3.250 Driver: 0.405.479 DeviceType: integrated DeviceName: Intel(R) Iris(R) Xe Graphics Denylisted: no
Thank you for the feedback, the patch for the workaround is here: https://gerrit.libreoffice.org/c/core/+/161503
Please forgive my ignorance... Before blacklisting, shouldn't this be actually confirmed by someone else (with same HW)? I mean, Intel(R) Iris(R) Xe Graphics is quite a popular device, isn't it? I don't know how much of a difference the exact "Device" code (0xa7a0) makes in the described behavior, or the precise "Driver" version. FWIW, I briefly had the possibility to test on a "Device: 0xa7a1" (note the last "1") with attachment 191664 [details] while _not_ using "Force Skia software rendering" on LO 7.6.4.1 on Windows, and there was no crash.
Note that SkiaSalGraphicsImpl::postDraw (vcl/skia/gdiimpl.cxx) has two calls to abort. The second one for 'abandoned' [1] case, which is likely not something we can do much about, aside from debugging on the relevant HW/SW combination (unlikely) or blacklist; but the first one is a recoverable 'oomed' [2] case, which maybe could be treated like this: there is a precaution above, checking pendingOperationsToFlush value. We could try to ignore the error then (pretend that we have drawn it OK), and decrease the value it compares to - e.g., halve it? So that the next time it would flush on 500 instead of 1000 pending operations. And so on. The oomed is documented to be implemented for Vulkan; and to be reset automatically until a next OOM error from HW. Julien: do you think it would be reasonable? [1] https://api.skia.org/classGrDirectContext.html#a5c1c5c644a82f21ce2af991b4f451348 [2] https://api.skia.org/classGrDirectContext.html#a46cacd2825836fd0305ee183e6fd276e
(In reply to Mike Kaganski from comment #9) > ... > The oomed is documented to be implemented for Vulkan; and to be reset > automatically until a next OOM error from HW. Julien: do you think it would > be reasonable? > ... It seems right but I must recognize I only know how to blacklist a device and know nothing about Skia. It seems the only expert was Luboš and since he's nowhere to be seen and now that Skia has made its way in LO internals, I expect some difficult times. Anyway, if you got an idea to fix this and considering Ady's comment, I abandoned the patch.
(In reply to ady from comment #8) > Please forgive my ignorance... > > Before blacklisting, shouldn't this be actually confirmed by someone else > (with same HW)?... IMHO you're right in 95% of cases but since there was a backtrace + the fact that there've been quite some bugs related to Skia, I thought it could be useful. Anyway, as indicated in my previous comment, I abandoned the patch for the moment. Like everybody I suppose, I'd prefer a real fix instead of some workaround patch as I did.
https://gerrit.libreoffice.org/c/core/+/161516 is my take. Greg Skyles: since this is a blind fix, I cannot test it locally. I ask you to do two things: 1. Download and install a today's daily build from https://dev-builds.libreoffice.org/daily/master/current.html It has no fix in it today, and so it is important to check that you can reproduce your problem *there*, i.e. that it indeed crashes on your system without any patches. 2. When my patch is merged (I think it will happen later today), this but will receive a commit notification. After that, on the next day there usually is an updated daily; please download that next-day daily with the patch, and repeat the test - it is important to check if it will actually fix the issue on your system. Thank you!
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/14e49062012f8699125422cc8a82a22b26f43143 tdf#158945: blind fix (try to decrease pending operations limit) It will be available in 24.8.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.
I retested with Win-x86_64@tb78-pollux-TDF. Not sure if this had the patch in or not. The about info is Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e71934471442a8bbba7e661d3ebe5f708627c5d6 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-AU (en_AU); UI: en-US Calc: threaded The issue is not fixed with this version, it still crashes on entering text. The backtrace looks mostly the same. I'll post it as well.
Created attachment 191698 [details] Backtrace testing with Win-x86_64@tb78-pollux-TDF
(In reply to Greg Skyles from comment #14) > I retested with Win-x86_64@tb78-pollux-TDF. Not sure if this had the patch > in or not. The about info is Based on the date and time of the commits, I think the build you tested does not include the patch. I would suggest trying again (if it's not too much trouble) when a new successful build is available, sometime in the coming days – see the date of each "daily" (master) download. For your next download, you might want to test/select a different Win-x86_64 server to download from (with build date not before 2024-01-03). https://dev-builds.libreoffice.org/daily/master/current.html
OK, I will do that.
(In reply to Greg Skyles from comment #14) > I retested with Win-x86_64@tb78-pollux-TDF. Not sure if this had the patch > in or not. The about info is > > Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: e71934471442a8bbba7e661d3ebe5f708627c5d6 > CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: > win > Locale: en-AU (en_AU); UI: en-US > Calc: threaded > > The issue is not fixed with this version, it still crashes on entering text. > The backtrace looks mostly the same. I'll post it as well. Hi Greg, yep, it doesn't contain the commit. You should download a more recent one and retest
Hmm, I tried with Win-x86_64@tb77-TDF from 2024-01-05 Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5056da285da2f130d741add1f8432cd590116a96 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-AU (en_AU); UI: en-US Calc: threaded And it has the same behaviour. I will add the backtrace.
Created attachment 191787 [details] Backtrace from dev build of 5-jan-2024
(In reply to Greg Skyles from comment #20) Pity; well, it just means that you likely see not the "oomed" case, but the unrecoverable "abandoned" case, which can't be debugged / fixed blindly. Then the change proposed by Julien in comment 7 might be the only reasonable solution for the time being.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4f1b9d79c0467dbc0b49eb62bf56f83392a9d33f Related tdf#158945: blacklist Intel Iris XE for Skia hardware rendering It will be available in 24.8.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.
(In reply to Commit Notification from comment #22) > Julien Nabet committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 4f1b9d79c0467dbc0b49eb62bf56f83392a9d33f > ... Since Mike's patch didn't help in your case, I restored and pushed the workaround (ie blacklisting this card).
OK, happy to test anything, now that I have all the infrastructure set up.
Greg, did you test previous version of LO? Would for example 7.5 work as expected?
Hi @stragu, I just tried the 7.5.9.2 release. It has the same problem. I don't know if this is useful or not, but it crashed in a slightly different way. When I first ran it, it displayed the "this is the first time you are using 7.5..." banner, which I dismissed, along with the tip of the day. I then tried my test, which induced the crash. On crashing, it first froze the cursor for a second or so, then the display updated to show the new to 7.5 banner again, then the window closed.
*** Bug 159650 has been marked as a duplicate of this bug. ***
Confirmed via duplicate bug 159650, which has same device: Calc: threaded Skia log: RenderMethod: vulkan Vendor: 0x8086 Device: 0xa7a0 API: 1.3.235 Driver: 0.404.4032 DeviceType: integrated DeviceName: Intel(R) Iris(R) Xe Graphics Denylisted: no As ady noted, see also bug 158129 (multiple graphics devices).
After reading your comments, I downloaded and installed latest drivers from Intel (my laptop is an LG GRAM 17 (17Z90R) and no updates were released by LG). Update worked like a charm and SOLVED the problem. This is the version I installed: Description: This download installs Intel® Graphics Driver 31.0.101.5333 (WHQL Certified) for Intel® Arc™ A-Series Graphics, Intel® Iris® Xe Graphics, and Intel® Core™ Ultra Processors with Intel® Arc™ Graphics. Version: 31.0.101.5333Release date: February 26, 2024Size: 681.18 MB Don't know if you can conditionally blacklist hardware based on installed driver version; it would be the best solution. Thanks for your patience. GP
(In reply to gpapotti from comment #29) > After reading your comments, I downloaded and installed latest drivers from > Intel [...]. Update worked like a charm and SOLVED the problem. That's excellent news! Thank you for testing and reporting. Greg: could you please confirm that a driver update does fix the issue for you too? Julien and Mike: do you think a driver-version-dependent blacklisting is worth the effort, or should we just call this resolved?
(In reply to Stéphane Guillou (stragu) from comment #30) > ... > Julien and Mike: do you think a driver-version-dependent blacklisting is > worth the effort, or should we just call this resolved? I've submitted this patch: https://gerrit.libreoffice.org/c/core/+/164186
(In reply to gpapotti from comment #29) > After reading your comments, I downloaded and installed latest drivers from > Intel (my laptop is an LG GRAM 17 (17Z90R) and no updates were released by > LG). Update worked like a charm and SOLVED the problem. > This is the version I installed: > > Description: > This download installs Intel® Graphics Driver 31.0.101.5333 (WHQL Certified) > for Intel® Arc™ A-Series Graphics, Intel® Iris® Xe Graphics, and Intel® > Core™ Ultra Processors with Intel® Arc™ Graphics. > Version: > 31.0.101.5333Release date: > February 26, 2024Size: > 681.18 MB > > Don't know if you can conditionally blacklist hardware based on installed > driver version; it would be the best solution. > Thanks for your patience. > GP Actually to denylist this driver/gpu pair, we need the content of your current skia.log, the 31.0.101.5333 is the marketing release for the driver.
(In reply to V Stuart Foote from comment #32) > (In reply to gpapotti from comment #29) > > After reading your comments, I downloaded and installed latest drivers from > > Intel (my laptop is an LG GRAM 17 (17Z90R) and no updates were released by > > LG). Update worked like a charm and SOLVED the problem. > > This is the version I installed: > > > > Description: > > This download installs Intel® Graphics Driver 31.0.101.5333 (WHQL Certified) > > for Intel® Arc™ A-Series Graphics, Intel® Iris® Xe Graphics, and Intel® > > Core™ Ultra Processors with Intel® Arc™ Graphics. > > Version: > > 31.0.101.5333Release date: > > February 26, 2024Size: > > 681.18 MB > > > > Don't know if you can conditionally blacklist hardware based on installed > > driver version; it would be the best solution. > > Thanks for your patience. > > GP > > Actually to denylist this driver/gpu pair, we need the content of your > current skia.log, the 31.0.101.5333 is the marketing release for the driver. Is that Calc: threaded Skia log: RenderMethod: vulkan Vendor: 0x8086 Device: 0xa7a0 API: 1.3.235 Driver: 0.404.4032 DeviceType: integrated DeviceName: Intel(R) Iris(R) Xe Graphics Denylisted: no you posted on bug 159650 ?
Here it is RenderMethod: vulkan Vendor: 0x8086 Device: 0xa7a0 API: 1.3.275 Driver: 0.405.1237 DeviceType: integrated DeviceName: Intel(R) Iris(R) Xe Graphics Denylisted: no
I just posted the WORKING version. The previous version was not working.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/09f19a4c06dc389fde11fc79cf3f912a5199ed48 Related tdf#158945: Calc: crash when entering text in a cell It will be available in 24.8.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.