Description: The problem started when I changed the monitor to the 4K model about a year ago. I connected my old monitor as a second. I set 4K resolution on new monitor with scale 175% and the old one works with 1920x1200 with 100% scale. I worked with documents like normal. Some edit, copy, paste and when I scrolled the document the app freezes for a few seconds and then closes. All opened documents close without any question about save, so all work withut save is lost. It happens on my PC at work and at home. Both have the same configurations of monutors (4K+1920x1200). It also was reported by my friend after buying 4K monitor. He has only one monitor. Steps to Reproduce: 1. Open any document in Writer, Calc or Impress 2. Edit like always 3. Scroll document with the mouse Actual Results: When scrolling the document in Writer, Calc or Impress the whole LibreOffice crashes. Without any warning or information about crash. All LibreOffice apps and all opened documents just close. The app first freezes, then after few seconds closes. Expected Results: It shouldn't crash :( Reproducible: Sometimes User Profile Reset: Yes Additional Info: I selected Writer but the problem exists also in Calc and Impress. The same problem exists in 7.5.2.2. It happend also in some previous versions. I don't remember all tested versions. I'm sure that I tested 7.4.3 (LibreOffice_7.4.3_Win_x64.msi) and some version from 7.3 line. Some time ago I made more tests by installing old version from download archive. I found that verion 7.2.6 (LibreOffice_7.2.6_Win_x64.msi) works properly without crashes. I send this information to my friend and he also uses this version without problems. I also noticed that 7.2.6 works stable after the uninstalling the previous one and installing this one then. When I installed 7.2.6 over the 7.4.3 it was no stable. About a month ago I decided to test the new version (7.5.1.2) and the problem returned. After first crash I deinstalled LibreOffice. Then deleted user profile in Windows. And installed 7.5.1.2 again. Today after crash I decided to write this bug report. If I can help with search of source of this bug generating some log/dump files please let me know how to do it. About the system: As I wrote all configurations with 4K monitors. Also all with Windows 10 Polish. All with NVIDIA graphics. The last words: Few minutes ago I deinstalled 7.5.2.2 and installed 7.2.7.2. I opened few documents (Writer, Calc and Impress). I scrolled them all. And it seems to be stable, like the 7.2.6.
Hi Marcin Thank you for your report. Could you please: - Paste here the info copied from Help > About LibreOffice (the version that crashes) - Check if the issue is related to Skia, by turning on the option "Force Skia software rendering" in Tools > Options > LibreOffice > View. Does it still crash?
Like always with this kind of problems: When the crash is required it does not happen :/ I uninstalled 7.2.7.2 and installed again 7.5.2.2, exact version: Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 24; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: CL threaded But as I wrote I tested many versions with this problem. Crashed a while ago when I opened the third document (Impress Presentation). I set the "Force Skia software rendering" and testing... I will be using version 7.5.2.2 and will let you know if the described failures continue after the change.
Hi, > - Check if the issue is related to Skia, by turning on the option "Force > Skia software rendering" in Tools > Options > LibreOffice > View. Does it > still crash? I changed to Skia/Render: Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 24; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: CL threaded and after a lot of scrolling it seems to be stable. I checked "the stable 7.2.6.2" and it is also Skia/Render: Version: 7.2.6.2 (x64) / LibreOffice Community Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: threaded So the Vulcan is the problem? Does "the default" of this setting was changed between 7.2 and newer? Regards, Marcin
If it would be Calc specific it would be bug 149527. This appears to be driver/graphic card related
@Marcin: could you apply https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_(_Skia_) ?
Hello, @Stéphane Guillou (stragu): Big thanks for help :) I tested LO applications on both my computers (at home and at work) and after switching to Skia/Raster I didn't see a crash anymore :) After switching to Skia/Vulcan and a minute or two of scrolling in Writer or Calc whole LO crashed. Content of skia.log after crash: RenderMethod: vulkan Vendor: 0x10de Device: 0x21c4 API: 1.3.205 Driver: 516.376.0 DeviceType: discrete DeviceName: NVIDIA GeForce GTX 1660 SUPER Denylisted: no I made few test installing and uninstalling different versions of LibreOffice 7: - If I deleted the user profile after uninstalling, then Skia/Vulcan was always enabled. - If I left the user profile untouched after uninstalling 7.4 or 7.5 and then installing 7.2 the settings changed to Skia/Raster. The above behavior looks a bit strange, but it was the reason why I was still using version 7.2. Reinstallation without deleting the user profile ensured the stability of the application even though as a regular user I knew nothing about Skia and Vulkan ;) And finally: As I wrote at the beginning of this bug report, the problem appeared not after the LO update, but after changing the monitor to a 4K model and turning on the resolution of 3840x2160 and scaling 175%. On exactly the same system and software, but with an FHD monitor and 100% scaling, everything was fine. If I understood everything correctly, then the problem is not necessarily the LibreOffice code, but rather the graphics driver? However, it seems to me that LO should detect such a problem somehow and can at least suggest the user to switch to Skia/Raster after a failure. Regards, Marcin
[Automated Action] NeedInfo-To-Unconfirmed
Please let the earliest version affected. The bug can be due to: - LO code - Skia code - graphic driver code - Windows libs Do you confirm you got last version of your graphic driver? If it's the case, I can provide a patch just to blacklist the device id you use as workaround so you'll be sure not to use Vulkan rendering of Skia.
I don't think blacklisting is the solution. I have observed this issue on 3 machines with: - Quadro P400 - GeForce GTX 1660 SUPER - GeForce GTX 960 It took me a while to write this bug report, but I bought a 4K monitor in March 2022. I accidentally found the following workaround for my problem: "uninstall newer version and install 7.2", but a while ago I decided to try the new 7.5 and found that the problem persists. Then I wrote about it here. I understand that a bug in one of the listed software components may be the cause. And actually enabling Skia/Raster solves the problem for me. But maybe it would be possible to somehow recognize this problem from LO's side and react to it? Maybe someone with more knowledge than me will be able to recreate the described situation and collect more data.
(In reply to Marcin from comment #9) > I don't think blacklisting is the solution. You're right in principle, except there somewhat of a reliance on the expertise of a single developer. There is nobody else who is familiar with the code (as far I'm aware). He is not active at this point in time... So blacklisting is the next best - band-aid - solution..
Created attachment 187281 [details] Crash information from Windows Event Log
For test I've updated NVIDIA drivers to the newest ones (531.79) and Vulcan crashed again: RenderMethod: vulkan Vendor: 0x10de Device: 0x21c4 API: 1.3.236 Driver: 531.316.0 DeviceType: discrete DeviceName: NVIDIA GeForce GTX 1660 SUPER Denylisted: no I found some crash info in Windows Event Log. Attached.
Thank you for the test with the updated driver. Could you also provide skia.log for the 2 other machines since they must have a different device id? Indeed, it would allow to make 1 blacklisting patch for the 3 devices. Again it's just a band-aid/workaround not a real fix. About your idea of detecting if there's a pb with Vulkan to tell LO using Raster part, I think I read someone was going to work on it but I don't know where and when I read this.
From the second PC: RenderMethod: vulkan Vendor: 0x10de Device: 0x13c2 API: 1.3.236 Driver: 531.272.0 DeviceType: discrete DeviceName: NVIDIA GeForce GTX 970 Denylisted: no I'll try to provide the log content from the third machine, but it's used by a slightly less tech-savvy friend and I'm not sure if he'll succeed :) BTW: Every time after a crash, the "document recovery" window appears (I have a PL interface and I'm not sure about the name). Maybe something like this can be done: When the "document recovery" window is displayed (crash detected), let's check the contents of the skia.log file. If the file contains: "RenderMethod: vulkan" and possibly additionally "Vendor: 0x10de", then display the following message to the user: LibreOffice crash detected. You are using the Skia/Vulkan interface. Check if changing to Skia/Raster will not fix the problem. With the link to: https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_(_Skia_)
The third device: RenderMethod: vulkan Vendor: 0x10de Device: 0x1cb3 API: 1.3.205 Driver: 516.376.0 DeviceType: discrete DeviceName: Quadro P400 Denylisted: no Tested on LO 7.4.7.2. Crashed on Skai/Vulcan. Works fine with forced Skia/Render.
Thank you for the last feedback, I've submitted a patch on gerrit here: https://gerrit.libreoffice.org/c/core/+/151801
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/880165e9c0786d5c70d5bf5804c17772e5f22f61 tdf#155143: blacklist 3 Nvidia cards for Skia hardware rendering It will be available in 7.6.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 don't know if it worths it to cherry-pick on 7.5 since it's just a workaround. Let's put this one to FIXED then even if, again, it's just a bandaid.
This probably isn't the place for such considerations, but I wanted to share my thoughts: LibreOffice is an office suite. Most users just want to create a larger or smaller document, or do some calculations in a spreadsheet. And they have little idea about "how the computer works". If problems like the one described here occur when Skia/Vulkan is used for rendering, then maybe Skia/Raster should be the default setting?
(In reply to Marcin from comment #19) > This probably isn't the place for such considerations, but I wanted to share > my thoughts: > > LibreOffice is an office suite. Most users just want to create a larger or > smaller document, or do some calculations in a spreadsheet. And they have > little idea about "how the computer works". If problems like the one > described here occur when Skia/Vulkan is used for rendering, then maybe > Skia/Raster should be the default setting? I fully agree. There a multiple known issues causing crashes leading to dataloss. * Problems seem to be laptops with integrated+dedicated GPUs * Issues around external monitor setups The performance gain isn't worth the bad experience
(In reply to Telesto from comment #20) > (In reply to Marcin from comment #19) > > This probably isn't the place for such considerations, but I wanted to share > > my thoughts: > > > > LibreOffice is an office suite. Most users just want to create a larger or > > smaller document, or do some calculations in a spreadsheet. And they have > > little idea about "how the computer works". If problems like the one > > described here occur when Skia/Vulkan is used for rendering, then maybe > > Skia/Raster should be the default setting? Completely agreed since there's no more Skia expert in LO now. > > I fully agree. There a multiple known issues causing crashes leading to > dataloss. > > * Problems seem to be laptops with integrated+dedicated GPUs > * Issues around external monitor setups > > The performance gain isn't worth the bad experience For this point, I suppose it depends on what you do.
Since I, as the submitter, should check the fix, I installed LibreOfficeDev: Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: f4c24da1e7f11664e0d2f688d2531f068e4a3bc0 CPU threads: 24; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: CL threaded UI render is set Skia/Raster regardless of setting "Force Skia software rendering" in Tools > Options > LibreOffice > View. The blacklist thus works as expected :)
I think the same problem. Again: NVIDIA, 4K screen, scale more then 100% (as I remember 225%). skia.log: RenderMethod: vulkan Vendor: 0x10de Device: 0x139b API: 1.3.194 Driver: 512.60.0 DeviceType: discrete DeviceName: NVIDIA GeForce GTX 960M Denylisted: no dump.ini: ProductName=LibreOffice Version=7.5.3.2 BuildID=9f56dff12ba03b9acd7730a5a481eea045e468f3 URL=https://crashreport.libreoffice.org/submit/ VulkanVendor=0x10de VulkanDevice=0x139b VulkanAPI=1.3.194 VulkanDriver=512.60.0 VulkanDeviceType=discrete VulkanDeviceName=NVIDIA GeForce GTX 960M UseSkia=true Language=pl-PL CPUModelName=Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz CPUFlags=sse3 pclmulqdq monitor ssse3 fma cpmxch16b sse41 sse42 movbe popcnt aes xsave osxsave avx f16c rdrand msr cx8 sep cmov clfsh mmx fxsr sse sse2 ht fsgsbase bmi1 avx2 bmi2 erms invpcid lahf abm syscall rdtscp MemoryTotal=16466792 kB I've tried also system with GTX 1060, but with standard monitor - 1680x1050, scale 100% - and seems to bo stable with vulcan render.
(In reply to Marcin from comment #23) > I think the same problem. Again: NVIDIA, 4K screen, scale more then 100% (as > I remember 225%). > > skia.log: > > RenderMethod: vulkan > Vendor: 0x10de > Device: 0x139b > API: 1.3.194 > Driver: 512.60.0 > DeviceType: discrete > DeviceName: NVIDIA GeForce GTX 960M > Denylisted: no => https://gerrit.libreoffice.org/c/core/+/153383 Michael: any idea whom to ping now about Skia pb? I mean since Luboš is nowhere to be seen (according to https://cgit.freedesktop.org/libreoffice/core/log/?qt=author&q=lunak, last patch was in 2022/09), there's nobody to fix Skia bugs. Should we disable Nvidia cards more widely instead of declaring each model one by one?
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/10cf2e7da6048eca7526149f4a2c824e7c3cfdfe Related tdf#155143: blacklist Nvidia GTX 960M for Skia hardware rendering 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.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/194a41889aa94600a59502ed2bac567183353253 Related tdf#155143: blacklist Nvidia GTX 960M for Skia hardware rendering It will be available in 7.6.0.0.beta2. 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 Julien Nabet from comment #24) > Should we disable Nvidia cards more widely instead of declaring each model one by one? IMHO: Locking all NVIDIA cards under Windows is not a bad idea. Maybe this will prompt the company to look into the driver side of things. On the other hand, the best solution for today would be: if ((NVIDIA) and (Windows) and (scale>100%)) then (force Skia/Raster), but I don't know how to write it in C++ :( BTW: I've tried to crash LO on GTX 1060 and standard monitor (scale=100%) and on Intel UHD Graphics on HiDPI (scale=150%) with Skia/Vulkan: without success ;)
(In reply to Marcin from comment #27) > (In reply to Julien Nabet from comment #24) > > Should we disable Nvidia cards more widely instead of declaring each model one by one? > > IMHO: Locking all NVIDIA cards under Windows is not a bad idea. Maybe this > will prompt the company to look into the driver side of things. See https://bugs.documentfoundation.org/show_bug.cgi?id=155143#c8, we don't know if Nvidia is the culprit. > > On the other hand, the best solution for today would be: if ((NVIDIA) and > (Windows) and (scale>100%)) then (force Skia/Raster), but I don't know how > to write it in C++ :( Don't know too but someone may know. > > BTW: I've tried to crash LO on GTX 1060 and standard monitor (scale=100%) > and on Intel UHD Graphics on HiDPI (scale=150%) with Skia/Vulkan: without > success ;) Hopefully, some Nvidia cards work with Skia/Vulkan, if not, there would be far much bugtrackers submitted :-)