Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1866207

Summary: Scribus Segmentation fault
Product: [Fedora] Fedora Reporter: Onyeibo Oku <onyeibo>
Component: scribusAssignee: Pete Walter <walter.pete>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 33CC: andreas.bierfert, dan, law, walter.pete
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: scribus-1.5.6-0.11.fc33 scribus-1.5.6-0.11.fc34 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-08-21 08:50:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace --failed-only --output=scribus.strace
none
Core dump after segfault none

Description Onyeibo Oku 2020-08-05 05:47:45 UTC
Created attachment 1710464 [details]
strace --failed-only --output=scribus.strace

Description of problem:
Scribus segfaults on execution

Version-Release number of selected component (if applicable):
1.5.6-0.10.fc33

How reproducible:
Constant

Steps to Reproduce:
1. Install Scribus
2. Execute Scribus from Terminal
3.

Actual results:
Segmentation fault (core dumped)

Expected results:
A running Scribus

Additional info:
See attached strace output
Apparently Scribus is looking for libraries in non-standard locations.

Comment 1 Dan Horák 2020-08-05 10:04:21 UTC
The failed loads of the libraries are expected, the dynamic linker tries various locations for the libraries. But it would be useful if you posted details from crash. Either from the ABRT tool or from coredumpctl. But I suspect the crash is a side-effect of enabling LTO during the mass-rebuild. Can you verify that scribus-1.5.6-0.9.fc33 [1] works well?

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1545103

Comment 2 Onyeibo Oku 2020-08-05 14:41:53 UTC
I get the following when I attempt to get coredump:
Coredump entry has no core attached (neither internally in the journal nor externally on disk).

downgrading to scribus-1.5.6-0.9.fc33

Comment 3 Onyeibo Oku 2020-08-08 10:39:09 UTC
(In reply to Onyeibo Oku from comment #2)
> 
> downgrading to scribus-1.5.6-0.9.fc33

Still got a Segfault on scribus-1.5.6-0.9.fc33
I upgraded again to 1.5.6-0.10.fc33 -- Better to trace it from there.

Attaching a coredump for 1.5.6-0.10.fc33

Comment 4 Onyeibo Oku 2020-08-08 10:41:15 UTC
Created attachment 1710883 [details]
Core dump after segfault

Comment 5 Onyeibo Oku 2020-08-08 10:43:14 UTC
Stack trace of thread 35641:
#0  0x00007fe65e613644 _ZN7QStringaSERKS_ (libQt5Core.so.5 + 0x148644)
#1  0x0000563ed5952f25 _Z41__static_initialization_and_destruction_0ii.constprop.212 (scribus + 0x346f25)
#2  0x0000563ed5955c61 _sub_I_65535_0.0 (scribus + 0x349c61)
#3  0x0000563ed6389ded __libc_csu_init (scribus + 0xd7dded)
#4  0x00007fe65dfdc12e __libc_start_main (libc.so.6 + 0x2812e)
#5  0x0000563ed595831e _start (scribus + 0x34c31e)

Comment 6 Dan Horák 2020-08-10 07:49:11 UTC
Could you try downgrading to scribus-1.5.6-0.8.fc33 (last build without LTO)? Looking at the backtrace there might be LTO-related runtime issues in other libraries too and there is no simple way how to downgrade to a pre-LTO state (before 2020-07-22) :-(

Comment 7 Onyeibo Oku 2020-08-10 15:02:50 UTC
Error: 
 Problem 1: conflicting requests
  - nothing provides libpoppler.so.94()(64bit) needed by scribus-1.5.6-0.8.fc33.x86_64
 Problem 2: package scribus-devel-1.5.6-0.8.fc33.x86_64 requires scribus = 1.5.6-0.8.fc33, but none of the providers can be installed
  - conflicting requests
  - nothing provides libpoppler.so.94()(64bit) needed by scribus-1.5.6-0.8.fc33.x86_64

Comment 8 Ben Cotton 2020-08-11 15:19:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 9 Dan Horák 2020-08-19 08:26:03 UTC
Could you try the rpms from https://koji.fedoraproject.org/koji/taskinfo?taskID=49596284 ? I have disabled LTO in this scribus build, perhaps it will help.

Comment 10 Onyeibo Oku 2020-08-20 21:56:56 UTC
(In reply to Dan Horák from comment #9)
> Could you try the rpms from
> https://koji.fedoraproject.org/koji/taskinfo?taskID=49596284 ? I have
> disabled LTO in this scribus build, perhaps it will help.

Yes!

That worked.  You need karma on this?

Comment 11 Dan Horák 2020-08-21 07:22:07 UTC
No, I'll do a regular build that will land in F-33 and Rawhide, those are without bodhi (for now).

Comment 12 Dan Horák 2020-08-21 15:09:35 UTC
Jeff, seems there is a runtime LTO related issue. But this is a complex GUI app.

Comment 13 Jeff Law 2020-08-21 15:32:53 UTC
So what precisely do I need to do to reproduce this problem and on what target?

Note that the actual fault point inside the Qt libraries, which I thought were all opted out of LTO due to problems in QT itself.  In combination with c#10 that would indicate that scribus is passing something bogus into the Qt libraries.

Comment 14 Jeff Law 2020-08-21 17:57:27 UTC
So I've been able to reproduce the failure locally.  Thankfully the failure happens without having to mess with the gui or anything -- it's occurring in the static initializers, eg before main() is called.

Comment 15 Jeff Law 2020-08-21 20:55:35 UTC
So as I noted in c#13, I suspect scribus is passing something bogus into the Qt libraries.  Of particular interest is this ctor:

ColorPixmapValue::ColorPixmapValue( const ScColor& col, ScribusDoc* doc, const QString& colName )
{
        m_doc = (doc) ? doc->guardedPtr() : nullptr;
        m_color = col;
        m_name = colName;
}

Note the last assignment which is going to call the QString operator to copy colName into m_name.  It's within that function we fault.

Now the constructor called via:

ColorPixmapValue ColorListModel::m_NoneColor(ScColor(), nullptr, CommonStrings::None);

Thankfully scribus is amenable to .o bisection and its the combination of colorlistmodel and moc_colorlistbox being compiled with LTO enabled that's the triggering event.

I'm still debugging, but wanted to get the notes above recorded for future reference.

Comment 16 Jeff Law 2020-08-21 21:57:55 UTC
I'm confident this is undefined behavior in scribus.

The C++ standard indicates that the order of static ctor initializations is undefined across translation units.  scribus clearly depends CommonStrings::None being initialized before the static initializer for ColorListModel::m_NoneColor

Something like this should fix the problem. 

diff --git a/scribus/ui/colorlistmodel.cpp b/scribus/ui/colorlistmodel.cpp
index a4905a5..d36dfb4 100644
--- a/scribus/ui/colorlistmodel.cpp
+++ b/scribus/ui/colorlistmodel.cpp
@@ -10,7 +10,11 @@ for which a new license (GPL+exception) is in place.
 #include "colorlistbox.h"
 #include "commonstrings.h"
 
-ColorPixmapValue ColorListModel::m_NoneColor(ScColor(), nullptr, CommonStrings::None);
+ColorPixmapValue& ColorListModel::m_NoneColor()
+{
+  static ColorPixmapValue* retval = new ColorPixmapValue(ScColor (), nullptr, CommonStrings::None);
+  return *retval;
+}
 
 ColorListModel::ColorListModel(QObject *parent)
                  : QAbstractItemModel(parent)
diff --git a/scribus/ui/colorlistmodel.h b/scribus/ui/colorlistmodel.h
index 8f5bc65..fb1e24d 100644
--- a/scribus/ui/colorlistmodel.h
+++ b/scribus/ui/colorlistmodel.h
@@ -104,11 +104,11 @@ protected:
        SortRule m_sortRule;
 
        //! Dummy object used to represent None Color
-       static ColorPixmapValue m_NoneColor;
+       static ColorPixmapValue& m_NoneColor();
 
        static bool compareColorNames(const ColorPixmapValue& v1, const ColorPixmapValue& v2);
        static bool compareColorValues(const ColorPixmapValue& v1, const ColorPixmapValue& v2);
        static bool compareColorTypes(const ColorPixmapValue& v1, const ColorPixmapValue& v2);
 };
 
-#endif // COLORLISTMODEL_H
\ No newline at end of file
+#endif // COLORLISTMODEL_H

Essentially it avoids the static constructor for m_NoneColor and initializes it at use time.  Note that AFAICT this member is never used within scribus (because we didn't have to change any use sites).  So an even better solution is to delete the static data member and initializer like this.  AFAICT the header is not exported outside scribus, so it should be safe to make changes to the class as there's no DSO or header ABI to maintain.

diff --git a/scribus/ui/colorlistmodel.cpp b/scribus/ui/colorlistmodel.cpp
index a4905a5..8363e97 100644
--- a/scribus/ui/colorlistmodel.cpp
+++ b/scribus/ui/colorlistmodel.cpp
@@ -10,8 +10,6 @@ for which a new license (GPL+exception) is in place.
 #include "colorlistbox.h"
 #include "commonstrings.h"
 
-ColorPixmapValue ColorListModel::m_NoneColor(ScColor(), nullptr, CommonStrings::None);
-
 ColorListModel::ColorListModel(QObject *parent)
                  : QAbstractItemModel(parent)
 {
diff --git a/scribus/ui/colorlistmodel.h b/scribus/ui/colorlistmodel.h
index 8f5bc65..892d0a7 100644
--- a/scribus/ui/colorlistmodel.h
+++ b/scribus/ui/colorlistmodel.h
@@ -103,12 +103,9 @@ protected:
        // SortRule m_sortRule
        SortRule m_sortRule;
 
-       //! Dummy object used to represent None Color
-       static ColorPixmapValue m_NoneColor;
-
        static bool compareColorNames(const ColorPixmapValue& v1, const ColorPixmapValue& v2);
        static bool compareColorValues(const ColorPixmapValue& v1, const ColorPixmapValue& v2);
        static bool compareColorTypes(const ColorPixmapValue& v1, const ColorPixmapValue& v2);
 };
 
-#endif // COLORLISTMODEL_H
\ No newline at end of file
+#endif // COLORLISTMODEL_H

Anyway, I'm confident this is a package problem, not an LTO problem.  I've installed the latter patch and re-enabled LTO. I leave it up to the package maintainer to negotiate with upstream.