We need a debug log.
I will try to generate and provide that. I spent more than three hours with this issue on friday, so I have to do some other task currently, but I will try to managed to do it this evening, or at least tomorrow.
Note that there is also an issue with parsing dates, fixed in Date header parsing fails persistently due to aliasing issue in datetok() (#484) · Issues · GNOME / evolution-data-server · GitLab
1 Like
Note that there is also an issue with parsing dates,
That is interesting, and may explain why all the old posts in the Inbox suddenly get the current date instead of the right old one. I will read the details of that issue soon, and than investigate why SMTP sending fails for me. Thanks.
rm -rf .cache/evolution/
rm -rf .config/evolution/
CAMEL_DEBUG=smtp evolution >& logfile
$ cat logfile
(evolution:29457): GLib-GIO-WARNING **: 12:30:39.005: Your application did not unregister from D-Bus before destruction. Consider using g_application_run().
I saw that message already a few times when launching evolution from the shell. I assume it is not really related to my SMTP sending issue, the evolution app just thinks that I have not entered a recipient. I will try the other debug options later. Maybe I have to compile evolution, or whole GTK without -O3 and without LTO. Or with an older compiler, current compiler is gcc version 13.2.0.
I have just disabled all the optimizations provided by Gentoo-LTO, which includes option -O3 and LTO. After rebuilding evolution-data-server and evolution, I can send mails over SMTP again! As I disabled LTO again on friday, I assume it is am -O3 issue with gcc 13.2.0. The content of the evolution “TO” recipient text widget seems to be not passed to the app, so evolution can not see a recipient and refuses to operate.
The issue with the date still persists, so it seems to be not -O3 and LTO related. But when the next evolution update for Gentoo will become available, that should be fixed.
Actually there is one more minor issue, which occurs for several years already, it may be related to my 90000 mails in inbox. When I execute rm -rf .cache/evolution/ and rm -rf .config/evolution/ and then launch evolution, it fetches inbox summary from server successfully, but then displays “Processing folder changes in Inbox” for hours with high CPU activity. But I can terminate the app, and after relaunching it is OK.
Hi,
when you say “inbox”, which one do you mean precisely, please? Is it On
This Computer/Inbox or the IMAP Inbox?
Also, when you play with the internal files of the application, you
should also run from a terminal:
evolution --force-shutdown
because there are processes, which have those files and directories
opened, which can cause weird problems. Some desktop environments, like
GNOME Shell, can restart those processes right after you stop them,
thus be careful. Or run the --force-shutdown also after finished with
the cleanup of the internal files.
Bye,
Milan
Hi,
it would be good to report it, possibly to the gcc folks, though it
might be useful to also point to a place in the code where the problem
occurs, which I do not know how to find, I’m sorry.
By the way, Evolution is a gtk3 application, not gtk4.
Bye,
Milan
I was referring to the IMAP Inbox. The directories listed under “On this Computer” are always empty for me, I have no real idea for what they may be good. Yes, maybe I should report the issues. The problem with the dates seems to be reported already, and will hopefully be fixed soon. The issue with the “To:” recipients field seems to be only an issue when compiled with option -O3. And the high CPU load for hours when processing the Inbox after first install may be hard to debug. Maybe 90000 mails in Inbox is just too much, I should clean it up. It is mostly a result from being subscribed to mailing lists, which was popular some decades ago.
IMAP is a remote protocol. So “On this computer” is empty if you don’t use any local protocol (e.g. POP).
1 Like
The problem with the dates seems to be reported already, and will
hopefully be fixed soon.
Hi,
it is fixed in the sources for 3.49.2 and later versions for roughly
a month now.
The issue with the “To:” recipients field seems to be only an issue
when compiled with option -O3.
Right, that’s something to be investigated and should be reported.
Ideally with the above mentioned fix applied, in case it’s just a
fallout of it.
And the high CPU load for hours when processing the Inbox after first
install may be hard to debug.
Not that much, once can build with debug symbols (for the evolution-
data-server, evolution and glib2 at least) and then grab a backtrace of
the running process to see what it is trying to do. You can get the
backtrace with a command like this:
$ gdb --batch --ex “t a a bt” --pid=pidof evolution &>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.
Maybe 90000 mails in Inbox is just too much
Nope, 90k mails is nothing. I’ve an IMAP folder with 238K messages and
the most time it takes to load is when downloading summary information
from the server after entering the account for the first time. I
believe there are users with many more messages in a single folder.
I think this failed due to those optimizations, which trigger some
problem. Whether related to the Date header or not I do not know, but
it might be a good bet, I guess.
Bye,
Milan
1 Like
You should keep a log of the build that exhibits the bug and the one that does not (eventually setting the build system to a verbose build).
That is for the GCC issue.
1 Like
Short status update:
The issue with date parsing was fixed upstream and provided by Gentoo Linux.
For the not working TO: field, the solution seems to be to compile for GentooLTO with
gnome-extra/evolution-data-server *FLAGS-=“-fno-semantic-interposition”
Before, a reply showed also an empty TO: field, but after recompiling evolution-data-server with removed no-semantic-interposition it works.
I was not able to fix the permanently high CPU load after first use of evolution after a new install, but terminating evolution and restarting fixes it.
This is for AMD64,
mail-client/evolution-3.48.4:2.0::gentoo USE=“bogofilter spell ssl weather -archive -geolocation -gtk-doc -highlight -ldap (-selinux) -spamassassin -ytnef”
gcc version 13.2.1 20230826 (Gentoo 13.2.1_p20230826 p7)
For the high CPU load, there still applies what was written above: Evolution mail client issues - #17 by mcrha
1 Like
in version 3.50.0 (installed both from the fedora 39 repository and from flathub), the text input field of the letter does not display the printed characters
Hi,
that’s drawn by WebKitGTK. Does it hide every letter or only some? I do
not know what version of the WebKitGTK the Flathub uses, but I have a
Fedora 39 machine and when it had webkit2gtk4.1-2.42.0-1.fc39.x86_64,
then writing “abc” (quotes for clarity only) into the field for a
response to the organizer in the meeting invitation showed all the
letters. After that I updated WebKitGTK into 2.42.1-1 version and wrote
the same letters - they are shown properly.
What is your locale, please? It can be seen with the following command:
locale | grep LANG
Will anything change if you run Evolution in an English locale, like:
LANG=en_US.utf8 evolution
please?
Bye,
Milan
the webkit2gtk4.1-2.42.0-1.fc39.x86_64 package is installed
$ locale | grep LANG
LANG=ru_RU.UTF-8
LANG=en_US.utf8 evolution - it doesn’t help
I just installed fedora 39 and Evolution on an empty computer and I understood why this error occurs, it does not repeat if I use wayland. Due to several reasons, I usually use X11 and this error is repeated there
Hi,
would you mind to file a bug report against WebKitGTK in:
https://bugs.webkit.org/enter_bug.cgi?product=WebKit
please? Or if you do not have an account there I can do it for you, I
only think it’ll make more sense to have you on the bug, in case the
developers would have any question.
Also, the Fedora 39 has updated the WebKitGTK to
webkit2gtk4.1-2.42.1-1.fc39.x86_64 and I cannot reproduce the problem
with it under X11 GNOME Shell, thus before filling a bug do update the
machine first and retest it, please.
Bye,
Milan
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.