libreoffice crashes on startup when using OpenGL rendering and proprietary nvidia driver.

[b]

I noticed that Libreoffice was rendering very slow (I can see each menu option drawn) so I tried using OpenGL rendering, which causes libreoffice to crash immediately on start-up.

I confirm that OpenGL is working fine:

$ glxinfo | head
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4

I'm able to use glxgears and other apps like djv_view with fast rendering.

I've attached the gdb trace resulting from the crash with debug symbols, following is an except:

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff68e96f7 in OpenGLContext::AcquireFramebuffer (this=0x128f600, rTe
xture=...) at /build/libreoffice-OypX7x/libreoffice-5.1.4/vcl/source/opengl/Open
GLContext.cxx:1773

WORKAROUND: Use 5.3.0~rc3-0ubuntu1~xenial1.1.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: libreoffice 1:5.1.4-0ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-45.66-generic 4.4.21
Uname: Linux 4.4.0-45-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: XFCE
Date: Fri Nov 11 18:45:52 2016
InstallationDate: Installed on 2010-11-05 (2198 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
SourcePackage: libreoffice
UpgradeStatus: Upgraded to xenial on 2016-11-02 (9 days ago)

[Silviu C. (silviucc)]

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.

[Silviu C. (silviucc)]

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.

[Silviu C. (silviucc)]

Might be related to this bug:

https://bugs.documentfoundation.org/show_bug.cgi?id=96546

which appears to be fixed on Windows

[Silviu C. (silviucc)]

Might be related to this bug:

https://bugs.documentfoundation.org/show_bug.cgi?id=96546

which appears to be fixed on Windows

[Michael-meeks-1 (michael-meeks-1)]

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 !

[Michael-meeks-1 (michael-meeks-1)]

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 !

[Michael-meeks-1 (michael-meeks-1)]

Oh - also, bug title says "crash on launch", but bug text says "crash on exit" - is it launch, or exit ? =) Thanks !

[Michael-meeks-1 (michael-meeks-1)]

Oh - also, bug title says "crash on launch", but bug text says "crash on exit" - is it launch, or exit ? =) Thanks !

[Silviu C. (silviucc)]

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.

[Silviu C. (silviucc)]

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.

[Silviu C. (silviucc)]

Created attachment 121985
result of running soffice --backtrace

[Silviu C. (silviucc)]

Created attachment 121985
result of running soffice --backtrace

[thackert (thackert)]

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.

[thackert (thackert)]

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.

[thackert (thackert)]

Created attachment 122001
"soffice --backtrace" output

My "soffice --backtrace" output, after enabling OpenGL in LO's Options dialog, restarting LO, and starting Writer ...

[thackert (thackert)]

Created attachment 122001
"soffice --backtrace" output

My "soffice --backtrace" output, after enabling OpenGL in LO's Options dialog, restarting LO, and starting Writer ...

[thackert (thackert)]

Created attachment 122003
zipped trace

Zipped "soffice --strace"log, as the unzipped one is 13MiB in size ... :(

[thackert (thackert)]

Created attachment 122003
zipped trace

Zipped "soffice --strace"log, as the unzipped one is 13MiB in size ... :(

[Silviu C. (silviucc)]

Created attachment 122927
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"

[Silviu C. (silviucc)]

Created attachment 122927
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"

[Michael-meeks-1 (michael-meeks-1)]

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 !

[Michael-meeks-1 (michael-meeks-1)]

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 !

[Silviu C. (silviucc)]

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.

[Silviu C. (silviucc)]

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.

[Michael-meeks-1 (michael-meeks-1)]

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 !

[Michael-meeks-1 (michael-meeks-1)]

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 !

[Silviu C. (silviucc)]

Created attachment 122960
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.

[Silviu C. (silviucc)]

Created attachment 122960
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.

[Michael-meeks-1 (michael-meeks-1)]

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 (?) =)

[Michael-meeks-1 (michael-meeks-1)]

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 (?) =)

[Michael-meeks-1 (michael-meeks-1)]

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.

[Michael-meeks-1 (michael-meeks-1)]

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.

[Silviu C. (silviucc)]

(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 :) )

[Silviu C. (silviucc)]

(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 :) )

[Michael-meeks-1 (michael-meeks-1)]

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 ? =)

[Michael-meeks-1 (michael-meeks-1)]

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 ? =)

[Silviu C. (silviucc)]

Created attachment 123013
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/

[Silviu C. (silviucc)]

Created attachment 123013
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/

[Markus Mohrhard (moggi)]

(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.

[Markus Mohrhard (moggi)]

(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.

[Beluga (beluga)]

*** Bug 101968 has been marked as a duplicate of this bug. ***

[Beluga (beluga)]

*** Bug 101968 has been marked as a duplicate of this bug. ***

[b (ben-ekran)]

I reproduced this bug on two different xenial machines running nvidia 304.131-0ubuntu3 (legacy) and 340.98-0ubuntu0.16.0

[penalvch (penalvch)]

b, thank you for reporting this and helping make Ubuntu better.

To see if this is already resolved upstream could you please advise if this is reproducible with the latest LibreOffice version available from https://launchpad.net/~libreoffice ?

[b (ben-ekran)]

This bug persists in 1:5.2.3~rc2-0ubuntu1~xenial1, now trying a pre-release version.

[b (ben-ekran)]

1:5.2.3~rc2-0ubuntu1~xenial1 appears to be the latest version I can find.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[b (ben-ekran)]

I just tried version 1:5.3.0~rc3-0ubuntu1~xenial1.1.

Now I don't get a crash any longer, but I get this message:

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

A little googling and it seems that this error is due to my OpenGL version:

$ glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 2.1.2 NVIDIA 304.131
OpenGL shading language version string: 1.20 NVIDIA via Cg compiler
OpenGL ES profile version string: OpenGL ES 2.0 NVIDIA 304.131 304.131
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.00

This is an older machine with an AGP card.

Does libreoffice now require OpenGL 3?

Without OpenGL rendering, the GUI drawing is painfully slow and "Use hardware acceleration" and "Use anti-aliasing" options make no difference.

[b (ben-ekran)]

Switching back to nouveau solves my very slow rendering issue.

[Kip Warner (kip)]

Created attachment 131345
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.

[Kip Warner (kip)]

Created attachment 131345
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.

[Matteo Iervasi (matteoiervasi)]

Same here, using 5.3.0~rc3-0ubuntu1~xenial1.1 on Ubuntu 16.04.2 64bit with nVidia drivers version 367.57.

Also I have OpenGL 4.5 support, so the problem is not related to OpenGL version

[Bojan (bojan007)]

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

[Bojan (bojan007)]

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

[Bojan (bojan007)]

Forgot to mentioned LO version which is 5.3.1.2 release.
Bojan

[Bojan (bojan007)]

Forgot to mentioned LO version which is 5.3.1.2 release.
Bojan

[Michael-meeks-1 (michael-meeks-1)]

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.

[Michael-meeks-1 (michael-meeks-1)]

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.

[Documentfoundation-a (documentfoundation-a)]

still happens on 5.3.3.2

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

[Documentfoundation-a (documentfoundation-a)]

still happens on 5.3.3.2

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

[t-nub (romanivchenkone)]

Have same problem in Ubuntu 14.04 with LibreOffice 5.3

glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 9600 GT/PCIe/SSE2
OpenGL core profile version string: 3.3.0 NVIDIA 340.102
OpenGL core profile shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.3.0 NVIDIA 340.102
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler

[Aron Budea (baron-z)]

Let's keep version as the earliest (known) affected.

[Aron Budea (baron-z)]

Let's keep version as the earliest (known) affected.

[林博仁(Buo-ren, Lin) (buo-ren-lin)]

This problem can be reproduced on KDE Neon(Ubuntu 16.04) with current latest release(5.3.3.2) on ASUS S550C laptop:

```
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL core profile version string: 4.5.0 NVIDIA 375.39
OpenGL core profile shading language version string: 4.50 NVIDIA
OpenGL version string: 4.5.0 NVIDIA 375.39
OpenGL shading language version string: 4.50 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 375.39
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
    GL_EXT_shader_implicit_conversions, GL_EXT_shader_integer_mix,
```

At the same time using intel graphics(the laptop has both) LibreOffice is launchable (although buggy)

[penalvch (penalvch)]

林博仁 (buo-ren-lin), in order for developers to confirm you have the same problem, please report the crash following https://wiki.ubuntu.com/LibreOfficeBugWrangling#LibreOffice_crashes_but_system_still_functional .

[Cezar José Sant Anna Junior (cezarsantanna)]

glxinfo | grep OpenGL
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVA8
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.0-devel
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.2.0-devel
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.2.0-devel
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

When I use nouveau, I get poor performance, just one png image inside the odt file and all screen role very slow.

When I use nvidia 340 LibreOffice don't start I get the same Error: soffice.bin: Couldn't find current GLX or EGL context.

The libreoffice version is: 5.3.3~rc2-0ubuntu0.16.04.1~lo0 amd64

And I also using KDE Neon 5.8
ppa source for LibreOffice
http://ppa.launchpad.net/libreoffice/libreoffice-5-3/ubuntu xenial main

[penalvch (penalvch)]

Cezar José Sant Anna Junior, in order for developers to confirm you have the same problem, please report the crash following https://wiki.ubuntu.com/LibreOfficeBugWrangling#LibreOffice_crashes_but_system_still_functional .

[penalvch (penalvch)]

Cezar José Sant Anna Junior, the instructions advise to file a new crash report (not provide manual attachments), as apport will automatically generate and process crash related files. Could you please advise to either your crash report URL, or new bug report URL?

[Cezar José Sant Anna Junior (cezarsantanna)]

Sorry for that, but apport don't get the error, so I collected then by hand.

When the apport get the crash I will send the file.

Mean while I will not be able to use LibreOffice!

No big deal, :)

[Stéphane Berbigier (kestufabrix)]

Hello,
I just encountered this bug too as I upgraded to Kubuntu 17.10.
That is : libreoffice crashes if use of opengl is set to true (it doesn't even start) and returns :

X Error: BadMatch (invalid parameter attributes) 8
  Extension: 154 (Uknown extension)
  Minor opcode: 5 (Unknown request)
  Resource id: 0x9a00024
soffice.bin: Couldn't find current GLX or EGL context.

My system :
Libreoffice version : 5.4.2.2
Nvidia driver 384.90
Opengl version 4.5.0

Thanks...

[David Gessel (dgessel)]

$ 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

[David Gessel (dgessel)]

$ 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

[David Gessel (dgessel)]

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/

[David Gessel (dgessel)]

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/

[julien2412 (serval2412-6)]

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.

[julien2412 (serval2412-6)]

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.

[Qa-admin-q (qa-admin-q)]

** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

[Qa-admin-q (qa-admin-q)]

** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

[Mattia (mattia.b89)]

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

[Mattia (mattia.b89)]

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