In the daily Linux dbgutil bibisect repository, I did ... SAL_USE_VCLPLUG=gen instdir/program/soffice --norestore On the splash screen, the progress bar went to about 30%, then the program crashed with SIGSEGV. The backtrace is very long; I cancelled it after about 15,000 call levels. The first few levels are ( I am not even going to try to break the lines) ... #0 0x00007ff4e8806393 in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libtllo.so #1 0x00007ff4e8800c1d in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libtllo.so #2 0x00007ff4e88023cd in ResMgr::GetResource(ResId const&, Resource const*) () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libtllo.so #3 0x00007ff4e88026b5 in ResMgr::GetResourceSkipHeader(ResId const&, ResMgr**) () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libtllo.so #4 0x00007ff4e72f48a8 in BitmapEx::BitmapEx(ResId const&) () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #5 0x00007ff4d304ab98 in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvclplug_genlo.so #6 0x00007ff4d304b050 in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvclplug_genlo.so #7 0x00007ff4d304c3ba in X11SalFrame::Init(SalFrameStyleFlags, SalX11Screen, SystemParentData*, bool) () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvclplug_genlo.so #8 0x00007ff4d304d807 in X11SalFrame::X11SalFrame(SalFrame*, SalFrameStyleFlags, SystemParentData*) () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvclplug_genlo.so #9 0x00007ff4d2fe192a in X11SalInstance::CreateFrame(SalFrame*, SalFrameStyleFlags) () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvclplug_genlo.so #10 0x00007ff4e714b6be in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #11 0x00007ff4e6f99619 in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #12 0x00007ff4e6f99912 in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #13 0x00007ff4e716fc76 in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #14 0x00007ff4e716e621 in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #15 0x00007ff4e716ec4f in WorkWindow::WorkWindow(vcl::Window*, long) () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #16 0x00007ff4e7559c65 in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #17 0x00007ff4e7558491 in ImplGetDefaultContextWindow() () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #18 0x00007ff4e75583b5 in ImplGetDefaultWindow() () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #19 0x00007ff4e7550adb in Application::GetDefaultDevice() () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #20 0x00007ff4e7501b31 in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #21 0x00007ff4e75027ec in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #22 0x00007ff4e7501f4b in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #23 0x00007ff4e7501972 in ?? () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #24 0x00007ff4e72f4991 in BitmapEx::loadFromIconTheme(rtl::OUString const&) () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so #25 0x00007ff4e72f48e6 in BitmapEx::BitmapEx(ResId const&) () from /home/terry/lo_hacking/bibisect/lo-linux-dbgutil-daily/opt/program/libvcllo.so Frames 4 through 25 repeat at least as far as frame 300. In that same repository, I see from `git bisect good` (newlines added) ... 147666bfa50190cfea00dd092e59e22d796bc974 is the first bad commit commit 147666bfa50190cfea00dd092e59e22d796bc974 Author: Miklos Vajna <vmiklos@collabora.co.uk> Date: Sun Oct 30 05:58:38 2016 +0100 2016-10-30: source-hash-be1750d866dab7712ede4cbbba771b088d862d05 :100644 100644 ee2674b74879ab46a7348d5dd14670695c63de0d 513052830dec20dc5cd11eda4991f4dc9744490f M build-info.txt :040000 040000 9a2caa4cbb3451fd4f71bec9fd818492a5572505 7b6e3f6a4bdc59b29df040b510cfdbd4f7b37058 M opt and from `git bisect log` (newlines added) ... # bad: [519eb89166bcca484ed9975955f8259e69e650f0] 2016-10-31: source-hash-1011f99ed63b61d9f9a469388729fa7d1b5bf960 # good: [9a9b8d528eca194b445970adb953e5da53458f4a] 2016-10-25: source-hash-b5c65b53de6663e12a8192100d6e25494779c5c7 git bisect start 'origin/master' '9a9b8d528eca194b445970adb953e5da53458f4a' # good: [9f192fa1e3698891ebdf9346fbf968dda0c294ac] 2016-10-28: source-hash-eb07ae8fc52378d9b59bcb6a7df8bb022b8b9cc0 git bisect good 9f192fa1e3698891ebdf9346fbf968dda0c294ac # bad: [147666bfa50190cfea00dd092e59e22d796bc974] 2016-10-30: source-hash-be1750d866dab7712ede4cbbba771b088d862d05 git bisect bad 147666bfa50190cfea00dd092e59e22d796bc974 # good: [12a5c2be4d64199c6540969c645118112084a639] 2016-10-29: source-hash-f19f88a0d49859eb714711cac72793f09f5f7d5c git bisect good 12a5c2be4d64199c6540969c645118112084a639 # first bad commit: [147666bfa50190cfea00dd092e59e22d796bc974] 2016-10-30: source-hash-be1750d866dab7712ede4cbbba771b088d862d05 These observations are from debian-stretch. I am setting priority high and keywords regression, bibisected.
Not changing priority after all: insufficient permission.
Correct line is SAL_USE_VCLPLUGIN=gen instdir/program/soffice --norestore Confirmed in Version: 5.3.0.0.alpha1+ Build ID: 64d3bd38c9242c1cc114f6e68bf13475ef679b73 CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; VCL: gen;layout Engine: old; Locale: ca-ES (ca_ES.UTF-8); Calc: group
*** Bug 103666 has been marked as a duplicate of this bug. ***
/confirm Program starts with "SAL_USE_VCLPLUGIN=gtk2 opt/libreofficedev5.3/program/swriter" (or gtk3). Version: 5.3.0.0.alpha1+ Build ID: c8be45889217c555e4bec92af838d0524ceba4e0 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; Layout Engine: old; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-11-02_23:37:13 Locale: en-US (en_US.UTF-8); Calc: group
Let's increment priority. BTW, I had put Valgrind and strace in tdf#103666
Created attachment 128470 [details] GDB symbol bt with appicon recursion
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=36888dc9607b6ce1f98a0a7fcd1069ded091aec1 tdf#103626 Workaround for AppIcon recursion It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The patch is just a temporary workaround. It prevents the crash, but the application won't have an application icon. Has to be reverted, when the underlying problem is fixed.
Jan-Marek Glogowski, Shouldn't there be a FIXME: in there? This circumvents the entire logic of the function leaving it all as unreachable code.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=96b95f5010be090ebae6f755d4d3891a2334332c tdf#103626 don't scale application icon to prevent a start-up loop It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I see no problem in daily Linux dbgutil bibisect repository version 2016-12-26. I am setting status VERIFIED FIXED. Thank you, Tomaž.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=377b8de39201b4f2b7f93f6a23f828a27e4ed2bc&h=libreoffice-5-3 tdf#103626 don't scale application icon to prevent a start-up loop It will be available in 5.3.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Target cleaning