Bug 105514 - Hang/crash during first start with non-OpenGL-capable hardware
Summary: Hang/crash during first start with non-OpenGL-capable hardware
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.3.0.1 rc
Hardware: All Windows (All)
: high critical
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.4.0 target:5.3.1
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2017-01-25 01:53 UTC by Aron Budea
Modified: 2017-02-01 13:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Backtrace (17.43 KB, text/plain)
2017-01-25 01:53 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2017-01-25 01:53:54 UTC
Created attachment 130668 [details]
Backtrace

If the hardware doesn't have enough OpenGL capability for LibreOffice, it hangs, and sometimes crashes upon first start.
Reproduced with 5.3.0.1 and 5.3.0.2 / Windows 7.
Not reproduced with 5.2.4.2. => regression

I couldn't send a crash report, but the backtrace is attached. Looks like an infinite recursion attempt.
Comment 1 Aron Budea 2017-01-25 01:55:00 UTC Comment hidden (bibisection)
Comment 2 Aron Budea 2017-01-25 02:03:09 UTC
Bibisection points to the commit referenced below, adding Cc: to Caolán McNamara, please take a look.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=11e6f819122bc51b5ed58d2dbace754c00faa7c8 (5.3)
https://cgit.freedesktop.org/libreoffice/core/commit/?id=d96686e482d2f2649dbd87d7ed9db2775e5d22f5 (master)
author	Caolán McNamara <caolanm@redhat.com>	2016-12-08 14:16:41 (GMT)
committer	Caolán McNamara <caolanm@redhat.com>	2016-12-09 13:07:26 (GMT)

"move the windows restart because of bad-opengl requirements to a better place"

Self-confirming, as I encountered this bug in two separate systems (it crashed in one and hung in the other).
Comment 3 V Stuart Foote 2017-01-25 04:40:17 UTC
Aron, but isn't this what we expect? Maybe a bit less stable now, but still intentional...

1. OpenGL enabled by default on Windows

2. OS/GPU/driver combo not blacklisted

3. a substandard OpenGL support -> crash recover OpenGL disabled

4. run with OpenGL disabled
Comment 4 V Stuart Foote 2017-01-25 05:07:04 UTC
The backtrace is convincing.

Looked through the crashreport server, unfortunately not seeing reports for this area of OpenGL--I even opened a couple dozen of the generic mergedlo signature agains 5.3.0.1/5.3.0.2--didn't see any against this. 

So either its not going to be common, or the hang isn't triggering the minidump and report.
Comment 5 Aron Budea 2017-01-25 05:48:30 UTC
(In reply to V Stuart Foote from comment #4)
> So either its not going to be common, or the hang isn't triggering the
> minidump and report.

Yes, in one system it hung during load (nothing appeared, only soffice.bin+exe in task manager), and nothing happened. In the other system it hung, and then crashed with a Windows crash dialog. Trying to submit a crash report when offered afterwards gave an "Error" text in the dialog instead of the link.

It might be worth checking with Markus if the crash dump really is unusable in this case, or that is a bug with error reporting.

Regarding the regular crash/recover behavior during OpenGL probing, that normally happens quickly, and without any visible indication of an error (in 5.2.4.2 for example).
Comment 6 Aron Budea 2017-01-25 18:09:29 UTC
(In reply to V Stuart Foote from comment #4)
> So either its not going to be common, or the hang isn't triggering the
> minidump and report.

Bug 105524 contains the explanation why.
Comment 7 Caolán McNamara 2017-01-26 21:07:29 UTC
https://gerrit.libreoffice.org/#/c/33580/ might solve this
Comment 8 Commit Notification 2017-01-27 08:55:50 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9a61fdbf0b64dac30a2fe098388cd20471cca7bb

Related: tdf#105514 recursive fallback GetOpenGLContext

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Caolán McNamara 2017-01-27 09:02:33 UTC
I can't test this myself, so I'd like to find out if this actually solves the problem, if it does I'll backport it
Comment 10 Aron Budea 2017-01-28 20:28:07 UTC
I'll test it once a daily build containing the commit is available for Windows.
Comment 11 Aron Budea 2017-01-31 02:24:16 UTC
I can confirm there is no crash in the daily build from 2017-01-29, LibreOffice starts with default rendering in the affected systems.

Version: 5.4.0.0.alpha0+
Build ID: e073bb9c3ea2f7d03a7cf0759efc70edf84fc033
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-29_05:25:38
Locale: hu-HU (hu_HU); Calc: CL
Comment 12 Caolán McNamara 2017-01-31 10:40:55 UTC
so, that's fixed in master then, backport now in gerrit for 5-3
Comment 13 Commit Notification 2017-02-01 13:37:41 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bafb52624869a5078636a462a06fd65b9efaf04b&h=libreoffice-5-3

Related: tdf#105514 recursive fallback GetOpenGLContext

It will be available in 5.3.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.