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

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.

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.

Might be related to this bug:

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

which appears to be fixed on Windows

Might be related to this bug:

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

which appears to be fixed on Windows

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 !

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 !

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

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

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.

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.

Created attachment 121985
result of running soffice --backtrace

Created attachment 121985
result of running soffice --backtrace

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.

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.

Created attachment 122001
"soffice --backtrace" output

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

Created attachment 122001
"soffice --backtrace" output

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

Created attachment 122003
zipped trace

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

Created attachment 122003
zipped trace

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

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"

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"

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 !

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 !

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.

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.

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 !

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 !

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.

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.

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

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

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.

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.

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

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

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

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

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/

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/

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

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

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

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

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.

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.

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

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

Forgot to mentioned LO version which is 5.3.1.2 release.
Bojan

Forgot to mentioned LO version which is 5.3.1.2 release.
Bojan

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.

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.

still happens on 5.3.3.2

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

still happens on 5.3.3.2

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

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

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

$ 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

$ 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

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/

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/

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.

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.

** 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

** 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

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

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