Evolution 3.50.3 [Flathub] hangs indefinitely when replying

Applications
1

I am having problems with Evolution 3.50.3 [Flathub version] on Fedora Silverblue. Fetching and reading email works fine but when I try to reply (clicking in GUI or using shortcuts) the programme hangs.

The reply window never opens and no matter how many times I click “wait” on the “Evolution is not responding” pop-up the programme never recovers.

I would like to share debug information as per this post.
However, having installed gdb, I am unsure how to launch Evolution from the terminal in a way that this information is created.

When launching Evolution from the terminal (flatpak run org.gnome.Evolution) the following messages are displayed:

flatpak run org.gnome.Evolution

(evolution.bin:28): libnotify-WARNING **: 16:31:34.611: Running in confined mode, using Portal notifications. Some features and hints won't be supported

(evolution.bin:28): GLib-GIO-CRITICAL **: 16:31:35.365: GFileInfo created without standard::display-name

(evolution.bin:28): GLib-GIO-CRITICAL **: 16:31:35.365: file ../gio/gfileinfo.c: line 1721 (g_file_info_get_display_name): should not be reached

(evolution.bin:28): GLib-GIO-CRITICAL **: 16:31:35.365: GFileInfo created without standard::display-name

(evolution.bin:28): GLib-GIO-CRITICAL **: 16:31:35.365: file ../gio/gfileinfo.c: line 1721 (g_file_info_get_display_name): should not be reached

(evolution.bin:28): GLib-GIO-CRITICAL **: 16:31:35.366: GFileInfo created without standard::display-name

(evolution.bin:28): GLib-GIO-CRITICAL **: 16:31:35.366: file ../gio/gfileinfo.c: line 1721 (g_file_info_get_display_name): should not be reached
2

Update:
I have installed Evolution in a toolbox and it is also crashing when attempting to reply to an email.
This is the output of gdb:

Sorry, I keep getting Error 422 when pasting in terminal output!

3

There is no line of an Evolution code call in that excerpt. It is not complete.

4

You quit too soon :smiley:

It’s generally sufficient to get a backtrace for just the crashing thread unless requested otherwise.

5

Sorry…did I mention I am a novice?

I have updated the above post with what is hopefully the relevant info.

If not, please let me know - I am learning as I go along.

6

The above has no stacktrace at all, just some single-line output. We need a stacktrace

7

He edited it into his post above. It’s good now. Thanks!

That said, it doesn’t show a crash, but a SIGINT. Guess: Evolution hung, but did not crash, then you pressed Ctrl+C, causing it to crash? That’s actually fine, because the backtrace shows exactly where it was hanging (gpg_ctx_op_step). Normally this is where I’d ask you to report a bug, but since Milan watches the evolution tag here and is likely to notice this thread soon, let’s wait for his opinion first.

8

Hi,
debugging under Flatpak is a very different story than debugging on the
host machine/system.

Before we dive into that, did this work before with no problem and
started suddenly, maybe after recent update either of the Evolution
itself or the org.gnome.Platform (a flatpak runtime)?

I would try to run Evolution from a terminal, maybe it prints something
related there. You can do it with:

flatpak kill org.gnome.Evolution
flatpak run org.gnome.Evolution

The “kill” is needed to ensure the process will print on this terminal,
not into any previous.

I tried to reproduce this here, but no luck, unfortunately. It does not
mean much, because your setup might influence this differently than
mine. I mean your setup might contain something what helps to trigger
the conditions to reproduce the problem.

Bye,
Milan
1 Like
9

The updated backtrace shows evolution waiting for a response from gpg. That should be fast, it’s only asking for your public key, to be included in the message in an Autocrypt header. As you do not run Flatpak version of Evolution any more, you can run it from a terminal with gpg-related debugging on with:

   CAMEL_DEBUG=gpg evolution

and it’ll print what command it tried to execute. It would be interesting to know whether a similar command causes the same hang on the gpg side, or what happened to gpg as such. Maybe check whether gpg is running (maybe it crashed?) while evolution is waiting for it, an grab a bactrace of the gpg process while in this waiting state, ideally with installed debuginfo package for the gnupg package. To check whether gpg is running:

   ps ax | grep gpg

and to get the backtrace of that process:

   gdb --batch --ex "t a a bt" --pid=`pidof gpg` &>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.

As a workaround, you can disable autocrypt in the Edit->Preferences->Mail Accounts->select the account->Edit->Security tab->then expand the Advances Options part and uncheck “Send own public key in outgoing mails” option. This option is for each configured account. Again, this is only a workaround, until we figure out what problem gpg has.

Do you have installed a key card or any such thing, which requires special processing (like password) to access the public key on it, or any special setting for the gpg-agent? The gpg backtrace should provide some information what it is waiting for, I hope, this is only a starting point, to check the gpg configuration (usually stored in ~/.gnupg/ , which can contain various .conf files, apart of the stored keys and other gpg-private data).

The command the libcamel calls is close to:

   gpg --list-keys --with-colons --with-fingerprint user@email.org

you can try to run it with your email address. The email address can be enclosed into brackets too, like this:

   gpg --list-keys --with-colons --with-fingerprint "<user@email.org>"

Do both commands behave the same when run from a terminal, please?

1 Like
10

First of all many thanks for your detailed instructions, @mcrha - I really appreciate the time you are taking to walk me through this.

I should add a couple of things which may determine the best course of action.

That is precicely what happened. I will boot into the previous system image to check.

Secondly, I do not use GPG encryption with the emails accounts set up in Evolution. Presumably, the GPG call still applies here and is related to the keychain? I just wanted to double check before diving into the troubleshooting steps you are suggesting.

11

That is precicely what happened. I will boot into the previous system image to check.

If you know the versions, or the commits the app or runtime changed from and into, then it’ll help. When you run:

flatpak list --columns ref,runtime,active

You can see what runtime org.gnome.Evolution uses, while you can search that runtime’s commit in the listing. Maybe I’d skip the flatpak version for now, as you can reproduce it also in the toolbox, thus I’d focus on it, which is easier to debug. It can also be the gpg version changed with the update (of the runtime, most likely). Do you know what version of gpg (if I’m not mistaken, it’s gnupg package) you’ve installed, please? That can help too, together with the backtrace of that (possibly) stuck process.

Presumably, the GPG call still applies here and is related to the keychain?

Yes, the gpg call is still done, because when you do not have filled exact key ID, the public key is search by the email address of the account. That’s for convenience.

12 
[GPG] going to execute: gpg2 --verbose --no-secmem-warning --no-greeting --no-tty --batch --yes --status-fd=80 --export --export-options export-minimal,no-export-attributes <myemail@provider.org>
< 0x56206b8e9160 >```

[quote="mcrha, post:9, topic:18996"]
`ps ax | grep gpg`
[/quote]
```Thread 0x56206b8e9160 >
[GPG] going to execute: gpg2 --verbose --no-secmem-warning --no-greeting --no-tty --batch --yes --status-fd=80 --export --export-options export-minimal,no-export-attributes <myemail@provider.org>
< 0x56206b8e9160 >```

bt.txt:
```This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007fac207c1f8e in select () from /lib64/libc.so.6

Thread 1 (Thread 0x7fac20594740 (LWP 7487) "gpg2"):
#0  0x00007fac207c1f8e in select () from /lib64/libc.so.6
#1  0x000055e2bbe7970c in dotlock_take_unix.lto_priv ()
#2  0x000055e2bbe97a17 in start_new_service.constprop ()
#3  0x000055e2bbdf930c in keydb_new ()
#4  0x000055e2bbe46f05 in do_export_stream.lto_priv ()
#5  0x000055e2bbe483e8 in do_export.lto_priv ()
#6  0x000055e2bbde3a69 in main ()
[Inferior 1 (process 7487) detached]

I tried to find out how to set debuginfod enabled on but failed.

There is no key card reader, etc. and

hangs:

gpg: waiting for lock (held by 608) ...

That line repeats when executing the libcamel calls.

I can confirm this is working. As a side effect Evolution is now much quicker in opening message (reply) windows. Previously I have experienced a delay which often caused me to inadvertently open several windows because it took so long for the window to appear.

13

Seeing this, you renamed the machine (its hostname), right? This error reminded me of 2249218 – gpg waits indefinitely in start_new_service()/assuan_socket_connect() , see some more pointers in this comment there: 2249218 – gpg waits indefinitely in start_new_service()/assuan_socket_connect()

I think fixing the gpg is a good thing to do, regardless you plan to use it or not. You can try to move away the old gpg lock files too (such may contain the old machine name).

14

I did indeed. In fact I did so even on the old install (F38 SB, my first Fedora install) when I also had problems with laggy reply windows (may be unrelated).

Reading through the bug reports you have provided I am wondering if it is safe to delete the ~/.gnupg directory?

I do not have any private keys generated and am not using GPG encrypted mail.

15

I faced some glitches which I sometimes been able to reproduce and sometimes not. You can always move away/rename the directory, not delete it, thus you can return back to it. As you do not store anything there, removing it or its content (with hidden files, name starting with a dot), may not have any disastrous effect.

16

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.