Summary: | Calc: crash when entering text in a cell | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Greg Skyles <greg_skyles> |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | gpapotti, greg_skyles, serval2412, stephane.guillou, vsfoote, xiscofauli |
Priority: | medium | ||
Version: | 7.5.9.2 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Windows (All) | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=158714 https://bugs.documentfoundation.org/show_bug.cgi?id=158129 https://bugs.documentfoundation.org/show_bug.cgi?id=161135 |
||
Whiteboard: | target:24.8.0 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 129062, 133092 | ||
Attachments: |
Test file to reproduce the problem
Backtrace of the crash Backtrace testing with Win-x86_64@tb78-pollux-TDF Backtrace from dev build of 5-jan-2024 |
Description
Greg Skyles
2023-12-31 09:17:07 UTC
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. |