Download it now!
Bug 132681 - SKIA crash when launching LO after having renamed LO profile
Summary: SKIA crash when launching LO after having renamed LO profile
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.0.1
Keywords: haveBacktrace
Depends on:
Blocks: Skia
  Show dependency treegraph
 
Reported: 2020-05-04 14:29 UTC by Julien Nabet
Modified: 2020-06-16 15:15 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
bt Windows (windbg) (20.34 KB, text/plain)
2020-05-04 14:30 UTC, Julien Nabet
Details
instdir\cache\skia.log (154 bytes, text/plain)
2020-05-06 12:08 UTC, Julien Nabet
Details
console logs with SAL_LOG=+INFO.vcl.skia (6.25 KB, text/plain)
2020-05-06 12:09 UTC, Julien Nabet
Details
bt on second step (15.35 KB, text/plain)
2020-05-19 12:33 UTC, Julien Nabet
Details
GPU details, old AMD HD 6450 no-Vulkan support nVIDIA GT 710 supported (2.88 KB, text/plain)
2020-05-19 23:30 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2020-05-04 14:29:16 UTC
Description:
On Win10 with master sources updated today 
commit 31a09e639f2769d29cd996b8e982fa14a3de78d8 (HEAD -> master, origin/master, origin/HEAD)
Author: LibreOfficiant <LibreOfficiant@sfr.fr>
Date:   Mon May 4 15:54:51 2020 +0200

    Update git submodules

    * Update helpcontent2 from branch 'master'
      to b2f0c674155a29174fca5acfa0c4036c3320fc6c
      - tdf#131416 Basic help pages

        - Redim
        - Type

I got a crash when launching LO after having renamed LO profile

Steps to Reproduce:
1. Rename LO directory profile
2. Launch LO


Actual Results:
Crash

Expected Results:
No crash


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 31a09e639f2769d29cd996b8e982fa14a3de78d8
Threads CPU : 4; OS : Windows 10.0 Build 18362; UI Render : Skia/Raster; VCL: win; 
Locale: fr-FR (fr_FR); Langue IHM : fr-FR
Calc: threaded
Comment 1 Julien Nabet 2020-05-04 14:30:22 UTC
Created attachment 160334 [details]
bt Windows (windbg)
Comment 2 Julien Nabet 2020-05-04 14:32:13 UTC
Just for information, I use:
soffice.bin

After having renamed LO profile:
- First time crash (see bt)
- Second time no crash but it doesn't start and no log
- Third time: error : Unknown IO error
- Fourth time: ok
Comment 3 Telesto 2020-05-04 23:02:43 UTC
Have noticed it too
Comment 4 Luboš Luňák 2020-05-06 11:23:56 UTC
I cannot reproduce this. The backtrace suggests that your Vulkan driver locks up and the first crash is the watchdog detecting it and aborting, but even after faking this I still cannot reproduce any follow-up crash.

You can try:
- check your instdir/cache/skia.log .
- run with SAL_LOG=+INFO.vcl.skia to see if something shows up
- check values of Skia-related entries in instdir/user/registrymodifications.xcu after the first crash
Comment 5 Julien Nabet 2020-05-06 12:08:53 UTC
Created attachment 160434 [details]
instdir\cache\skia.log
Comment 6 Julien Nabet 2020-05-06 12:09:30 UTC
Created attachment 160435 [details]
console logs with SAL_LOG=+INFO.vcl.skia
Comment 7 Julien Nabet 2020-05-06 12:15:04 UTC
registrymodifications.xcu contains only:
<?xml version="1.0" encoding="UTF-8"?>
<oor:items xmlns:oor="http://openoffice.org/2001/registry" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<item oor:path="/org.openoffice.Office.Common/VCL"><prop oor:name="ForceSkiaRaster" oor:op="fuse"><value>true</value></prop></item>
<item oor:path="/org.openoffice.Office.Linguistic/General"><prop oor:name="UILocale" oor:op="fuse"><value></value></prop></item>
<item oor:path="/org.openoffice.Office.Logging/Settings"><node oor:name="unopkg" oor:op="replace"><prop oor:name="LogLevel" oor:op="fuse"><value>2147483647</value></prop><prop oor:name="DefaultHandler" oor:op="fuse"><value>com.sun.star.logging.FileHandler</value></prop><node oor:name="HandlerSettings"><prop oor:name="FileURL" oor:op="fuse"><value>$(userurl)/$(loggername).log</value></prop></node><prop oor:name="DefaultFormatter" oor:op="fuse"><value>com.sun.star.logging.PlainTextFormatter</value></prop><node oor:name="FormatterSettings"></node></node></item>
<item oor:path="/org.openoffice.Setup/L10N"><prop oor:name="ooLocale" oor:op="fuse"><value>fr</value></prop></item>
<item oor:path="/org.openoffice.Setup/Office"><prop oor:name="ooSetupInstCompleted" oor:op="fuse"><value>true</value></prop></item>
</oor:items>

So ForceSkiaRaster = true (whereas I forced nothing), it's just after a reset of LO profile.
Comment 8 Julien Nabet 2020-05-12 12:30:06 UTC
Luboš: any information I could retrieve or test I could do to help investigation?
Comment 9 Telesto 2020-05-12 13:22:19 UTC
I'm seeing the same thing. However only when resetting the user profile in safe mode to factory settings (with both checkboxes checked). 
No issue when launching after deleting the profile.. Didn't try renaming

Version: 7.0.0.0.alpha1 (x64)
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU-threads: 4; Besturingssysteem: Windows 6.3 Build 9600; UI-render: Skia/Vulkaan; VCL: win; 
Locale: nl-NL (nl_NL); UI: nl-NL
Calc: threaded
Comment 10 Luboš Luňák 2020-05-19 10:22:20 UTC
(In reply to Julien Nabet from comment #2)
> After having renamed LO profile:
> - First time crash (see bt)

 I think this is most likely a driver problem and there's not much to do about it, the watchdog already handles fine that it locks up (minus the restart done once, which could be improved by blacklisting the card/driver).

> - Second time no crash but it doesn't start and no log
> - Third time: error : Unknown IO error

 So I consider these two to be possible problems. Can you provide more information about these (backtraces, logs)?
Comment 11 Telesto 2020-05-19 11:07:54 UTC
@Stuart V
How often do you need to launch LibreOffice after factory reset (in safe mode). 
- First time -> Quits.. no crash
- Second time no crash but it doesn't start
- Third time still nothing
- Fourth time: ok
Comment 12 Julien Nabet 2020-05-19 12:33:08 UTC
Created attachment 161004 [details]
bt on second step

I runned "make clean" then updated and built from scratch.
Now LO opens after the third launch (instead of fourth one).

1 : crash
2: nothing (I attached a bt)
3: ok

Remark: to launch LO, I use soffice.bin
To obtain this bt, I launched Windbg and used "Open executable" and chose soffice.bin.
Comment 13 V Stuart Foote 2020-05-19 13:02:33 UTC
(In reply to Telesto from comment #11)

Not having an issue. But I am noticing recently the Splash screen syncing/enabling modules & extensions cycles 4 times before fully opening to Start Center. That seems new--related?

On Windows 10 Home 64-bit en-US (1909) with Intel HD Graphics 620 with Intel ICH pgk Driver Version 27.20.100.8187

Using the 'Reset to Factory Settings' [chk Entire User Profile] and 'Apply Changes and Restart'

Results in this Skia.log:

RenderMethod: vulkan
Vendor: 0x8086
Device: 0x5916
API: 1.2.135
Driver: 0.401.4091
DeviceType: integrated
DeviceName: Intel(R) HD Graphics 620
Blacklisted: no

I'll check on a couple of older "non-Vulkan" graphics capable systems.
Comment 14 Julien Nabet 2020-05-19 14:01:21 UTC
If, after having remove LO profile, instead of "soffice.bin", I used "swriter.exe", it aborts at first time, it opens at the second time.
Comment 15 V Stuart Foote 2020-05-19 23:30:55 UTC
Created attachment 161019 [details]
GPU details, old AMD HD 6450 no-Vulkan support nVIDIA GT 710 supported

(In reply to V Stuart Foote from comment #13)

> I'll check on a couple of older "non-Vulkan" graphics capable systems.

So with today's TB77 build of master

Version: 7.0.0.0.alpha1+ (x64)
Build ID: 4804d969bacd25ad586b3bf70d3dc8c27adb48ef
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win; 
Locale: en-US (en_US); UI: en-US
Calc: CL

No crashes Skia Vulkan or Raster.

And as earlier today, for GPUs with and without support for Skia Vulkan rendering, a Safe mode reset cycles through the splash screen sequence to Synchronize bundled extensions, and then Enable bundled extensions -4- times.

Not clear that is a Skia issue, probably not, but it is new.
Comment 16 Julien Nabet 2020-05-23 08:13:12 UTC
Except if I missed something, information have been provided.
Comment 17 Telesto 2020-05-23 08:26:25 UTC
I'm 'pulling out'.. no issues here.
Version: 7.0.0.0.alpha1+ (x64)
Build ID: 9a7c5d38a7a43c75c0f3d2f0c725196e916d0260
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 18 Luboš Luňák 2020-06-02 14:40:07 UTC
(In reply to Julien Nabet from comment #14)
> If, after having remove LO profile, instead of "soffice.bin", I used
> "swriter.exe", it aborts at first time, it opens at the second time.

You're not supposed to call soffice.bin directly, that's an internal executable invoked by soffice.exe, swriter.exe or others. It's normal that soffice.bin sometimes exits, soffice.exe will restart it as necessary. Does the problem exist if you use soffice.exe?
Comment 19 Julien Nabet 2020-06-02 15:01:29 UTC
(In reply to Luboš Luňák from comment #18)
> (In reply to Julien Nabet from comment #14)
> ...
> You're not supposed to call soffice.bin directly, that's an internal
> executable invoked by soffice.exe, swriter.exe or others. It's normal that
> soffice.bin sometimes exits, soffice.exe will restart it as necessary. Does
> the problem exist if you use soffice.exe?

I updated my local repo and removed LO profile, I confirm I've got same pb with soffice.exe:
- first time: error message ("abort has been called...")
- second time: ok
Comment 20 Luboš Luňák 2020-06-10 13:38:18 UTC
(In reply to Julien Nabet from comment #19)
> (In reply to Luboš Luňák from comment #18)
> > (In reply to Julien Nabet from comment #14)
> > ...
> > You're not supposed to call soffice.bin directly, that's an internal
> > executable invoked by soffice.exe, swriter.exe or others. It's normal that
> > soffice.bin sometimes exits, soffice.exe will restart it as necessary. Does
> > the problem exist if you use soffice.exe?
> 
> I updated my local repo and removed LO profile, I confirm I've got same pb
> with soffice.exe:
> - first time: error message ("abort has been called...")
> - second time: ok

That works as intended. The first time is the watchdog detecting a problem with the driver and aborting, the second time is fine with LO switched to raster. So the only thing remaining should be blacklisting the driver, which I'll do now.

Your driver appears to be very old. I suggest you update it if possible (perhaps even by using a driver directly from Intel instead of a PC-vendor-provided driver).
Comment 21 Commit Notification 2020-06-10 13:41:53 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/eaacb2eca2ffcf46306f1db83e4c5da4a102e4a9

blacklist old intel driver 0.16.2 for Vulkan (tdf#132681)

It will be available in 7.1.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 22 Xisco Faulí 2020-06-16 15:09:05 UTC
@Julien, could you please verify the issue is fixed for you in a recent build ?
Comment 23 Julien Nabet 2020-06-16 15:13:21 UTC
On Win10 with master sources updated today, I confirm I got no error and could launch LO after having removed LO profile, with 1 try.

Thank you Luboš!
Comment 24 Commit Notification 2020-06-16 15:15:21 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/db8e2fb82d875ccfb022a0fe24958bf3c4ac7d83

blacklist old intel driver 0.16.2 for Vulkan (tdf#132681)

It will be available in 7.0.0.1.

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.