Bug 158945 - Calc: crash when entering text in a cell
Summary: Calc: crash when entering text in a cell
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.5.9.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard: target:24.8.0
Keywords:
: 159650 (view as bug list)
Depends on:
Blocks: Skia Crash
  Show dependency treegraph
 
Reported: 2023-12-31 09:17 UTC by Greg Skyles
Modified: 2024-05-16 13:52 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file to reproduce the problem (9.73 KB, application/vnd.oasis.opendocument.spreadsheet)
2023-12-31 09:19 UTC, Greg Skyles
Details
Backtrace of the crash (6.79 KB, text/plain)
2023-12-31 10:32 UTC, Greg Skyles
Details
Backtrace testing with Win-x86_64@tb78-pollux-TDF (8.11 KB, text/plain)
2024-01-02 14:21 UTC, Greg Skyles
Details
Backtrace from dev build of 5-jan-2024 (8.11 KB, text/plain)
2024-01-06 15:53 UTC, Greg Skyles
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Skyles 2023-12-31 09:17:07 UTC
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
Comment 1 Greg Skyles 2023-12-31 09:19:33 UTC
Created attachment 191664 [details]
Test file to reproduce the problem
Comment 2 Greg Skyles 2023-12-31 10:32:48 UTC
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.
Comment 3 Julien Nabet 2023-12-31 11:35:11 UTC
Since the pb seems related to Skia rendering, could you follow https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_(_Skia_) ?
Comment 4 Greg Skyles 2023-12-31 15:29:58 UTC
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
Comment 5 Julien Nabet 2023-12-31 15:33:04 UTC
(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.
Comment 6 Greg Skyles 2023-12-31 16:03:11 UTC
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
Comment 7 Julien Nabet 2023-12-31 16:37:02 UTC
Thank you for the feedback, the patch for the workaround is here:
https://gerrit.libreoffice.org/c/core/+/161503
Comment 8 ady 2023-12-31 21:42:01 UTC
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.
Comment 9 Mike Kaganski 2024-01-01 06:21:07 UTC
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
Comment 10 Julien Nabet 2024-01-01 11:24:23 UTC
(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.
Comment 11 Julien Nabet 2024-01-01 11:26:58 UTC
(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.
Comment 12 Mike Kaganski 2024-01-01 12:01:40 UTC
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!
Comment 13 Commit Notification 2024-01-02 04:57:04 UTC
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.
Comment 14 Greg Skyles 2024-01-02 14:20:46 UTC
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.
Comment 15 Greg Skyles 2024-01-02 14:21:38 UTC
Created attachment 191698 [details]
Backtrace testing with Win-x86_64@tb78-pollux-TDF
Comment 16 ady 2024-01-02 16:24:12 UTC
(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
Comment 17 Greg Skyles 2024-01-03 00:52:22 UTC
OK, I will do that.
Comment 18 Xisco Faulí 2024-01-05 09:04:19 UTC
(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
Comment 19 Greg Skyles 2024-01-06 15:50:04 UTC
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.
Comment 20 Greg Skyles 2024-01-06 15:53:21 UTC
Created attachment 191787 [details]
Backtrace from dev build of 5-jan-2024
Comment 21 Mike Kaganski 2024-01-08 03:40:18 UTC
(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.
Comment 22 Commit Notification 2024-01-08 14:00:20 UTC
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.
Comment 23 Julien Nabet 2024-01-08 14:03:43 UTC
(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).
Comment 24 Greg Skyles 2024-01-09 00:08:31 UTC
OK, happy to test anything, now that I have all the infrastructure set up.
Comment 25 Stéphane Guillou (stragu) 2024-01-10 23:40:27 UTC
Greg, did you test previous version of LO? Would for example 7.5 work as expected?
Comment 26 Greg Skyles 2024-01-12 05:32:10 UTC
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.
Comment 27 Stéphane Guillou (stragu) 2024-03-01 00:58:43 UTC
*** Bug 159650 has been marked as a duplicate of this bug. ***
Comment 28 Stéphane Guillou (stragu) 2024-03-01 01:03:36 UTC
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).
Comment 29 gpapotti 2024-03-01 08:14:54 UTC
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
Comment 30 Stéphane Guillou (stragu) 2024-03-01 10:36:29 UTC
(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?
Comment 31 Julien Nabet 2024-03-01 10:47:27 UTC
(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
Comment 32 V Stuart Foote 2024-03-01 12:57:53 UTC
(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.
Comment 33 V Stuart Foote 2024-03-01 13:00:37 UTC
(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 ?
Comment 34 gpapotti 2024-03-01 16:00:52 UTC
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
Comment 35 gpapotti 2024-03-01 16:02:53 UTC
I just posted the WORKING version.
The previous version was not working.
Comment 36 Commit Notification 2024-03-02 08:15:27 UTC
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.