Arch Linux

The gdal warnings are irrelevant. Please post a backtrace of the crash

Okay, Thanks.


$ gdb scribus
GNU gdb (GDB) 10.2

Reading symbols from scribus...
(No debugging symbols found in scribus)
(gdb) run
Starting program: /usr/bin/scribus
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff154c640 (LWP 43482)]
[New Thread 0x7fffebcae640 (LWP 43483)]
[New Thread 0x7fffeb4ad640 (LWP 43484)]
[New Thread 0x7fffeaa92640 (LWP 43485)]
[New Thread 0x7fffea259640 (LWP 43486)]
[New Thread 0x7fffe8e99640 (LWP 43487)]
[New Thread 0x7fffda570640 (LWP 43488)]
[New Thread 0x7fffd9d6f640 (LWP 43489)]
[New Thread 0x7fffd956e640 (LWP 43490)]
[Detaching after fork from child process 43491]
[Detaching after fork from child process 43492]
[Detaching after fork from child process 43493]
[Detaching after fork from child process 43494]
[Detaching after fork from child process 43495]
Warning: dynamic library '/usr/lib/osgPlugins-3.6.5/osgdb_ogr.so' exists, but an error occurred while trying to open it:
libgdal.so.29: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
sizeof(TrkHeader)=1000
ReaderWriterTF::writeObject
Warning: dynamic library '/usr/lib/osgPlugins-3.6.5/osgdb_vnc.so' exists, but an error occurred while trying to open it:
libvncclient.so.1: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
Warning: dynamic library '/usr/lib/osgPlugins-3.6.5/osgdb_gdal.so' exists, but an error occurred while trying to open it:
libgdal.so.29: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
pathForIcon: Unable to load icon /usr/share/scribus/icons/1_5_1/lab.png: File not found
pathForIcon: Unable to load icon /usr/share/scribus/icons/1_5_1/spot.png: File not found
pathForIcon: Unable to load icon /usr/share/scribus/icons/1_5_1/register.png: File not found
qt.gui.icc: Unsupported ICC profile class 70727472
QPngHandler: Failed to parse ICC profile

Thread 1 "scribus" received signal SIGSEGV, Segmentation fault.
0x00007ffff5278a0e in __strcmp_avx2 () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff5278a0e in __strcmp_avx2 () at /usr/lib/libc.so.6
#1 0x00007ffff478ea4a in g_str_equal () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff478f832 in g_hash_table_lookup () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff47b52f6 in g_intern_static_string () at /usr/lib/libglib-2.0.so.0
#4 0x00007ffff03a1cc5 in g_param_spec_internal () at /usr/lib/libgobject-2.0.so.0
#5 0x00007ffff03a24c3 in g_param_spec_object () at /usr/lib/libgobject-2.0.so.0
#6 0x00007ffff0691eb7 in () at /usr/lib/libgtk-3.so.0
#7 0x00007ffff03b69eb in () at /usr/lib/libgobject-2.0.so.0
#8 0x00007ffff03bd89f in () at /usr/lib/libgobject-2.0.so.0
#9 0x00007ffff03be279 in g_type_class_ref () at /usr/lib/libgobject-2.0.so.0
#10 0x00007ffff03a7b0c in g_object_new_valist () at /usr/lib/libgobject-2.0.so.0
#11 0x00007ffff03a7bea in g_object_new () at /usr/lib/libgobject-2.0.so.0
#12 0x00007ffff069840b in gtk_file_chooser_dialog_new () at /usr/lib/libgtk-3.so.0
#13 0x00007ffff0cf75fd in () at /usr/lib/qt/plugins/platformthemes/libqgtk3.so
#14 0x00007ffff0cfc1d4 in () at /usr/lib/qt/plugins/platformthemes/libqgtk3.so
#15 0x00007ffff6600d4e in QDialogPrivate::platformHelper() const () at /usr/lib/libQt5Widgets.so.5
#16 0x00007ffff661686b in QFileDialogPrivate::init(QFileDialogArgs const&) () at /usr/lib/libQt5Widgets.so.5
#17 0x00007ffff6616d0b in QFileDialog::QFileDialog(QWidget*, QFlags<Qt::WindowType>) () at /usr/lib/libQt5Widgets.so.5
#18 0x000055555606587c in NewDocDialog::createOpenDocPage() ()
#19 0x0000555556068cdc in NewDocDialog::NewDocDialog(QWidget*, QStringList const&, bool, QString const&) ()
#20 0x0000555555d7d9fa in ScribusMainWindow::startUpDialog() ()
#21 0x0000555555d991f7 in ScribusCore::startGUI(bool, bool, bool, QString const&) ()
#22 0x0000555555d8b3e4 in ScribusQApp::init() ()
#23 0x000055555594518a in mainApp(int, char**) ()
#24 0x00007ffff5144b25 in __libc_start_main () at /usr/lib/libc.so.6
#25 0x00005555558e790e in _start ()
(gdb) quit

Thanks, I confirm the crash when using QT_QPA_PLATFORMTHEME=gtk3. You should report this upstream.

Is this still a problem? I am unable to replicate it using the scribus-1.5.7-2 package. Neither by default nor with the env var mentioned by Antonio does it crash for me.

Hello, I have scribus 1.5.7-2 installed and it crashes with the same backtrace by me.

i can confirm, too: my scribus 1.5.7-2 is still crashing.

Per @arojas's suggestion above, has anybody that is actually able to reproduce this reported it upstream? I'm willing to help with the packaging it it turns out to be something we can fix, but it sounds like an upstream issue and I don't have a desktop environment where this is a problem so I'm sure I'm the best one to report it.

Please cross-link it here when it is reported.

This is fixed for me with gtk 3.24.30+62+g8d04980f38, please confirm

extra/gtk3 1:3.24.30+62+g8d04980f38-2 (7.6 MiB 48.5 MiB) (Installed)

No fix, still crashing for me.

my scribus 1.5.7-7 is still crashing.

Hi all,

OK, this is really vexing.  FS#71277  shows what is apparently the same error -- it contains one workaround, which is to run as root. This is a workaround for me, too, scribus 1.5.7-7.  FS#71277  was closed as WFM because the 17 June 2021 update to scribus 1.5.7-1 resolved the problem for the reporter (lcv). (1.5.7-1 won't run for me, I assume because of dependency hell.)

Please see also: https://forums.scribus.net/index.php/topic,4139.msg19250.html
as well as: https://forums.scribus.net/index.php/topic,4059.msg18968.html

Obviously running as root isn't a solution, and seems to show there is something permissions related going on (he guessed optimistically)??? When I run it as root at the command line I get exactly the same warnings spew except for the addition of:

"QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'"

and there is no:

"Scribus Crash
-------------
Scribus crashes due to Signal #11
Calling Emergency Save"

obviously. My backtrace shows it crashes thusly:

"Thread 1 "scribus" received signal SIGSEGV, Segmentation fault.
0x00007ffff524b2da in __strcmp_ssse3 () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff524b2da in __strcmp_ssse3 () at /usr/lib/libc.so.6"

Only difference seems to be which architecture optimized strcmp glibc is employing(?). Speaking of architecture and age of CPU, this old laptop's /proc/cpuinfo says in part:

vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz
stepping : 10
microcode : 0xa0c
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority vpid dtherm ida

A somewhat newer old one:

vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
stepping : 7
microcode : 0x1b
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm epb pti tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm arat pln pts

This newer one also crashes, in __strcmp_sse2_unaligned in this case.

My newest laptop, a ThinkPad E595:

vendor_id : AuthenticAMD
cpu family : 23
model : 24
model name : AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx
stepping : 1
microcode : 0x8108102
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate ssbd ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca sme sev sev_es

On this newest laptop, scribus runs without a problem as an unprivileged user. Isn't something weird happening around CPU architecture and permissions?... I'm obviously not an expert.

I'm assuming this is a fairly narrow problem. There aren't hundreds of people screaming about it in FlySpray or on the Scribus forums. This isn't much, but HTH. I will try running the appimage later, assuming I can figure out how to run appimages ;^)

Clemmitt Sigler

Hello again,

More (largely useless) info. I downloaded the appimage generated Nov. 11 from https://gitlab.com/scribus/scribus/-/jobs -- with it I get a bunch of warnings like this:

"Fontconfig warning: "/etc/fonts/conf.d/10-hinting-slight.conf", line 4: unknown element "description""

Before that I get:

"Run experimental bundle that bundles everything
Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed"

Finally, I get:

"Fontconfig warning: FcPattern object weight does not accept value [40 210)
Segmentation fault (core dumped)"

gdb is no help because zero symbols:

"Thread 1 "ld-linux-x86-64" received signal SIGSEGV, Segmentation fault.
0x00007fffe53a3fc4 in ?? () from /tmp/.mount_ScribuHhPKDv/usr/lib/libQt5XcbQpa.so.5"

I also built scribus-svn 24770-1 from AUR on my fast laptop. With the Arch pkgs I can run 'scribus -h', 'scribus -v', etc., non-graphical branches to exit, but not the graphics unless it's run as root. Is there any chance this is due to some weird Qt thing? Just spitballin' :^\

TIA.

Clemmitt

Sorry -- duplicate comment -- removed

Hi there,

I had a similar problem (#11 signal), I don’t know if it has same origin but what did the job for me :

Use the no-splash option which disable starting screen, after that Scribus start at document creation and seems to work fine.
Following lines from scribus -h gave me this idea (french version, sorry about that) :
-ns, --no-splash Ne pas afficher l'écran de démarrage
-nns, --never-splash Cesse d'afficher l'écran de démarrage au démarrage. Ecrit un fichier vide appelé .neversplash dans ~/.config /scribus
I confirm that using -nns option works even after launching program out of a terminal (from start menu or from a file)

Hope this might help you having Scribus working and maybe debugging the problem.

@AdrienHegy

On both of my old laptops, using the '-ns' switch didn't help. Still crashed with Sig11. I'm very happy yours is working :D

I will try with the '-ns' switch to get tracebacks when I have time. Thanks again :)

Clemmitt

Update -- On both laptops, running under gdb as `/usr/bin/scribus -ns' still crashes exactly the same way for me, so --no-splash isn't a workaround for me :(

Clemmitt

@AdrienHegy
--no-splash works for me too! Thanks!

My version is 1.5.8svn rev.24772

Given @javum anad @cmsigler have different results here, is it possible we're chasing more than one bug? Has anybody tried to find anything in upstream issue trackers using the -ns workaround?

Here is a gdb session trying to run scribus without and with -ns option.
Don’t think it’s really relevant though.

Let me know if you think I can try something more useful.

Same problem when starting scribus.
For me it works when opening an existing *.sla (scribus) file. Then everything seems ok. Maybe this helps.

Hello, alerque and all,

Thank you, Steelhe. Stupidly, I had never even thought to try opening an existing file via:

$ scribus foo.sla

This works. No crash, and without resorting to using --no-splash. So this solves my problem, but....

Maybe there *are* multiple subtle bugs. Which is bad :\

Please allow me to again reference closed  FS#71277  from which I learned to try running scribus as root to get it to run without crashing. This works for me *every*time*. There must be some nugget of wisdom we can learn from this, no?

Of course, my root user/home directory has never run a desktop environment. I run XFCE as my desktop so my regular user's home directory is littered with all sorts of GTK configuration/preferences files. This obviously is not true of the root user.

Is it possible that some GTK setting in my home directory is causing this??? Am I crazy to suggest this? :O

(What I am slowly figuring out is I have basically no idea how Qt graphical apps run on a GTK-based desktop.)

It just seems bizarre that elevating permission by running as root would get rid of a crash that has a backtrace like this:

#0 0x00007ffff50862da in __strcmp_ssse3 () at /usr/lib/libc.so.6
#1 0x00007ffff45abc1a in g_str_equal () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff45aca02 in g_hash_table_lookup () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff45d26c6 in g_intern_static_string ()
at /usr/lib/libglib-2.0.so.0
#4 0x00007ffff01ab1f5 in g_param_spec_internal ()
at /usr/lib/libgobject-2.0.so.0
#5 0x00007ffff01abad3 in g_param_spec_object ()
at /usr/lib/libgobject-2.0.so.0
#6 0x00007ffff048e967 in () at /usr/lib/libgtk-3.so.0
#7 0x00007ffff01beb7b in () at /usr/lib/libgobject-2.0.so.0
.
.
.

I will create a new user and see if scribus crashes. More when I have time to test this out.

Thank you all for putting up with the aggravation of helping debug this.

Clemmitt

Hello again,

I have a very interesting result to my little investigation. Steps:

1.) I installed LXQt so I had a purely(? is there such a thing?) Qt-based desktop.
2.) I created a blank new user account. I did no desktop/window manager configuration whatsoever for this account.
3.) I logged into the new account on the desktop or window manager.
4.) I ran scribus to see if it crashed.

Easy peasy. Results:

- Using this "blank" account, I ran Xfce, GNOME Classic, GNOME, Cinnamon and LXQt (using Openbox as WM for LXQt). Scribus crashed under *all* of these.
- With LXQt comes Openbox for "free." So I gave it a shot. And....

BINGO!!!!!! Scribus runs without crashing under Openbox!!! I opened both an Xfce-terminal and a good ol' Xterm, then called scribus from the command line. It just worked. The only difference was the underlying graphical environment.

So, I assume there clearly is a graphical environment/library component or dependence causing this weird crash. Is scribus somehow triggering an extremely obscure bug in GTK? Or something else like that?

Please let me know what other information I can provide that may help.

Clemmitt

Hi again,

To summarize for anyone finding this Flyspray bug report --

If scribus crashes right at startup with signal 11, SIGSEGV, Segmentation fault:

1.) Try running scribus without splash screen; from the command line use --no-splash (-ns) switch -- $ scribus -ns
2.) Run scribus from the command line to open an existing .sla file (scribus XML-formatted save file) -- $ scribus foo.sla
3.) Try running scribus under Openbox window manager instead of a desktop environment
4.) ==>AT YOUR OWN RISK<== (you allow an attacker through a huge security hole, you bought it), try running scribus as root, e.g., by using sudo

These crashes seem (not definitively) to be caused by either or both the graphical splashscreen or the initial file open dialog window. If I missed or didn't understand anything, please correct me! TIA

Clemmitt

Hi again again,

I have a few more results of experimentation. On the brand new "blank" (clean of settings) user account I created, I can run both the scribus 1.5.7 stable and the 1.5.8svn nightly AppImages. This seems to work on any desktop -- Openbox, LXQt, XFCE.

HOWEVER, if I try to run these AppImages under my daily driver username (with tons of accumulated GTK, Qt, yada yada, settings under ~/.config) they both crash horribly with SIGSEGV before even trying to draw anything on the screen....

I'd be happy to try stuff if these seem to be helpful symptoms to figure out how things are failing. Thanks again to all!

Clemmitt

Hi one more time,

I managed to get the AUR pkg scribus-stable 1.4.8-1 patched to build. I will find time in the next few days to update that AUR pkg. I will also report my patch upstream. I suspect the error it gave me is related to gcc throwing an error rather than a warning, and that this changed with the upgrade to gcc ver. 11 or ver. 11.1(?).

EDIT: This was changed in gcc 11. Please see this gcc bug report -- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699

The good news is, if you install scribus-stable from the AUR it should work. It ran fine for me, even with the splash screen, and popped open the initial file open dialog window -- no more crash.

So, if scribus 1.5.7 is crashing and the older version will do what you need, try scribus-stable from AUR :) HTH.

Clemmitt

Hi,

OK, with just a bit more time to play around, I have found a way I can avoid these signal 11 crashes. It works on both of my ancient laptops where scribus has been crashing during start-up more often than not.

1.) Open an existing scribus .sla file -- $ scribus foo.sla
2.) Use the menus: File -> Preferences -> User Interface -> Start Up tab -> Uncheck BOTH Show Splashscreen AND Show Startup Dialog

Doing that solves this problem for me. I hope it solves your problem, too. HTH :)

Clemmitt

Thank you cmsigler for your efforts. It works for me too (svn 1.5.8 version)
Simon

Would anybody that was having the issue with the splash screen in the first place be willing to try the current build again to see if this is still an issue? Having dealt with some other GTK issues that are cropping up with LTO builds landing I'm wondering if disabling that might have "fixed" this? Alternatively the version in [community-testing] with GraphicsMagic enabled (see  FS#59800 ) could also be tested, it also has LTO disabled at build time.

Sadly, with both the current build (1.5.7-11) and the testing build (1.5.7-12), I’m still having the signal #11 issue with this return of gdb :
Thread 1 "scribus" received signal SIGSEGV, Segmentation fault.
0x00007ffff54dea0e in __strcmp_avx2 () from /usr/lib/libc.so.6
Both version are still working with the no-splash "trick".

Wow. I don't really know what to say except this is almost certainly an upstream bug, apparently this one: https://bugs.scribus.net/view.php?id=16684

starting "scribus --no-splash" working for me with 1.5.7-12. With splash it still segfault 11.

It would be interesting to confirm if this is still an issue in 1.5.8. The related upstream bug report is still marked as open, but I've noticed before their tracking is less than perfect (whose is?). A comment here and on the upstream tracking issue confirming if it is still crashing in the latest release would probably be useful.

1.5.8-1 still segfaulting

Thread 1 "scribus" received signal SIGSEGV, Segmentation fault.
0x00007ffff54d0a0e in __strcmp_avx2 () from /usr/lib/libc.so.6

I had Signal #11 crash too with Scribus 1.5.8 on a fully updated arch, i did:

sudo pacman -S gdal

after installation finished, I didn't have this package, I was able to run Scribus normally

previous behavior:
$ scribus
ReaderWriterTF::writeObject
sizeof(TrkHeader)=1000
Warning: dynamic library '/usr/lib/osgPlugins-3.6.5/osgdb_ogr.so' exists, but an error occurred while trying to open it:
libgdal.so.30: cannot open shared object file: No such file or directory
Warning: dynamic library '/usr/lib/osgPlugins-3.6.5/osgdb_gdal.so' exists, but an error occurred while trying to open it:
libgdal.so.30: cannot open shared object file: No such file or directory
pathForIcon: Unable to load icon /usr/share/scribus/icons/1_5_1/lab.png: File not found
pathForIcon: Unable to load icon /usr/share/scribus/icons/1_5_1/spot.png: File not found
pathForIcon: Unable to load icon /usr/share/scribus/icons/1_5_1/register.png: File not found
qt.gui.icc: Unsupported ICC profile class 70727472
QPngHandler: Failed to parse ICC profile
Scribus Crash
-------------
Scribus crashes due to Signal #11

1.5.8- 3
Still happening. The comment above by cmsigler on 2021/12/13 is a viable
workaround for me.

This appears to be an issue related to displaying the startup dialog. The
dialog is bypassed when Scribus opens an existing file at startup. That file
can be a Scribus Document [*.sla], PDF Document [*.pdf], or any other format
supported by Scribus.

From a terminal, you can simply type:
$ scribus [foo.pdf]

After Scribus has started, then proceed to preferences and disable the startup
dialog. Disabling the splash screen is unnecessary in my case. Once the
startup dialog is disabled, you can start Scribus however you normally would.

yes, can also confirm the problem persists with 1.5.8-10 here,
Can also confirm that that quirky fix by cmsigler on 2021/12/13 works (so far).

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.