Bug 1866207

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

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

(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

Created attachment 1710883 [details]
Core dump after segfault

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)

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) :-(

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

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

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.

(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?

No, I'll do a regular build that will land in F-33 and Rawhide, those are without bodhi (for now).

Jeff, seems there is a runtime LTO related issue. But this is a complex GUI app.

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.

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.

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.

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.