Bug 131610 - Impress crashes upon running the second OpenGL transition (GTK3)
Summary: Impress crashes upon running the second OpenGL transition (GTK3)
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.4.2.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Impress-OpenGL GTK3
  Show dependency treegraph
 
Reported: 2020-03-26 18:54 UTC by mikefreeman1972
Modified: 2020-12-07 18:14 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document demonstrating the crash (13.37 KB, application/vnd.oasis.opendocument.presentation)
2020-06-10 04:25 UTC, mikefreeman1972
Details
--backtrace log (25.55 KB, text/x-log)
2020-08-28 17:12 UTC, mikefreeman1972
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mikefreeman1972 2020-03-26 18:54:47 UTC
Description:
If I set up a presentation and use OpenGL transistions with the previews on, the first transition runs fine in the preview, but if I select a second OpenGL transition (doesn't matter if it's on the same slide or not), LibreOffice crashes. I've tried turning previews off, and while that allows me to add all the transitions I want to a presentation, the same problem happens when running the actual fullscreen presentation: The first OpenGL transition runs just fine, the second one crashes LibreOffice. This has been the case for every version of LibreOffice on every Linux computer I've run it on going back for years. Still present in the most recent version. This makes OpenGL transistions useless. I've heard that using the Flatpak version helps, but for me the Flatpak version shows the exact same behavior. This is on Linux Mint 19.3 (going back for many versions - can't remember the first version I tried it on), currently on AMD A8 APU (also the same on various other AMD APU's, CPU's, and GPU's I've used). Running the open source graphics driver. OpenGL info: OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.2.8 (from glxinfo). I have tried resetting my user profile to make sure it wasn't a problem there. The same behavior occurs on a brand new user profile.

Steps to Reproduce:
1. Open Impress and create a presentation.
2. Add a transistion.
3. Add a second transition.
4. (If previews turned off) Run presentation through to the second OpenGL transition.
5. Watch it crash.

Actual Results:
LibreOffice crashes completely.

Expected Results:
Transitions should all run properly without crashes.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Version: 6.4.2.2
Build ID: 1:6.4.2-0ubuntu0.18.04.2
CPU threads: 4; OS: Linux 5.3; UI render: GL; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 Utkarsh Gupta 2020-06-09 04:55:32 UTC
I am coming from Pop OS 20.04 LTS with Libreoffice Impress 6.4.3.2. Previewing 3D transitions twice or more still crashes Impress. I did not know that I am getting into this buggy mud when I left Microsoft's software.
Comment 2 Xisco Faulí 2020-06-09 11:42:27 UTC
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Comment 3 mikefreeman1972 2020-06-10 04:25:09 UTC
Created attachment 161826 [details]
Sample document demonstrating the crash

Ok. Here is my sample document, which was created exactly as I've described in the original bug report. I'm not sure if this will be of value if what I describe isn't already happening on your hardware when you follow those steps.
Comment 4 mikefreeman1972 2020-06-10 04:27:24 UTC
...you should not be able to reach the third slide.
Comment 5 QA Administrators 2020-06-11 03:54:34 UTC Comment hidden (obsolete)
Comment 6 mikefreeman1972 2020-08-16 19:44:37 UTC
I can confirm that this bug still exists in LO 7.0.0
Comment 7 mikefreeman1972 2020-08-24 17:03:19 UTC
Is there anything more you need from me to move forward on this bug?
Comment 8 Buovjaga 2020-08-28 13:02:19 UTC
(In reply to mikefreeman1972 from comment #4)
> ...you should not be able to reach the third slide.

I was able to reach it.

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: e2fe4fde592564d35099ad1e2659ad682dfb77f5
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 25 August 2020
Comment 9 mikefreeman1972 2020-08-28 14:24:49 UTC
(In reply to Buovjaga from comment #8)
> (In reply to mikefreeman1972 from comment #4)
> > ...you should not be able to reach the third slide.
> 
> I was able to reach it.
> 
> Arch Linux 64-bit
> Version: 7.1.0.0.alpha0+
> Build ID: e2fe4fde592564d35099ad1e2659ad682dfb77f5
> CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> Calc: threaded
> Built on 25 August 2020

Perhaps this bug is specific to the Debian/Ubuntu builds, or perhaps it's related to specific hardware or OpenGL compatibility? For me, it is present no matter which version of LO I try, whether the one in the Ubuntu repositories, the official LO PPA, from the LO website, Flathub version, etc. I can completely clear out my LO hidden folders to reset the configuration without affecting this bug. It always results in the same crash after the second GL transition.
Comment 10 mikefreeman1972 2020-08-28 17:12:01 UTC
Created attachment 164823 [details]
--backtrace log

If it helps, I'm attaching the log file generated when I run libreoffice --backtrace and trigger the bug.
Comment 11 Buovjaga 2020-08-28 17:50:57 UTC
(In reply to mikefreeman1972 from comment #0)
> Additional Info:
> Version: 6.4.2.2
> Build ID: 1:6.4.2-0ubuntu0.18.04.2
> CPU threads: 4; OS: Linux 5.3; UI render: GL; VCL: gtk3; 
> Locale: en-US (en_US.UTF-8); UI-Language: en-US
> Calc: threaded

Just wondering, how is it possible that you have UI render: GL. It should not be enabled on Linux. Do you see the option in Tools - Options - LibreOffice - View - Use OpenGL for all rendering?

You could also try launching from the command line with

SAL_USE_VCLPLUGIN=gen libreoffice

and seeing if it crashes.
Comment 12 mikefreeman1972 2020-08-28 18:24:18 UTC
(In reply to Buovjaga from comment #11)
> Just wondering, how is it possible that you have UI render: GL. It should
> not be enabled on Linux. Do you see the option in Tools - Options -
> LibreOffice - View - Use OpenGL for all rendering?

I'm not sure. Why shouldn't that be possible?

Looking in Tools > Options > LibreOffice > View, I do not see "Use OpenGL for all rendering". I do see "Use hardware acceleration"

> You could also try launching from the command line with
> 
> SAL_USE_VCLPLUGIN=gen libreoffice
 
That stops the crashes. It also removes my GTK theming.
Comment 13 Buovjaga 2020-08-28 18:27:45 UTC
(In reply to mikefreeman1972 from comment #12)
> (In reply to Buovjaga from comment #11)
> > Just wondering, how is it possible that you have UI render: GL. It should
> > not be enabled on Linux. Do you see the option in Tools - Options -
> > LibreOffice - View - Use OpenGL for all rendering?
> 
> I'm not sure. Why shouldn't that be possible?

Because LibreOffice OpenGL UI rendering support was never completed to an acceptible level on Linux. Now it is being replaced by Vulkan anyway: https://www.collaboraoffice.com/success-story/implementing-vulkan-capable-libreoffice-user-interface-using-the-skia-library/
Comment 14 mikefreeman1972 2020-08-28 18:47:39 UTC
(In reply to Buovjaga from comment #13)
> Because LibreOffice OpenGL UI rendering support was never completed to an
> acceptible level on Linux. Now it is being replaced by Vulkan anyway:
> https://www.collaboraoffice.com/success-story/implementing-vulkan-capable-
> libreoffice-user-interface-using-the-skia-library/

Ok. Interesting. When will we see Vulkan support in the Linux version? Hopefully it will have more attention than OpenGL on Linux LO did.

Also, I looked at my current about info (using LO 7.0.0.3), and this is what it says:

Version: 7.0.0.3
Build ID: 00(Build:3)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.0.0_rc3-0ubuntu0.20.04.2
Calc: threaded

So after upgrading to LO 7, it no longer says the UI renderer is GL, but it still crashes without the SAL_USE_VCLPLUGIN=gen prefix. Could GTK3 be causing the problem?

I also noticed that after upgrading from 6.4 to 7, the transition preview as well as many of the UI elements in the Impress window blink and stutter badly until the preview is over. With LO 6.4 or with LO 7 with SAL_USE_VCLPLUGIN=gen, the preview is fairly smooth and the UI doesn't blink and stutter.
Comment 15 Rafael Lima 2020-08-29 14:15:41 UTC
I can confirm that these issues only happen on VCL-Gtk. I tried running VCL-Kf5 on the same machine / same linux distro and all worked fine.

I provided a more detailed report on the Meta Bug 94691 that deals with "Impress OpenGL transition bugs".
Comment 16 Caolán McNamara 2020-08-31 08:25:03 UTC
works fine for me with gtk3 under Fedora 32/33. Seeing as the crash is reported as happening in /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so the best course of action is to bring raise the bug against your distribution and get a backtrace that includes the symbols of that lib if possible to see what exactly is crashing
Comment 17 Buovjaga 2020-08-31 10:26:22 UTC
(In reply to Caolán McNamara from comment #16)
> works fine for me with gtk3 under Fedora 32/33. Seeing as the crash is
> reported as happening in /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so the
> best course of action is to bring raise the bug against your distribution
> and get a backtrace that includes the symbols of that lib if possible to see
> what exactly is crashing

Makes sense. Mike: here is the Ubuntu bug tracker: https://bugs.launchpad.net/ubuntu/
For debug symbols under Ubuntu, see: https://wiki.ubuntu.com/Debug%20Symbol%20Packages

Let's close.
Comment 18 mikefreeman1972 2020-12-07 17:23:09 UTC
Just to check, I've just tried installing the oibaf mesa drivers PPA, which includes updated radeonsi-dri drivers, compiled daily, to see if drivers from a different source than Ubuntu itself would solve this problem. It did not. I'm still running into this same crash. And if anything, the flickering that happens during the transition selection is much worse now.

I tried LO Impress on my wife's computer, which also runs the same distro but runs a newer AMD APU, shows the exact same problem as well.
Comment 19 mikefreeman1972 2020-12-07 17:40:52 UTC
Are you sure this isn't a problem with the GTK VCL plugin, and not the radeonsi driver? Impress transitions work fine with the generic, qt, and kf5 VCL plugins. It would seem to me (granted, I'm not a programmer) that the problem exists within the way the GTK VCL plugin specifically is interfacing with the drivers. I've never run into any OpenGL crashes with my drivers other than this.
Comment 20 Buovjaga 2020-12-07 18:14:05 UTC
(In reply to mikefreeman1972 from comment #19)
> Are you sure this isn't a problem with the GTK VCL plugin, and not the
> radeonsi driver?

I can only suggest that you open a bug in Ubuntu's tracker