|
|
could you add the debug symbols and run it with gdb? ... it looks like a library issue... |
|
|
I managed to reproduced the crash in my Ubuntu 20.10 VM. It does not happen systematically tho. Looks like a crash in a GTK event loop or something like that. |
|
|
It seems I cannot reproduce the crash anymore with latest Ubuntu updates. |
|
|
OK, I'm trying to help, but I'm really not a C++ developer, so I'm a noob for debugging Scribus. I found only very outdated wiki pages how to build Scribus on Ubuntu 20.10 with debug symbols and I do not fully understand what gdb is... I build Scribus cmake -DWANT_DEBUG=1 -DCMAKE_INSTALL_PREFIX:PATH=/usr/local/scribus_svn .. When I start it I get this output: /usr/local/scribus_svn/bin$ gdb ./scribus GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./scribus... (gdb) run Starting program: /usr/local/scribus_svn/bin/scribus [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff1880640 (LWP 42463)] [New Thread 0x7fffebe94640 (LWP 42464)] [New Thread 0x7fffeb693640 (LWP 42465)] [New Thread 0x7fffeac4e640 (LWP 42466)] [New Thread 0x7fffea1cc640 (LWP 42468)] [Detaching after fork from child process 42469] [Detaching after fork from child process 42470] [Detaching after fork from child process 42471] [Detaching after fork from child process 42472] [Detaching after fork from child process 42473] pathForIcon: Unable to load icon /usr/local/scribus_svn/share/scribus/icons/1_5_1/lab.png: File not found pathForIcon: Unable to load icon /usr/local/scribus_svn/share/scribus/icons/1_5_1/spot.png: File not found pathForIcon: Unable to load icon /usr/local/scribus_svn/share/scribus/icons/1_5_1/register.png: File not found Unsupported ICC profile class 70727472 fromIccProfile: failed general sanity check QPngHandler: Failed to parse ICC profile [New Thread 0x7fffd8e06640 (LWP 42476)] [New Thread 0x7fffcffff640 (LWP 42477)] [New Thread 0x7fffcf7fe640 (LWP 42478)] [New Thread 0x7fffceffd640 (LWP 42479)] [New Thread 0x7fffce7fc640 (LWP 42480)] [New Thread 0x7fffcdffb640 (LWP 42481)] [New Thread 0x7fffcce51640 (LWP 42482)] [New Thread 0x7fffb7fff640 (LWP 42483)] [Thread 0x7fffcdffb640 (LWP 42481) exited] [Thread 0x7fffcf7fe640 (LWP 42478) exited] [Thread 0x7fffceffd640 (LWP 42479) exited] [Thread 0x7fffd8e06640 (LWP 42476) exited] [Thread 0x7fffcffff640 (LWP 42477) exited] [Thread 0x7fffce7fc640 (LWP 42480) exited] @ale, if you give me a wiki description I will do more. @jhali, I updated my Ubuntu (including Scribus), but it continues to crash. |
|
|
with ubuntu, you don't need to compile scribus yourself to start scribus with the debugger. i can see if i can put together a short tutorial. anyway, i think that jean got the information he needed to reproduce and ubuntu seems to have fixed the bug... |
|
|
After upgrading to scribus-trunk amd64 1.5.6svn~r24132~20201031~ppa78~ubuntu20.10.1 I got this warning: There is a problem loading 1 of 55 plugins. libhunspellplugin.cpython-38-x86_64-linux-gnu.so This is probably caused by some kind of dependency issue or old plugins existing in your install directory. If you clean out your install directory and reinstall and this still occurs, please report it on bugs.scribus.net. And yes, there is a /usr/lib/scribus-trunk/plugins/libhunspellplugin.cpython-38-x86_64-linux-gnu.so file. If I remove it the crash persists. Képernyőkép erről: 2020-10-31 16-17-12.png (40,120 bytes) |
|
|
>> anyway, i think that jean got the information he needed to reproduce and ubuntu seems to have fixed the bug... Arghhh!! After restarting my VM this morning, the crash is unfortunately back. Here is the backtrace I'm getting: #0 0x00007fb6b221766f in __GI___poll (fds=0x562a6e01a7d0, nfds=4, timeout=2992) at ../sysdeps/unix/sysv/linux/poll.c:29 0000001 0x00007fb6b197e71e in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 0000002 0x00007fb6b197e853 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 0000003 0x00007fb6b2941843 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 0000004 0x00007fb6b28e8a4b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 0000005 0x00007fb6b35a001f in QDialog::exec() () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 0000006 0x0000562a69c7e8cf in ScribusMainWindow::startUpDialog (this= 0x562a6c5327c0) at /home/developer/Documents/scribus-trunk/Scribus/scribus/scribus.cpp:1970 0000007 0x0000562a69cd916f in ScribusCore::startGUI (this=0x562a6c45cda0, showSplash=true, showFontInfo=false, showProfileInfo=false, newGuiLanguage=...) at /home/developer/Documents/scribus-trunk/Scribus/scribus/scribuscore.cpp:132 0000008 0x0000562a69cd519e in ScribusQApp::init (this=0x7fff7beb3290) at /home/developer/Documents/scribus-trunk/Scribus/scribus/scribusapp.cpp:364 0000009 0x0000562a6a342643 in mainApp (argc=1, argv=0x7fff7beb3438) at /home/developer/Documents/scribus-trunk/Scribus/scribus/main_nix.cpp:72 0000010 0x0000562a6a3425b8 in main (argc=1, argv=0x7fff7beb3438) at /home/developer/Documents/scribus-trunk/Scribus/scribus/main_nix.cpp:51 Unfortunately it seems something bad happens deep inside Qt and glib. So the fix will likely have to happen on Ubuntu side. |
|
|
Tested here .. no crash on 20.10 |
|
|
I tested it on a fresh Ubuntu 20.10 (VM) and get this result. I installed only the scribus package: - 1st start Scribus works well - Close Scribus and restart it: crashed :-(. |
|
|
New test here... If I remove that 2 files before running Scribus every time: ~/.config/scribus/checkfonts150.xml ~/.config/scribus/scribus150.rc there is no crash on startup anymore, Scribus is usable. I tested this on fresh Ubuntu 20.10 and on my real desktop. I hope this helps. |
|
|
Try editing the theme="" in scribus150.rc to be "Fusion" or "Windows" and see if it starts up. I have zero issue here with all 3 themes on 20.10 though. Again, likely a Qt or GTK issue. Not a Scribus issue. |
|
|
@cbradney, thanks for you help. Unfortunately this fix (theme="Fusion") does not solve the crash problem completely: - If Scribus crashes and there is an empty theme attribute, when I fill it with theme="Fusion", it solves the problem. - But after that if I edit the Scribus preferences on GUI, after exit and restart Scribus crashes again although this theme attribute is not empty in this case. - And on some cases Scribus starts without any problem with empty theme attribute. :-( |
|
|
The crash can be avoided by setting in scribus150.rc the Maximized attribute of MainWindow element to "0". For those compiling scribus themselves on Ubuntu 20.10, a temporary workaround can be to comment out following lines in scribus.cpp: if (mainWinSettings.maximized) this->setWindowState((this->windowState() & ~(Qt::WindowMinimized | Qt::WindowFullScreen)) | Qt::WindowMaximized); Of course, when starting up scribus, the maximization state of scribus main window will not be restored anymore. I tried several workarounds in order the allow the maximization state of scribus main window to be restored while preventing the crash on Ubuntu 20.10, unfortunately without success as none of the workarounds I tried worked reliably. So at this point, I strongly think that the fix will have to come from Ubuntu guys or GTK guys. I doubt the issue is in Qt as the same Qt 5.14.x works correctly in other distros. |
|
|
@jghali, you are right, I can confirm that <MainWindow Maximized="0" /> solves the crash. Thank you for investigation. |
|
|
It seems also that the 1.5.6 AppImage does not trigger the crash in 20.10. But that's probably because it embeds Ubuntu 18.04 components. |
|
|
Actually, nope, 1.5.6 fails to respond after loading here with both AppImage and my own build from source code. Not running it with maximized window mode does solve the issue. |
|
|
This is the output in the Terminal when I launch Scribus in Ubuntu 20.10. As I mentioned on other forums, GNOME Shell crashes, and Scribus doesn't respond. I have to kill the process to close Scribus. Schermafdruk van 2020-11-16 17-42-14.png (33,320 bytes) |
|
|
Those few missing files isn't a problem, Scribus falls back to previous versions of the icons |
|
|
@bubu, removing the two files did solve the issue for me; thanks! I still find it rather odd that stable branch is supposed to be 1.5.5 (right?), that is what the package is called, but when it runs, it appears to be 1.5.6 unstable? Anyway, Scribus no longer crashes with the two files removed. |
|
|
stable is 1.4.x |
|
|
@antoonstessels, it is enough to modify Maximized="1" to Maximized="0" in scribus150.rc file as jghali mentioned above. |
|
|
Thanks @bubu and @jghali, changing the line in the scribus150.rc file fixes the problem. |
|
|
I find this problem gone (Ubuntu 20.10). |
|
|
Nope, I can still reproduce it in my VM. I'm going to install latest updates and test again. |
|
|
I can still reproduce the issue with latest updates. |
|
|
Interesting, I can't reproduce anymore the issue: - I'm running Scribus 1.5.6, scribus-trunk, my development build, appImage - all they work without any problem. - Maximized="1" is enabled. - Ubuntu 20.10: Linux lazar 5.8.0-41-generic 0000046-Ubuntu SMP Mon Jan 18 16:48:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux - Gnome 3.38.3 - Wayland /X11 does not matter. @antoonstessels, @alexandre? |
|
|
I have the same problem here the output of gdb: I tried some of the workarounds but they don't seem to work. (gdb) run Starting program: /usr/bin/scribus [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffefee4640 (LWP 55401)] [New Thread 0x7fffee63c640 (LWP 55402)] [New Thread 0x7fffede3b640 (LWP 55403)] [New Thread 0x7fffed63a640 (LWP 55404)] [New Thread 0x7fffecaf4640 (LWP 55405)] [New Thread 0x7fffd7fff640 (LWP 55406)] [New Thread 0x7fffd77fe640 (LWP 55407)] [New Thread 0x7fffd4dc7640 (LWP 55409)] [New Thread 0x7fffcffff640 (LWP 55410)] [New Thread 0x7fffcf7fe640 (LWP 55411)] [New Thread 0x7fffceffd640 (LWP 55412)] [Detaching after fork from child process 55413] [Detaching after fork from child process 55414] [Detaching after fork from child process 55415] [Detaching after fork from child process 55416] [Detaching after fork from child process 55417] 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 Thread 1 "scribus" received signal SIGSEGV, Segmentation fault. 0x00007ffff587eb84 in QObject::objectName() const () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 |
|
|
I never had such issue running scribus 1.5.6 or 1.5.7 appimage on ubuntu 20.10 |
|
|
I can't reproduce: - Ubuntu 21.04 - Qt 5.15.2 - X or Wayland - Scribus 1.5.6.1 (deb), 1.5.7 (appImage) |
|
|
The crash is fixed in Ubuntu 21.04 and Ubuntu 20.10 is going out of support this month, so I'm closing this issue. Given the location of the crash, it was out of scope for us anyway. |
- Anonymous
