Created attachment 1920611 [details] dnf history info Description of problem: After today's dnf upgrade, any attempt to launch Scribus (GUI, CMD, without sudo, with sudo) ends up with Scribus crashing with the same error message "Scribus crashes due to Signal #6". I was actually using Scribus yesterday and everything worked just fine. And the only thing that changed on my system between yesterday and today was the dnf upgrade (I have a bad habbit of running dnf upgrade every time I turn on the computer). I'm running XFCE spin of Fedora 36. Apart from some games, all installed packages comes either from Fedora official repositories or RPM Fusion free and free-tainted repositories. I've upgraded my system one more time after discovering the bug but it didn't solve the issue. Version-Release number of selected component (if applicable): scribus-1.5.7-9.fc36.x86_64.rpm Additional info: GBD backtrace: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007ffff4c8ec73 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007ffff4c3e986 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff4c287f4 in __GI_abort () at abort.c:79 #4 0x00007ffff4c2871b in __assert_fail_base (fmt=0x7ffff4dbbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff74bf328 "exception->signature == MagickSignature", file=0x7ffff74d15b8 "magick/error.c", line=1025, function=<optimized out>) at assert.c:92 #5 0x00007ffff4c37536 in __GI___assert_fail (assertion=assertion@entry=0x7ffff74bf328 "exception->signature == MagickSignature", file=file@entry=0x7ffff74d15b8 "magick/error.c", line=line@entry=1025, function=function@entry=0x7ffff74d28e0 <__PRETTY_FUNCTION__.0.lto_priv.9> "ThrowLoggedException") at assert.c:101 #6 0x00007ffff740c838 in ThrowLoggedException (exception=0x7fffffffd440, severity=ModuleError, reason=0x7ffff74d7d2b <message_dat+8331> "Unable to load module", description=0x7fffffffca30 "\"/usr/lib64/GraphicsMagick-1.3.38/modules-Q16/coders/url.la: file not found\"", module=0x7ffff74d3dea "magick/module.c", function=0x7ffff74d5148 <__func__.6.lto_priv.4> "OpenModule", line=1426) at magick/error.c:1025 #7 0x00007ffff742b0ae in OpenModule (module=0x5555569824e0 "URL", exception=exception@entry=0x7fffffffd440) at magick/module.c:1426 #8 0x00007ffff742b29c in OpenModules (exception=exception@entry=0x7fffffffd440) at magick/module.c:1537 #9 0x00007ffff742b398 in GetMagickInfo (name=name@entry=0x7ffff74d4428 "*", exception=exception@entry=0x7fffffffd440) at magick/magick.c:432 #10 0x00007ffff742b3f0 in GetMagickInfoArray (exception=0x7fffffffd440) at magick/magick.c:519 #11 0x0000555555e0d299 in FormatsManager::FormatsManager (this=<optimized out>, this=<optimized out>) at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/util_formats.cpp:55 #12 0x0000555555e0f08d in FormatsManager::instance () at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/util_formats.cpp:167 #13 0x00007fffe001ee6a in WMFImportPlugin::registerFormats (this=0x555556d55430) at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/plugins/import/wmf/wmfimportplugin.cpp:108 #14 0x00007fffe001f2b0 in WMFImportPlugin::WMFImportPlugin (this=<optimized out>, this=<optimized out>) at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/plugins/import/wmf/wmfimportplugin.cpp:66 #15 0x00007fffe001f34f in wmfimplugin_getPlugin () at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/plugins/import/wmf/wmfimportplugin.cpp:48 #16 0x0000555555bd5cf2 in PluginManager::loadPlugin (this=<optimized out>, pluginData=...) at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/pluginmanager.cpp:550 #17 0x0000555555bdeba7 in PluginManager::initPlugin (this=0x555556e62870, fileName=...) at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/pluginmanager.cpp:167 #18 0x0000555555bdf060 in PluginManager::initPlugs (this=0x555556e62870) at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/pluginmanager.cpp:200 #19 0x0000555555d1ee9e in ScribusCore::initScribusCore (this=0x555556820000, showSplash=<optimized out>, showFontInfo=<optimized out>, showProfileInfo=<optimized out>, newGuiLanguage=...) at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/scribuscore.cpp:186 #20 0x0000555555d1f108 in ScribusCore::startGUI (this=0x555556820000, showSplash=<optimized out>, showFontInfo=<optimized out>, showProfileInfo=<optimized out>, newGuiLanguage=...) at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/scribuscore.cpp:99 #21 0x0000555555d1f3a2 in ScribusQApp::init (this=0x7fffffffd990) at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/scribusapp.cpp:365 #22 0x0000555555933ab8 in mainApp (argc=<optimized out>, argv=0x7fffffffdb38) at /usr/src/debug/scribus-1.5.7-9.fc36.x86_64/scribus/main_nix.cpp:72 #23 0x00007ffff4c29510 in __libc_start_call_main (main=main@entry=0x5555558baff0 <main(int, char**)>, argc=argc@entry=1, argv=argv@entry=0x7fffffffdb38) at ../sysdeps/nptl/libc_start_call_main.h:58 #24 0x00007ffff4c295c9 in __libc_start_main_impl (main=0x5555558baff0 <main(int, char**)>, argc=1, argv=0x7fffffffdb38, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdb28) at ../csu/libc-start.c:389 #25 0x00005555558c7225 in _start () Metadata about the dnf transaction are in the attachment.
Hm, since I'm doing the dnf upgrade pretty much everyday and it might so happen, that some things have to be restarted for the upgrade to take effect, I've also checked what was upgraded in yesterday's dnf transaction and lo and behold it was glibc: Packages Altered: Upgrade glibc-2.35-20.fc36.x86_64 @updates Upgraded glibc-2.35-17.fc36.x86_64 @@System Upgrade glibc-all-langpacks-2.35-20.fc36.x86_64 @updates Upgraded glibc-all-langpacks-2.35-17.fc36.x86_64 @@System Upgrade glibc-common-2.35-20.fc36.x86_64 @updates Upgraded glibc-common-2.35-17.fc36.x86_64 @@System Upgrade glibc-devel-2.35-20.fc36.x86_64 @updates Upgraded glibc-devel-2.35-17.fc36.x86_64 @@System Upgrade glibc-doc-2.35-20.fc36.noarch @updates Upgraded glibc-doc-2.35-17.fc36.noarch @@System Upgrade glibc-gconv-extra-2.35-20.fc36.x86_64 @updates Upgraded glibc-gconv-extra-2.35-17.fc36.x86_64 @@System Upgrade glibc-headers-x86-2.35-20.fc36.noarch @updates Upgraded glibc-headers-x86-2.35-17.fc36.noarch @@System Upgrade glibc-langpack-en-2.35-20.fc36.x86_64 @updates Upgraded glibc-langpack-en-2.35-17.fc36.x86_64 @@System
I can reproduce, but it looks like the actual problem is in GraphicsMagick rather than in scribus, it fails there when loading/processing modules.
Bases on the previous comment, I've changed the component from "scribus" to "GraphicsMagick". Bug still persists and is also present in Fedora 37 Xfce Beta. I've tested it by creating two virtual machines-Fedora 36 Xfce and Fedora 37 Xfce Beta-with nothing installed manually but scribus. Bug is present on both of those machines. Appimage from upstream works on both of them.
The problem is the new version of libxml2. Downgrading libxml2 is a hotfix to make GM work again (and this scribus). Not that GM itself is broken, too. Just try: gm convert -list format Rebuilding GM against the current version of libxml2 is the proper fix. I would provide a copr repo, but copr has a planned outage, so koji scratch build will have to do for now: https://koji.fedoraproject.org/koji/taskinfo?taskID=93570470
https://src.fedoraproject.org/rpms/GraphicsMagick/pull-request/2 for convenience
Can confirm that after installing GraphicsMagick-1.3.38-2.fc36.x86_64.rpm bug is no longer present on Fedora 36 and both GraphicsMagick as well as Scribus seems to work well. Thanks for the quick fix! I'm not very familiar with bugzilla workflow though, so I'm not quite sure who should close this bug (me as a reporter vs someone from QA) and when should the bug be closed. Should I wait until the fixes for both Fedora 36 and Fedora 37 make their way into Fedora Updates repositories? Or can I close the bug some time before that happens?
rrezh, thanks for your report and for confirming that the fix works for you. This is much appreciated input, you've done everything right! Now it is up to the maintainers to merge the pull-request and submit the fix as an update for Fedora Linux 36 (and possibly 37). They will update the bug to "assigned" when they take up this task, to "closed" when the update is submitted (and possibly to intermediate states in between). (I'm no GM maintainer, just another scribus hacker^Wuser.)
*** Bug 2138637 has been marked as a duplicate of this bug. ***
FEDORA-2022-5117b65a10 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-5117b65a10
Note: Scribus works after upgrading to Fedora 37.
FEDORA-2022-5117b65a10 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-5117b65a10` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5117b65a10 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Well, really, the problem is that libxml2 changed ABI without changing soname. That is not supposed to happen. We're covering that in https://bugzilla.redhat.com/show_bug.cgi?id=2139546 . I'm sending a build of libxml2 which should restore all the important lost symbols and hopefully make the existing builds of dependent packages work (thanks mtasaka for figuring out the options). *** This bug has been marked as a duplicate of bug 2139546 ***
(In reply to Adam Williamson from comment #12) > Well, really, the problem is that libxml2 changed ABI without changing > soname. That is not supposed to happen. We're covering that in We certainly agree on that. There are two options to react: - adjust to the new libxml build (which should not have been pushed) by rebuilding depending packages - revert libxml to the old ABI Mixing these won't work, obviously. > https://bugzilla.redhat.com/show_bug.cgi?id=2139546 . I'm sending a build of > libxml2 which should restore all the important lost symbols and hopefully > make the existing builds of dependent packages work (thanks mtasaka for > figuring out the options). What determines "important"? Does that restore the old ABI completely? Have you confirmed that existing builds for depending packages will indeed work with your libxml rebuild? Why not revert to the previous libxml2 build (with epoch bump)? I have a bad feeling that packages like GraphicsMagick will need yet another rebuild against your libxml build. In that case we'd better adjust to the reduced symbol set since upstream deprecated parts of the ABI.
See the other bug for details, there's no point duplicating the discussion.
FEDORA-2022-5117b65a10 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
Arg, so the update referenced above was built against the wrong libxml2, does it need rebuilding against the fixed libxml2 now?
I don't think it *needs* to be rebuilt, no? The update should have just added back symbols that were missing before, it shouldn't cause anything built against the previous build not to run, unless I'm missing something about how this works. Of course, if you actually want to have FTP support or whatever you could rebuild it, I guess...
*** Bug 2141612 has been marked as a duplicate of this bug. ***
Scribus starts OK with scribus-1.5.7-9.fc36.ppc64le libxml2-2.10.3-2.fc36.ppc64le GraphicsMagick-1.3.38-2.fc36.ppc64le I have updates-testing enabled and do update daily.