Bug 97160 - Linux: OpenGL causes applications to crash on launch
Summary: Linux: OpenGL causes applications to crash on launch
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1 all versions
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 101968 (view as bug list)
Depends on:
Blocks: Crash OpenGL-Linux
  Show dependency treegraph
 
Reported: 2016-01-15 22:10 UTC by Silviu C.
Modified: 2020-08-28 11:57 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
result of running soffice --backtrace (17.04 KB, text/x-log)
2016-01-16 11:13 UTC, Silviu C.
Details
"soffice --backtrace" output (4.54 KB, text/x-log)
2016-01-16 16:44 UTC, Thomas Hackert
Details
zipped trace (1.79 MB, application/zip)
2016-01-16 16:46 UTC, Thomas Hackert
Details
backtrace with symbols LO 5.1.0 rc3 (14.83 KB, text/x-log)
2016-02-23 18:13 UTC, Silviu C.
Details
Valgrind OGL crash log (56.71 KB, text/x-log)
2016-02-24 17:51 UTC, Silviu C.
Details
debug build crash log LibreOfficeDev 5.2.0.0.alpha0 (28.96 KB, application/x-xz)
2016-02-26 14:41 UTC, Silviu C.
Details
glxinfo on a GeForce GTX 960/PCIe/SSE2 (54.68 KB, text/plain)
2017-02-20 02:30 UTC, Kip Warner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Silviu C. 2016-01-15 22:10:51 UTC
Trying to run any Writer, Calc, etc with OpenGL enabled causes them to crash on exit. OpenGL rendering is deselected on subsequent runs, unless it's forced. Then a profile reset is needed.
Comment 1 Silviu C. 2016-01-15 22:13:28 UTC
Might be related to this bug:
 
https://bugs.documentfoundation.org/show_bug.cgi?id=96546
 
which appears to be fixed on Windows
Comment 2 Michael Meeks 2016-01-16 10:51:41 UTC
Oooh - nice =) what is the hash of your build from Help->about ? - or is it RC2 ? Some idea of your GPU would be nice.

Even more ideal would be a windbg stack-trace if we have one - ideally with symbols (?) =) with that we can nail this down much more quickly instructions are here:

https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg

Many thanks !
Comment 3 Michael Meeks 2016-01-16 10:52:44 UTC
Oh - also, bug title says "crash on launch", but bug text says "crash on exit" - is it launch, or exit ? =) Thanks !
Comment 4 Silviu C. 2016-01-16 11:11:49 UTC
Oh gosh. I'm sorry. I really should stop writing bug reports at midnight :/
 
Anyway, the crash happens on launch.

LO build info:
Version: 5.1.0.2
Build ID: ecd3574d51754b043f865cf5bafee286d24db7cc
CPU Threads: 4; OS Version: Linux 4.3; UI Render: default; 
Locale: en-US (en_US.UTF-8)
 
I tried with the Jan 15 daily and the same crash on launch happened.
 
My video card is a GTX 660 and I'm using the 352.63 driver (long lived branch)

Could I provide a useful stack-trace using GDB? I'll attach what I got in the meantime by running soffice --backtrace.
Comment 5 Silviu C. 2016-01-16 11:13:21 UTC
Created attachment 121985 [details]
result of running soffice --backtrace
Comment 6 Thomas Hackert 2016-01-16 16:43:03 UTC
Hello Silviu, *,
I can confirm it with LO

Version: 5.0.4.2
Build-ID: 00m0(Build:2)
Gebietsschema: de-DE (de_DE.UTF-8)

on Debian Testing AMD64, but not with

Version: 5.1.0.2
Build-ID: ecd3574d51754b043f865cf5bafee286d24db7cc
CPU Threads: 4; OS Version: Linux 4.3; UI Render: GL; 
Gebietsschema: de-DE (de_DE.UTF-8)

(parallel installed, following the instructions from https://wiki.documentfoundation.org/Installing_in_parallel/Linux) with de-DE lang- as well as helppack.

My video chip is an Intel HD Graphics 4400 and NVidia GeForce 840M (which I am not able to get it work ... :( ). I am using xserver-xorg-video-intel 2.99.917-2, if this is important ... ;) I will attach a backtrace as well as a trace afterwards. If someone here needs any further info, feel free to ask :)
HTH
Thomas.
Comment 7 Thomas Hackert 2016-01-16 16:44:59 UTC
Created attachment 122001 [details]
"soffice --backtrace" output

My "soffice --backtrace" output, after enabling OpenGL in LO's Options dialog, restarting LO, and starting Writer ...
Comment 8 Thomas Hackert 2016-01-16 16:46:56 UTC
Created attachment 122003 [details]
zipped trace

Zipped "soffice --strace"log, as the unzipped one is 13MiB in size ... :(
Comment 9 Silviu C. 2016-02-23 18:13:04 UTC
Created attachment 122927 [details]
backtrace with symbols LO 5.1.0 rc3

As LO 5.1.0 packages hit the official PPA today, I installed the libreoffice-dbg package and ran soffice --backtrace
 
LO still crashes when activating "Use OpenGL for all rendering"
Comment 10 Michael Meeks 2016-02-23 21:58:04 UTC
That it crashes, and disables GL in doing so is rather a feature =)

It would be interesting to install 'apitrace' which is a useful tool, and to run:

apitrace trace soffice.bin

while running in GL mode.

If then using qapitrace you can get the trace to crash the tracing app - then we can isolate the problem as an OpenGL driver issue and re-file (with the trace) up-stream =)

Thanks !
Comment 11 Silviu C. 2016-02-23 22:45:18 UTC
No dice. Trace files turn up empty and the application still crashes :/
 
Even tried doing it the "hard" way:
 
-----
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/apitrace/wrappers/glxtrace.so /usr/lib/libreoffice/program/soffice.bin

** (process:11154): WARNING **: require a newer gtk than 3.10 for theme expectations
apitrace: tracing to /home/silviu/soffice.bin.8.trace

(soffice:11154): Gdk-WARNING **: gdk_window_set_icon_list: icons too large
Application Error
-----
 
Still ended up with a 0 byte trace file.
Comment 12 Michael Meeks 2016-02-24 10:20:55 UTC
unfortunately the back-trace with symbols (which is great - it looks like calling a virtual / null function somehow) seems rather odd:

#1  0x00007ffff68b9bb5 in OpenGLContext::AcquireFramebuffer (this=0x174b300, rTexture=...) at /build/libreoffice-slmnDx/libreoffice-5.1.0~rc3/vcl/source/opengl/OpenGLContext.cxx:1649
#2  0x00007ffff68b027f in OpenGLSalGraphicsImpl::CheckOffscreenTexture (this=this@entry=0x171ee30) at /build/libreoffice-slmnDx/libreoffice-5.1.0~rc3/vcl/opengl/gdiimpl.cxx:477

but at line 1649 in 5.1.0.3 we have:

    if( !pFramebuffer && mnFramebufferCount < MAX_FRAMEBUFFER_COUNT )
    {
        mnFramebufferCount++;
***     pFramebuffer = new OpenGLFramebuffer();  ***
        if( mpLastFramebuffer )
        {
            pFramebuffer->mpPrevFramebuffer = mpLastFramebuffer;

A simple constructor - so ... it is very unclear how that could be NULL. Most odd. Perhaps running in valgrind would help.

It'd also be great to get a trace from 5.1.1.rc1 (or even 2 coming soon) if possible. It looks like a simple NULL ptr de-reference which (I'd hope) would be easy to fix - but we need a newer version to poke at I think.

Thanks !
Comment 13 Silviu C. 2016-02-24 17:51:27 UTC
Created attachment 122960 [details]
Valgrind OGL crash log

Attaching a --verbose log I captured with valgrind.
 
Regrading the 5.1.1 rc trace, I will be able to do that once it's actually in the repos I assume.
 
The nightly builds have no debug info as far as I can see.
Comment 14 Michael Meeks 2016-02-25 21:56:11 UTC
Well; I imagine gdb and valgrind are confused by the constructor or something:

        pFramebuffer = new OpenGLFramebuffer();

is the line; and the (out of line) constructor is:

OpenGLFramebuffer::OpenGLFramebuffer() :
    mnId( 0 ),
    mnWidth( 0 ),
    mnHeight( 0 ),
    mnAttachedTexture( 0 ),
    mpPrevFramebuffer( nullptr ),
    mpNextFramebuffer( nullptr )
{
    glGenFramebuffers( 1, &mnId );
    CHECK_GL_ERROR();
    VCL_GL_INFO( "Created framebuffer " << (int)mnId );
}

but I guess (libmerged LTO magic) this gets inlined in its only call site even across translation units.

I imagine the problem is that your driver has a NULL 'glGenFramebuffers' method - which we call via glew. I guess we should check for that and disable GL.
 I assume your drivers are horribly old (?) =)
Comment 15 Michael Meeks 2016-02-25 22:18:16 UTC
We can check for this in the GLEW init and return false if we fail (all well and good) - but then that is not actually checked:

rtl::Reference<OpenGLContext> X11OpenGLSalGraphicsImpl::CreateWinContext()
{
    X11WindowProvider *pProvider = dynamic_cast<X11WindowProvider*>(mrParent.m_pFrame);

    if( !pProvider )
        return nullptr;

    Window aWin = pProvider->GetX11Window();
    rtl::Reference<OpenGLContext> pContext = OpenGLContext::Create();
    pContext->setVCLOnly();
    pContext->init( mrParent.GetXDisplay(), aWin,
                    mrParent.m_nXScreen.getXScreen() );
    return pContext;
}

Which is lame ... I guess we should be doing this inside:

bool OpenGLHelper::isVCLOpenGLEnabled()

To check whether we can in fact initialize this (or not) before we get much further. If this method returns true - we assume that we can get GL up and running; so we need to do a deeper probe and sanity check in there (I guess).

Hmm =) shouldn't be too hard I hope. Still - I'm glad the crash handler is doing its job nicely for you.
Comment 16 Silviu C. 2016-02-25 22:22:24 UTC
(In reply to Michael Meeks from comment #14)

> I imagine the problem is that your driver has a NULL 'glGenFramebuffers'
> method - which we call via glew. I guess we should check for that and
> disable GL.
>  I assume your drivers are horribly old (?) =)

On the contrary. I was using the latest 361.28 nvidia blob for Linux. Today I got the same crash with nvidia's 355.00.28 Linux driver which is the build with Vulkan support (trying out The Talos Principle VK mode :) )
Comment 17 Michael Meeks 2016-02-26 11:34:58 UTC
Its amazing =) I can't imagine that a new driver would have a NULL glGenFramebuffers. Hmm.

Any chance you can get a dbgutil build (these are usually quite a large download) and get the console output from:

SAL_LOG=1 ./soffice --writer

or whatever with GL enabled; that should help us go a bit further; but ... this guy is quite odd. More ideally - it'd be nice to have the crash in gdb [ which looks like a simple NULL ptr de-reference ] and ...

I fear bug#97700 makes any testing on 5.1.0* hard to predict anyway; we can corrupt memory without valgrind seeing =)

Could you re-test with 5.1.1.2 ? =)
Comment 18 Silviu C. 2016-02-26 14:41:19 UTC
Created attachment 123013 [details]
debug build crash log LibreOfficeDev 5.2.0.0.alpha0

This contains the output of running 

LibreOfficeDev 5.2.0.0.alpha0 1b6a84a5a24e7e02c6066ca0fcb5a0011d2decd6 

invoked with 

SAL_LOG=1 ./soffice --writer > allout.txt 2>&1
 
Link to the where I found the build:
 
http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF-dbg/2016-02-24_07.29.17/
Comment 19 Markus Mohrhard 2016-03-01 02:33:28 UTC
(In reply to Silviu C. from comment #18)
> Created attachment 123013 [details]
> debug build crash log LibreOfficeDev 5.2.0.0.alpha0
> 
> This contains the output of running 
> 
> LibreOfficeDev 5.2.0.0.alpha0 1b6a84a5a24e7e02c6066ca0fcb5a0011d2decd6 
> 
> invoked with 
> 
> SAL_LOG=1 ./soffice --writer > allout.txt 2>&1
>  
> Link to the where I found the build:
>  
> http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF-
> dbg/2016-02-24_07.29.17/

I would guess that the problem is once again in info:vcl.opengl:29286:1:vcl/source/opengl/OpenGLContext.cxx:747: created a 3.2 core context

So my old code to create a core context is most likely picking a wrong fbc and therefore generating the context fails. I think some drivers/vendors are a lot more picky than others when it comes to bad combination of drawable and fbc.

I think at some point we need to clean that up. It was written when I was still very new to OpenGL.
Comment 20 Buovjaga 2016-09-24 19:19:45 UTC
*** Bug 101968 has been marked as a duplicate of this bug. ***
Comment 21 Kip Warner 2017-02-20 02:30:23 UTC
Created attachment 131345 [details]
glxinfo on a GeForce GTX 960/PCIe/SSE2

I too am experiencing the same problem:

$ soffice --writer
soffice.bin: Couldn't find current GLX or EGL context.

$ soffice --version
LibreOffice 5.3.0.3 30m0(Build:3)

My glxinfo is attached.
Comment 22 Bojan 2017-03-21 06:22:32 UTC
I too have same problem.

openSuSE Leap 42.2.2, KDE Plasma 5.9.3, KDE Frameworks 5.32.0, Qt 5.8.0, Kernel 4.4.49-16-default, 64 bit, NVIDIA K2000 (driver 375.39)

LO crashes on launch with opengl enabled. Tried with a brand new LO profile with the same result.

Bojan
Comment 23 Bojan 2017-03-21 06:26:29 UTC
Forgot to mentioned LO version which is 5.3.1.2 release.
Bojan
Comment 24 Michael Meeks 2017-03-21 08:57:36 UTC
Linux / OpenGL needs quite some work; help / patches much appreciated - my hope is that we don't need a back-compat context anymore in 5.3+, which may help.
Comment 25 codywohlers 2017-05-18 12:32:27 UTC
still happens on 5.3.3.2

soffice.bin: Couldn't find current GLX or EGL context.
Comment 26 Aron Budea 2017-05-22 02:57:37 UTC
Let's keep version as the earliest (known) affected.
Comment 27 Gessel 2017-12-28 17:25:58 UTC
$ soffice
soffice.bin: Couldn't find current GLX or EGL context.

(crash)

$ soffice --version
LibreOffice 5.4.4.2 40m0(Build:2)

NVIDIA driver version 384.98
Quadro K2100M
VBIOS 80.06.8a.00.03
Comment 28 Gessel 2017-12-30 16:07:42 UTC
If you find this looking for a solution to be able to restart libreoffice, it is here:  https://www.reddit.com/r/linuxmint/comments/6xsv47/sofficebin_couldnt_find_current_glx_or_egl_context/
Comment 29 Julien Nabet 2018-01-29 17:30:37 UTC
The git history of the file vcl/source/opengl/OpenGLContext.cxx quoted by Markus shows about thirty commits
Any better with a recent LO version? Last stable one is 5.4.4.
If the crash is still reproduced, a bt with debug symbols may help.
Also attaching opengl_device.log (see https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_.28OpenGL.29) could be useful. Indeed, if the pb is in the driver, it could be blacklisted and so LO would start automatically by disabling OpenGL.
Comment 30 QA Administrators 2019-01-30 03:41:48 UTC Comment hidden (obsolete)
Comment 31 mattia.b89 2019-02-02 21:50:57 UTC
Can't reproduce it. Seems fixed!

Version: 6.1.4.2
Build ID: 6.1.4-4
CPU threads: 4; OS: Linux 4.20; UI render: default; VCL: gtk3; 
Locale: it-IT (en_GB.UTF-8); Calc: group threaded
Comment 32 Buovjaga 2020-08-28 11:57:32 UTC
As Skia with Vulkan will replace OpenGL UI rendering on all platforms, it does not make sense to keep OpenGL UI reports open.

Details about Skia: https://www.collaboraoffice.com/success-story/implementing-vulkan-capable-libreoffice-user-interface-using-the-skia-library/