Software : Linux 6.17.7-300.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Nov 2 15:30:09 UTC 2025 x86_64 GNU/Linux evolution-3.58.1-1.fc43.x86_64 Mon 17 Nov. 2025 15:33:21 Hardware : product: R530/R730/P590 vendor: SAMSUNG ELECTRONICS CO., LTD. model name : Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz Problem : Evolution does not start ; /var/log/messages produces this : Nov 17 16:34:23 kernel: traps: evolution[3465] trap int3 ip:7f1bbe452f43 sp:7ffd33d95bc0 error:0 in libglib-2.0.so.0.8600.1[4bf43,7f1bbe407000+a6000] Nov 17 16:34:23 systemd-coredump[3591]: Process 3465 (evolution) of user 1000 terminated abnormally with signal 5/TRAP, processing... Reproducible: Always Steps to Reproduce: 1. Just start Evolution, either from the GUI or from a terminal, then look in /var/log/messages. 2. 3.
Thanks for a bug report. It looks like it's crashing somewhere in glib2 code, which does not necessarily mean it's a problem in the glib2 itself. Could you install debuginfo packages for the glib2, evolution-data-server and evolution, like: sudo dnf install glib2-debuginfo evolution-data-server-debuginfo evolution-debuginfo --enable-repo=updates-debuginfo only make sure the versions of the debuginfo packages exactly match those installed, aka: rpm -q glib2 evolution-data-server evolution and then run evolution from a terminal under gdb to get the backtrace of the crash, please? You can get the backtrace with a command like this: DEBUGINFOD_URLS="" gdb --batch evolution --ex r --ex "t a a bt" &>bt.txt Please check the bt.txt for any private information, like passwords, email addresses, server addresses,... I usually search for "pass" at least (quotes for clarity only), before sharing it anywhere.
Created attachment 2114909 [details] gdb backtrace, as requested.
Thanks for a quick update. I see it's crashing in the WebKitGTK code, due to at-spi D-Bus problem. That had been reported in bug #2162351 some time ago, which references an upstream bug and also a link to a workaround: https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/180#note_2440753 It's untested by me, I do not face this. As the path references `lxdm`, it might be a leftover from the enabled accessibility in the login manager (or how it's called) of the LXDE desktop environment, because LXDE is mentioned in the upstream bug as well. *** This bug has been marked as a duplicate of bug 2162351 ***
Followed your links. $ NO_AT_BRIDGE=1 evolution : fails. $ WEBKIT_FORCE_SANDBOX=0 evolution : fails. In a message from Apr 2023, I found this : WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 evolution and this works. Michael Catanzaro commented on that post : "Uh, needless to say, I don’t recommend globally adding environment variables with DANGEROUS in the name." I am surprised this workaround is still necessary. I understand "evolution" is not involved. But you have more authority than I have in negotiating with the webkitgtk team.
I do not have any authority with the WebKitGTK folks, I'm sorry. :) The most I can ping some people, but that's all. They work on things they can. WebKit(GTK) has too many opened bugs, not talking they need to stay current with the technologies, which are constantly evolving and changing. Anyway, while it's the WebKitGTK code casing the application crash, the problem can be very well elsewhere, at least the root cause of the problem. I know some other distributions have this problem too, apart of those linked here. I do not recall many details, unfortunately, but from the error message you've got here, the problem is that the lxdm left an at-spi D-Bus service running, while the user was supposed to run its own after he/she logs in. That ensures the logged in user has his/her own at-spi D-Bus service, to which it has access and control of. If I recall correctly, it also happened to some users that the leftover at-spi D-Bus service was closed some time after they logged in, then the new could be started and every thing worked fine again. You can try to find out which process is serving the at-spi D-Bus service and kill it, to imitate the closure of it. Trying to run here `ps ax | grep at-spi` it shows multiple processes running here, but I'm sorry, I do not know which one is "the one", if any at all.