Bug 1394182

Thanks for a bug report. You are right that without a backtrace it's pretty hard to fix the problem, because it's basically unknown. I didn't see crash evolution myself recently, but I also do not keep it running for too long. Anyway, could you install debuginfo packages for the evolution-data-server and evolution [1], then run evolution under gdb [2] and let it try to catch the backtrace, please?

[1] A command to install only those two is below. Make sure the installed binary package versions exactly match those for the debuginfo, otherwise it'll not work. Run this as a root:
   # dnf install evolution-data-server-debuginfo evolution-debuginfo \
      --enablerepo=updates-debuginfo

[2] Run evolution from a command line as a regular user like this:

  $ gdb evolution --ex r --ex bt

Once the UI freezes check the terminal with gdb, maybe it'll show a prompt there. The command as such just runs the evolution and once it'll stop it prints the backtrace, then waits for further commands. One such command can be "t a a bt", which prints a backtrace for all running threads. Another is "continue" to continue the run. Finally the "quit" quits gdb and closes the evolution.

Please make sure you'll not expose any private data in the backtrace, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only).

It would be also good to know the circumstances under which the crash happened. Could you also paste a result of the below command here, please?

   $ rpm -q evolution-data-server evolution webkitgtk3

Created attachment 1227350 [details]
evolution backtrace of freeze

Attaching backtrace. Assuming "crash" is the same issue I'm seeing: evolution freezes and is not responsive. You can recover by killing it and restarting, which sometimes loses what you were working on. It seems like the pop-up for "not responding" doesn't always appear but that could be my impatience.

$ rpm -q evolution-data-server evolution webkitgtk3
evolution-data-server-3.22.2-1.fc25.x86_64
evolution-3.22.2-1.fc25.x86_64
webkitgtk3-2.4.11-3.fc25.x86_64

Thanks for the update. The bakctrace shows a gdb prompt stopping on a SIGPIPE, which not always result in a crash. Could you re-try and simply repeat these gdb command until the gdb tells you that the process does not run any more, please?

   (gdb) bt
   (gdb) c

The commands print a backtrace and then let the execution continue. Thanks in advance.

Could you also try whether anything changes when you'll run evolution as:

   $ export WEBKIT_DISABLE_COMPOSITING_MODE=1
   $ evolution

to test whether it'll have any influence on the run as such, please?

Hi Milan,

While With the default compositing mode you cannot browse more than a few messages without getting a freeze of the preview window, with WEBKIT_DISABLE_COMPOSITING_MODE=1 the freeze goes away entirely.

Though while testing "heavily" I still experienced a couple of occasional lockups-without-crash during shutdown that I will try to reproduce.

BTW, I am experiencing the same freeze with a few other programs; namely Opera, VLC and MPV.

In Opera the "freeze" goes away if Graphic acceleration is disabled and in VLC it goes away by setting the video output mode to OpenGL in the preferences.

It might be worth mentioning that my computer has an "r600" AMD video card (RS780L [Radeon 3000]) whit mesa drivers.

(In reply to Davide Repetto from comment #4)
> Though while testing "heavily" I still experienced a couple of occasional
> lockups-without-crash during shutdown that I will try to reproduce.

That would need a backtrace, as mentioned above, to see what the evolution, eventually WebKitWebProcess-es do.

> BTW, I am experiencing the same freeze with a few other programs; namely
> Opera, VLC and MPV.

Right, it looks like something related to video drivers (I'm not the expert here, though). The upstream WebKit developers [1] sometimes look for the output of:

   $ glxinfo

to see what the drivers advertise and so on. If you could provide it, then it may help them.

[1] https://bugs.webkit.org/show_bug.cgi?id=165246#c4

Created attachment 1229092 [details]
evolution backtrace of freeze continued

(In reply to Milan Crha from comment #3)
> Thanks for the update. The bakctrace shows a gdb prompt stopping on a
> SIGPIPE, which not always result in a crash. Could you re-try and simply
> repeat these gdb command until the gdb tells you that the process does not
> run any more, please?
> 
>    (gdb) bt
>    (gdb) c
> 
> The commands print a backtrace and then let the execution continue. Thanks
> in advance.
> 
> Could you also try whether anything changes when you'll run evolution as:
> 
>    $ export WEBKIT_DISABLE_COMPOSITING_MODE=1
>    $ evolution
> 
> to test whether it'll have any influence on the run as such, please?

I have attached a backtrace where I continued and kept running. Consequently, evolution does reach an end; the process keeps going and going until you receive the "... Stopped Responding pop-up". However, evolution is completely useless in this loop. Therefore, the only option is to kill evolution and restart.

Thanks for the update. I cannot tell whether Jonas' issue is the same or different, I need a backtrace from his crashes to know it, but that yours reads as:

> Gdk-WARNING **: Error writing selection data: Error writing to file descriptor: Broken pipe"

and that SIGPIPE I thought is not related is just for this issue. The Wayland in gtk+ (and its gdk subpart) failed badly for some reason. A similar issue is already filled as bug #1339331. It's not exactly the same, though I think it's close enough.

Due to that I think we can continue with this SIGPIPE error there and keep this bug report for the original issue, for which I'd need information from Jonas.

Because evolution has been a quite buggy experience for me (not just crashes but even mails not showing up when I really needed them) I was forced to switch the client for now because it started to impact my work, so I didn't have a good chance to look at this bug further.

However, it's definitely crashes and not freezes - and because I wasn't sure whether evolution has updated from the outdated insecure webkit1 I have HTML mails disabled unless I explicitly view them, so a webkit crash seems a bit unlikely.

If I recall correctly, one time it happened when interacting with the search/filter box at one point, and another crash was me clicking something in the UI I can't remember which I think was in the composer window. (I was about to send an email, I forgot whether it was the actual send button or something else)

ABRT has a fix in the pipeline that allows reporting crashes even with locked memory if you override the warning - so I hope in the future it will be easier for users to report this. I can only add that I know others who tried evolution around the same time who also told me about common crashes, so I don't think I'm the only one.

Evolution 3.22.0+ does use WebKit2 (through webkitgtk4 package). It doesn't matter whether you've HTML messages or plain text messages, they are always rendered by the WebKitGTK+.

Many users experience issues with the webkit's compositor mode, I wouldn't be surprised if you (and the others you mentioned) are also affected by it. There's a workaround in the evolution for 3.22.3+, which will be released the next Monday and shortly after will reach updates-testing for Fedora 25.

I'm closing this bug report in the favour of 3.22.3. As you are going to eventually file new bugs through ABRT, then it'll be easier to track it separately, also because ABRT cannot pair them with this bug report.