Open PPTX attachment 180067 [details] from 149042. Advance to slide 2. Now slide 3 should advance automatically but it crashes for me in Mint 19 (based on Ubuntu 18.04) GTK3. Crash is not for all users nor is in GEN and WIN. Bibisected in 7.4 to: commit 59e9d50757e55b1da148976b86adb8db3ebfc811 Date: Mon Mar 28 15:08:12 2022 +0200 author Stephan Bergmann <sbergman@redhat.com> Drop support for OpenGL denylist on X11 CC Stephan, please see.
(In reply to Timur from comment #0) > Bibisected in 7.4 to: > > commit 59e9d50757e55b1da148976b86adb8db3ebfc811 > Date: Mon Mar 28 15:08:12 2022 +0200 > author Stephan Bergmann <sbergman@redhat.com> > Drop support for OpenGL denylist on X11 Please state the git repo that you used for bibisecting.
It's bibisect-linux-64-7.4, is there some other?
(In reply to Timur from comment #0) > Open PPTX attachment 180067 [details] from 149042. > Advance to slide 2. ...after starting the slide show, I assume > Now slide 3 should advance automatically but it crashes for me in Mint 19 > (based on Ubuntu 18.04) GTK3. > > Crash is not for all users nor is in GEN and WIN. I cannot reproduce locally (Fedora 36 GNOME x86-64 with Intel graphics). Please provide a backtrace (maybe passing the --backtrace command line argument to soffice is all that you'd need to do; the bibisect-linux-64-7.4 binaries seem not to be stripped).
Created attachment 180097 [details] gdbtrace.log Attached is gdbtrace.log from bibisect soffice -backtrace. But it says: no debugging symbols found. If not useful, I'll have to fetch debug build. Here is a console: OpenGL Warning: glXQueryContext not implemented by Chromium No provider of glGenVertexArrays found. Requires one of: Desktop OpenGL 3.0 GL_ARB_vertex_array_object OpenGL ES 3.0 GL_APPLE_vertex_array_object GL_OES_vertex_array_object
(In reply to Timur from comment #4) > Created attachment 180097 [details] > gdbtrace.log > > Attached is gdbtrace.log from bibisect soffice -backtrace. > But it says: no debugging symbols found. > If not useful, I'll have to fetch debug build. ...quoting its relevant part inline here: > Thread 1 (Thread 0x7ffff7f92ec0 (LWP 17359)): > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 > #1 0x00007ffff74d07f1 in __GI_abort () at abort.c:79 > #2 0x00007fffe8842ce2 in gl_provider_resolver () from /home/t/linux-64-7.4/instdir/program/libepoxy.so > #3 0x00007fffe887a62a in epoxy_glGenVertexArrays_global_rewrite_ptr () from /home/t/linux-64-7.4/instdir/program/libepoxy.so > #4 0x00007fffdcc9eee1 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #5 0x00007fffdcc9f52c in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #6 0x00007fffdccb5ae6 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #7 0x00007fffdccb5ca8 in gdk_window_end_draw_frame () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #8 0x00007fffdd2e79a3 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #9 0x00007fffdd18b859 in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > #10 0x00007fffdcc9c765 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #11 0x00007fffdccac7f5 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #12 0x00007fffdccad9f6 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #13 0x00007fffdccadbf0 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #14 0x00007fffe81fc0bd in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #15 0x00007fffe820f00e in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #16 0x00007fffe82176f5 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #17 0x00007fffe821810f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #18 0x00007fffdcca5ac9 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #19 0x00007fffdcc91080 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #20 0x00007fffe7f21e23 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > #21 0x00007fffe7f213a5 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > #22 0x00007fffe7f21770 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > #23 0x00007fffe7f217fc in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > #24 0x00007fffdd94368c in GtkSalData::Yield(bool, bool) () from /home/t/linux-64-7.4/instdir/program/libvclplug_gtk3lo.so > #25 0x00007fffefb9d392 in ImplYield(bool, bool) () from /home/t/linux-64-7.4/instdir/program/libvcllo.so > #26 0x00007fffbaabd8ea in sd::SlideshowImpl::updateSlideShow() () from /home/t/linux-64-7.4/instdir/program/../program/libsdlo.so > #27 0x00007fffefb8cf9b in Scheduler::CallbackTaskScheduling() () from /home/t/linux-64-7.4/instdir/program/libvcllo.so > #28 0x00007fffdd9425fa in sal_gtk_timeout_dispatch () from /home/t/linux-64-7.4/instdir/program/libvclplug_gtk3lo.so > #29 0x00007fffe7f213a5 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > #30 0x00007fffe7f21770 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > #31 0x00007fffe7f217fc in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > #32 0x00007fffdd94368c in GtkSalData::Yield(bool, bool) () from /home/t/linux-64-7.4/instdir/program/libvclplug_gtk3lo.so > #33 0x00007fffefb9d392 in ImplYield(bool, bool) () from /home/t/linux-64-7.4/instdir/program/libvcllo.so > #34 0x00007fffefb9fb35 in Application::Execute() () from /home/t/linux-64-7.4/instdir/program/libvcllo.so > #35 0x00007ffff78b105e in desktop::Desktop::Main() () from /home/t/linux-64-7.4/instdir/program/libsofficeapp.so > #36 0x00007fffefba7936 in ImplSVMain() () from /home/t/linux-64-7.4/instdir/program/libvcllo.so > #37 0x00007ffff78dcffd in soffice_main () from /home/t/linux-64-7.4/instdir/program/libsofficeapp.so > #38 0x000000000040066b in main () (In reply to Timur from comment #4) > Here is a console: > > OpenGL Warning: glXQueryContext not implemented by Chromium > No provider of glGenVertexArrays found. Requires one of: > Desktop OpenGL 3.0 > GL_ARB_vertex_array_object > OpenGL ES 3.0 > GL_APPLE_vertex_array_object > GL_OES_vertex_array_object What apparently happens is that since <https://git.libreoffice.org/core/+/8a734ba9287f8d25c3c3df50b4efc91b9035127d%5E%21> "Drop support for OpenGL denylist on X11" modified OpenGLHelper::isDeviceDenylisted (vcl/source/opengl/OpenGLHelper.cxx), that function no longer returns true for you, so that OpenGLHelper::supportsOpenGL (vcl/source/opengl/OpenGLHelper.cxx) now returns true, and the slideshow uses OpenGL, which then runs into the > fprintf(stderr, "No provider of %s found. Requires one of:\n", name); > for (i = 0; providers[i] != gl_provider_terminator; i++) { > fprintf(stderr, " %s\n", enum_string + enum_string_offsets[providers[i]]); > } > if (providers[0] == gl_provider_terminator) { > fprintf(stderr, " No known providers. This is likely a bug " > "in libepoxy code generation\n"); > } > abort(); tail of gl_provider_resolver (workdir/UnpackedTarball/epoxy/src/gl_generated_dispatch.c), causing soffice.bin to crash with SIGABRT. @Caloán, Thorsten: I have no idea what that "No provider of glGenVertexArrays found" means, whether it is a bug on our end, an obvious misconfiguration of Timur's environment, or something that can legitimately happen and which that removed X11 OpenGL denylist had shielded us from. It probably depends on that what the best way forward is here? (One thing we might be able to do would be to extend VCLExceptionSignal_impl in vcl/source/app/svmain.cxx to also get called for SIGABRT, so that it would call OpenGLZone::hardDisable(), which would set the /org.officecfg.Office/Common/VCL/DisableOpenGL configuration property, taking effect on the next start after the crash.)
My guess is that something calls glGenVertexArrays and according to https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGenVertexArrays.xhtml that is OpenGL >= 3 and the various logs here suggest that OpenGL >= 3 isn't supported, so some older version presumably. As far as I see, our slideshow has mnRequiredGLVersion which defaults to 3.0 so that would suggest that we shouldn't have tried to use any of our transitions because the condition 3.0 wasn't met. I see a hit on glGenVertexArrays in gtk itself, maybe that one is the trigger. Perhaps we should check earlier if the OpenGL is that min version and give up earlier. Right after impl_initializeFlags we have the version of OpenGL if we checked there that its less than the min and failed at that point maybe we cut off this crash later.
I can pseudo-reproduce this by setting mnRequiredGLVersion to 23 in slideshow/source/engine/opengl/TransitionImpl.hxx and putting a breakpoint on epoxy_glGenVertexArrays_global_rewrite_ptr and it looks to me that once a gtk GLArea is created (or at least realized) then it will be gtk itself that does the glGenVertexArrays call even if we destroy a GLArea and don't use it. @Timur: I wonder what happens if you run gtk3-demo and double-click its OpenGL Area demo? Does it work, fail, crash?
I have high hopes that https://gerrit.libreoffice.org/c/core/+/134350 would avoid this problem
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/da50382b366d6f3de778d8a52136cd812ef5b751 tdf#149068 reject OpenGL versions that don't support glGenVertexArrays It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Caolán McNamara from comment #7) > @Timur: I wonder what happens if you run gtk3-demo and double-click its > OpenGL Area demo? Does it work, fail, crash? No provider of glGenVertexArrays found. Requires one of: Desktop OpenGL 3.0 GL extension "GL_ARB_vertex_array_object" OpenGL ES 3.0 GL extension "GL_APPLE_vertex_array_object" GL extension "GL_OES_vertex_array_object" zsh: abort (core dumped) gtk3-demo I'm waiting for bibisect update to check again.
I'll mark this as fixed and if there is contrary evidence feel free to update with that.
Still crashes with updated bibisect repo (albeit differently, no prior flash). Unspecified Application Error Fatal exception: Signal 6 Stack: /home/t/linux-64-7.4/instdir/program/libuno_sal.so.3(+0x14e48)[0x7f756f8b8e48] /home/t/linux-64-7.4/instdir/program/libuno_sal.so.3(+0x3fef6)[0x7f756f8e3ef6] /lib/x86_64-linux-gnu/libc.so.6(+0x3ef10)[0x7f756f210f10] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f756f210e87] /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f756f2127f1] /home/t/linux-64-7.4/instdir/program/libvcllo.so(+0x797a86)[0x7f7567879a86] /home/t/linux-64-7.4/instdir/program/libvcllo.so(_ZN11Application5AbortERKN3rtl8OUStringE+0xa2)[0x7f75678ba092] /home/t/linux-64-7.4/instdir/program/libsofficeapp.so(+0x28b76)[0x7f756f5ebb76] /home/t/linux-64-7.4/instdir/program/libvcllo.so(+0x7e08d4)[0x7f75678c28d4] /home/t/linux-64-7.4/instdir/program/libuno_sal.so.3(+0x17ea2)[0x7f756f8bbea2] /home/t/linux-64-7.4/instdir/program/libuno_sal.so.3(+0x3fdbf)[0x7f756f8e3dbf] /lib/x86_64-linux-gnu/libc.so.6(+0x3ef10)[0x7f756f210f10] /lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0x116)[0x7f756f2604e6] /lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x1872)[0x7f756f22ebd2] /lib/x86_64-linux-gnu/libc.so.6(vsprintf+0x81)[0x7f756f253681] /lib/x86_64-linux-gnu/libc.so.6(sprintf+0x94)[0x7f756f237054] /var/lib/VBoxGuestAdditions/lib/libGL.so.1(+0xb2a3f)[0x7f751cf5da3f] /home/t/linux-64-7.4/instdir/program/libepoxy.so(epoxy_is_desktop_gl+0x22)[0x7f7560469922] /home/t/linux-64-7.4/instdir/program/libepoxy.so(+0x5ed77)[0x7f7560469d77] /home/t/linux-64-7.4/instdir/program/libepoxy.so(+0x97baa)[0x7f75604a2baa] /home/t/linux-64-7.4/instdir/program/../program/libOGLTranslo.so(+0x87ba)[0x7f751c0637ba] /home/t/linux-64-7.4/instdir/program/../program/libOGLTranslo.so(+0x8ddd)[0x7f751c063ddd] /home/t/linux-64-7.4/instdir/program/libuno_cppuhelpergcc3.so.3(_ZN4cppu27WeakComponentImplHelperBase7disposeEv+0x125)[0x7f756c7eabb5] /home/t/linux-64-7.4/instdir/program/libuno_cppuhelpergcc3.so.3(_ZN4cppu27WeakComponentImplHelperBase7releaseEv+0x3c)[0x7f756c7e924c] /home/t/linux-64-7.4/instdir/program/../program/libOGLTranslo.so(+0x10938)[0x7f751c06b938] /home/t/linux-64-7.4/instdir/program/../program/libslideshowlo.so(+0x1527e4)[0x7f750dd617e4] /home/t/linux-64-7.4/instdir/program/../program/libslideshowlo.so(+0x10b145)[0x7f750dd1a145] /home/t/linux-64-7.4/instdir/program/../program/libsdlo.so(+0x3f0574)[0x7f753204a574] /home/t/linux-64-7.4/instdir/program/../program/libsdlo.so(+0x3f5d3c)[0x7f753204fd3c] /home/t/linux-64-7.4/instdir/program/../program/libsdlo.so(+0x3f783a)[0x7f753205183a] /home/t/linux-64-7.4/instdir/program/../program/libsdlo.so(+0x3f7bd5)[0x7f7532051bd5] /home/t/linux-64-7.4/instdir/program/../program/libslideshowlo.so(+0x10bbb1)[0x7f750dd1abb1] /home/t/linux-64-7.4/instdir/program/../program/libslideshowlo.so(+0xa204c)[0x7f750dcb104c] /home/t/linux-64-7.4/instdir/program/../program/libslideshowlo.so(+0xb6715)[0x7f750dcc5715] /home/t/linux-64-7.4/instdir/program/../program/libslideshowlo.so(+0x106979)[0x7f750dd15979] /home/t/linux-64-7.4/instdir/program/../program/libsdlo.so(+0x3f742a)[0x7f753205142a] /home/t/linux-64-7.4/instdir/program/libvcllo.so(_ZN9Scheduler22CallbackTaskSchedulingEv+0x28b)[0x7f75678a975b] /home/t/linux-64-7.4/instdir/program/libvclplug_gtk3lo.so(+0xdf8ba)[0x7f755556f8ba] /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x155)[0x7f755fb4d3a5] /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4c770)[0x7f755fb4d770] /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c)[0x7f755fb4d7fc] /home/t/linux-64-7.4/instdir/program/libvclplug_gtk3lo.so(+0xe094c)[0x7f755557094c] /home/t/linux-64-7.4/instdir/program/libvcllo.so(+0x7d79d2)[0x7f75678b99d2] /home/t/linux-64-7.4/instdir/program/libvcllo.so(_ZN11Application7ExecuteEv+0x75)[0x7f75678bc175] /home/t/linux-64-7.4/instdir/program/libsofficeapp.so(+0x3005e)[0x7f756f5f305e] /home/t/linux-64-7.4/instdir/program/libvcllo.so(_Z10ImplSVMainv+0x46)[0x7f75678c42a6] /home/t/linux-64-7.4/instdir/program/libsofficeapp.so(soffice_main+0x11d)[0x7f756f61ef4d] /home/t/linux-64-7.4/instdir/program/soffice.bin[0x40066b] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f756f1f3c87] /home/t/linux-64-7.4/instdir/program/soffice.bin[0x40069f]
oh well. It is of course some vm scenario, VirtualBox? (I presume so from /var/lib/VBoxGuestAdditions/lib/libGL.so.1)
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/a37577f9fd74c5f84ee7d24adca3755b6f26a55c tdf#149068 reject OpenGL versions that don't support glGenVertexArrays It will be available in 7.3.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Caolán McNamara from comment #13) > oh well. It is of course some vm scenario, VirtualBox? Yes. Thanks. Let's assume Fixed.
(In reply to Caolán McNamara from comment #13) > oh well. It is of course some vm scenario, VirtualBox? (I presume so from > /var/lib/VBoxGuestAdditions/lib/libGL.so.1) Yes.
Unfortunately for reproduce this, my VirtualBox supports opengl fine and this code path isn't triggered. Its possible that using gdk_gl_context_set_use_es would avoid this specific crash, but probably just push it to another similar location later on
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d77db907465547f8704fd32b2c90165b54873dba tdf#149068 put a OpenGLZone around the sync indirect opengl calls It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1bfbef9ad2092106c8f1f6c3e5942940173c2d15 tdf#149068 don't call any OpenGL if the context is initially 'invalid' It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
maybe that will make a difference
In the meantime I upgraded my VirtualBox and I don't see crash anymore even with old versions, and not with today updated bibi repo. I still close as Fixed due to patches, thanks Caolán.