View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016637 | Scribus | Internal | public | 2021-09-19 20:36 | 2021-11-09 21:39 |
| Reporter | mapreri | Assigned To | jghali | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.5.7 | ||||
| Fixed in Version | 1.5.8.svn | ||||
| Summary | 0016637: Building with LTO causes segfaults on startup | ||||
| Description | Scribus is probably affected by this problem: https://isocpp.org/wiki/faq/ctors#static-init-order Both CommonStrings::None and ColorListModel::m_NoneColor are static, and the latter uses the former for initialization. However, the order of initialization is not guaranteed. When building with LTO, it looks like ColorListModel::m_NoneColor is initialized first, leading to the following, very confusing, segfault: #0 0x00007fe7cd054c74 in std::__atomic_base<int>::load (__m=std::memory_order_relaxed, this=<optimized out>) at /usr/include/c++/10/bits/atomic_base.h:426 0000001 QAtomicOps<int>::loadRelaxed<int> (_q_value=...) at ../../include/QtCore/../../src/corelib/thread/qatomic_cxx11.h:239 0000002 QBasicAtomicInteger<int>::loadRelaxed (this=<optimized out>) at ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:107 0000003 QtPrivate::RefCount::ref (this=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qrefcount.h:55 0000004 QString::operator= (this=this@entry=0x559b454c7ae8 <ColorListModel::m_NoneColor+72>, other=...) at text/qstring.cpp:2408 0000005 0x0000559b44d43595 in ColorPixmapValue::ColorPixmapValue (this=<optimized out>, col=..., doc=<optimized out>, colName=..., this=<optimized out>, col=..., doc=<optimized out>, colName=...) at ./scribus/ui/colorlistmodel.cpp:31 0000006 0x0000559b4472b565 in __static_initialization_and_destruction_0(int, int) [clone .constprop.215] (__priority=65535, __initialize_p=1) at ./scribus/ui/colorlistmodel.cpp:34 0000007 0x0000559b4472de3b in _sub_I_65535_0.0 () 0000008 0x0000559b45183f2d in __libc_csu_init () 0000009 0x00007fe7cc9bd4f1 in __libc_start_main (main=0x559b44721ef0 <main(int, char**)>, argc=2, argv=0x7ffdc2984208, init=0x559b45183ee0 <__libc_csu_init>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdc29841f8) at ../csu/libc-start.c:279 0000010 0x0000559b4472f8fe in _start () The site linked above has a couple of options on how to prevent the "static initialization ordering problem" (by effectively turning one of the object non-static), however it looks like it wouldn't be trivial to apply to this case, where CommonStrings is quite massive. | ||||
| Steps To Reproduce | This was first reported in Ubuntu, where starting with 21.10 hirsute the toolchain defaults to building with LTO (-flto=auto -ffat-lto-objects): https://bugs.launchpad.net/ubuntu/+source/scribus/+bug/1939213 Indeed, disabling LTO produces something that doesn't crash. | ||||
| Additional Information | Thanks to Dmitry Shachnev (mitya57) for debugging and finding the likely issue, and Rik Mills for discovering the role of LTO. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-09-19 20:36 | mapreri | New Issue | |
| 2021-09-19 21:09 | jghali | Severity | minor => crash |
| 2021-09-20 19:46 | jghali | Assigned To | => jghali |
| 2021-09-20 19:46 | jghali | Status | new => resolved |
| 2021-09-20 19:46 | jghali | Resolution | open => fixed |
| 2021-09-20 19:46 | jghali | Fixed in Version | => 1.5.8.svn |
| 2021-09-20 19:46 | jghali | Note Added: 0049251 | |
| 2021-11-09 21:39 | cbradney | Status | resolved => closed |
