Thanks for a bug report. The backtrace is clean, doesn't show any sign of an ongoing message list generation. It can be that the operations left stuck in some thread pool, either related to GTask, or some internal for the evolution (-data-server).

Did you just move from offline to online or anything like that?

By the way, I'm not sure whether 3.18.5, but the 3.20.0 for sure allows to click the window's close (x) button multiple times, where the second+ click shows a dialog to force-quit the evolution. It was supposed to do in in 3.18.x too, but there was some bug...

(In reply to Milan Crha from comment #1)
> Did you just move from offline to online or anything like that?

Yes, that's very likely the case.

Of course I can force-quit Evolution, but this bug is about avoiding to get into that situation by having code that times out.

And stuck again. Grabbed a gdb trace before killing Evolution.
If there's anything else helpful I can provide, please tell me how.

evolution-3.18.5.2-1.fc23.x86_64
evolution-data-server-3.18.5-1.fc23.x86_64

$:andre\> gdb -p 2699
GNU gdb (GDB) Fedora 7.10.1-31.fc23
Attaching to process 2699
[...]
0x00007fafa82b6b1d in poll () at ../sysdeps/unix/syscall-template.S:84
84	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) thread apply all bt full

+ Trace 236296

rax            0xfffffffffffffdfc	-516
rbx            0x559ca01c2a70	94131189459568
rcx            0x7fafa82b6b1d	140392417422109
rdx            0x21	33
rsi            0x4	4
rdi            0x559ca349c170	94131242778992
rbp            0x4	0x4
rsp            0x7fff9ae1b2d0	0x7fff9ae1b2d0
r8             0x4	4
r9             0x1	1
r10            0x7faf161cdc40	140389966994496
r11            0x293	659
r12            0x559ca349c170	94131242778992
r13            0x21	33
r14            0x7fafa85da060	140392420712544
r15            0x4	4
rip            0x7fafa82b6b1d	0x7fafa82b6b1d <poll+45>
eflags         0x293	[ CF AF SF IF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0
(gdb) list
79	#else
80	
81	/* This is a "normal" system call stub: if there is an error,
82	   it returns -1 and sets errno.  */
83	
84	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
85		ret
86	T_PSEUDO_END (SYSCALL_SYMBOL)
87	
88	#endif
(gdb)

...and that stacktrace is identical (apart form more debug symbols for webkit stuff)

Hrm, it's identical backtrace, as you said, showing all threads polling/idle/relaxing. If I got it right, then:
- the Evolution is offline
- the message list shows "Generating message list..." text
- the status bar shows the same text as the message list, plus a "cancelling"
  note there, which is there to indicate that the cancel of it had been initiated

What is the folder's account type, where that happened?

What if you move to another folder, will it cure the issue (remove the operation from the status bar and fill the message list with the other folder content), or not?

What if you select the account name node at the left folder tree, like the "On This Computer" node? And eventually then the On This Computer/Sent folder?

Did you initiated the cancel of the activity, or it was the evolution itself requesting the cancel?

I'm currently unsure what could cause this, the reproducibility looks like a problem. Maybe if we'll try to find something related, together with the answers for the above questions, then maybe it'll lead us somewhere.

(In reply to Milan Crha from comment #5)
> Hrm, it's identical backtrace, as you said, showing all threads
> polling/idle/relaxing. If I got it right, then:
> - the Evolution is offline

It seems to happen when going offline and sync'ing for offline use. It remains when going online again.

> - the message list shows "Generating message list..." text

No, I can use Evolution 'correctly' and go to other folders and such, and the message list updates.

> - the status bar shows the same text as the message list, plus a "cancelling"
>   note there, which is there to indicate that the cancel of it had been
> initiated

Yes.

> What is the folder's account type, where that happened?

IMAP, GMail.

> What if you move to another folder, will it cure the issue (remove the
> operation from the status bar and fill the message list with the other
> folder content), or not?

If you mean going to a different folder, it does not solve the problem. If you mean "moving random messages from a folder to another", I have not tried that.

> What if you select the account name node at the left folder tree, like the
> "On This Computer" node? And eventually then the On This Computer/Sent
> folder?

The status pane message remains, but Evolution is functional so the view updates.

> Did you initiated the cancel of the activity, or it was the evolution itself
> requesting the cancel?

I initiated myself but it does not help.

(In reply to André Klapper from comment #6)
> If you mean going to a different folder, it does not solve the problem. If
> you mean "moving random messages from a folder to another", I have not tried
> that.

I meant "going to another folder".

It looks like the associated EActivity is leaking in this case, as you can use the evolution otherwise. I'll try to read the code and focus on the details you gave me. Maybe something will show up. Thanks.

Hrm, I tried to reproduce this here, even by cheating in the code, but no luck, the status bar is cleaned up either if I imitate a cancellation or a fake error. The code reading also didn't bring anything obvious. I can try to provide a test build with some debug prints, but the question is whether you can reproduce it at least partially. Otherwise it can be just a full log of some semi-random prints from various parts of the code, which will also slow down the processing, thus eventually will avoid the circumstances, if it is timing-related at all.

From the code reading, the EActivity which is responsible for the message shown in the status bar is probably leaking. It is associated with the message list regeneration and is unreffed when the regeneration is finished, successfully or not. The EActivity can be reffed, for one second, by an EActivityProxy or EActivityBar (these two I found). It's unreffed after that one second automatically. The message list regeneration data can be also reffed and unreffed (these data hold the EActivity instance), but I didn't notice a reference imbalance on this data structure during the code reading. The regeneration uses GSimpleAsyncResult, and that also looks like being unreffed and freed appropriately here.

Seeing this again with evolution-3.20.3-1.fc24.x86_64 and evolution-data-server-3.20.3-1.fc24.x86_64.

Created attachment 330812 [details]
Debug output (via: "/usr/bin/evolution $@ &>/var/tmp/evolution.$$")

After unhibernating on a hotel network where the wifi is up but the internet is not available ("limited connectivity" according to NetworkManager). 
I did change from threaded view to unthreaded via Ctrl+T; guess that is related.

evolution-3.20.3-1.1.fc24.x86_64 and evolution-data-server-3.20.3-1.fc24.x86_64 (custom build for more debugging output).

Attached file might include debug spew from other applications (Firefox or such).

Hmm, each created activity has its unref too, thus maybe the issue is somewhere else. I created a new build [1], which adds even more debugging to the log. Please install it and we'll see. Thanks in advance.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=14760985

Created attachment 330904 [details]
Debug output for stuck "Retrieving message 12345"

NOT necessarily the same issue, but same outcome:

After going into offline mode (and syncing for offline use), I got stuck with two messages in the status pane: "Retrieving message 25112 in wikitech-l" and "Retrieving message 25270 in wikitech-l". 
Evolution does not close / shutdown either because of these two messages. I don't open a new task for this as this might be a very similar issue.

General info: 
I have two GMail accounts configured in Evolution: 'aklapper@abcdefghi.org' (the account where this happens) and 'other_account@gmail.com' (irrelevant).
I do switch a lot between folders in my GMail account so there's a lot of syncing, updating, downloading for offline usage, moving and local mail filtering happening.

I had probably tried to open those two messages earlier but they were not yet downloaded (or my connection was flaky). 

That affected subfolder "INBOX/wikitech-l" is NOT marked for downloading messages for offline usage in my account "aklapper@abcdefghi.org".
"INBOX" and "INBOX/maniphest" ARE marked for downloading messages for offline.

Created attachment 330941 [details]
Debug output for "Generating message list"

Has been showing "Generating message list" for two hours now, in online mode. 
I don't think that I went to offline/sync beforehand.

(In reply to André Klapper from comment #12)
> NOT necessarily the same issue, but same outcome:

I might need also a backtrace of the running evolution in this state to investigate it further. Maybe you face bug #748223 comment #22 here.

Backtrace for stuck "Retrieving message '931985' in INBOX".
Re comment 12.

$:andre\> gdb -p 20156
GNU gdb (GDB) Fedora 7.11.1-75.fc24
Copyright (C) 2016 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-redhat-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".
Attaching to process 20156
[New LWP 20158]
[New LWP 20159]
[New LWP 20160]
[New LWP 20161]
[New LWP 20162]
[New LWP 20163]
[New LWP 20195]
[New LWP 20196]
[New LWP 21607]
[New LWP 22574]
[New LWP 22776]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007fa73f76d32d in poll () at ../sysdeps/unix/syscall-template.S:84
84	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) thread apply all bt

+ Trace 236468

(gdb) list
79	#else
80	
81	/* This is a "normal" system call stub: if there is an error,
82	   it returns -1 and sets errno.  */
83	
84	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
85		ret
86	T_PSEUDO_END (SYSCALL_SYMBOL)
87	
88	#endif
(gdb) info register
rax            0xfffffffffffffdfc	-516
rbx            0x55a03a3b9190	94146660110736
rcx            0x7fa73f76d32d	140356301017901
rdx            0x21	33
rsi            0x4	4
rdi            0x55a03b77fda0	94146680847776
rbp            0x55a03b77fda0	0x55a03b77fda0
rsp            0x7ffcd1c4a8f0	0x7ffcd1c4a8f0
r8             0x4	4
r9             0x1	1
r10            0x55a03a4e8160	94146661351776
r11            0x293	659
r12            0x4	4
r13            0x21	33
r14            0x7fa73fa90330	140356304306992
r15            0x4	4
rip            0x7fa73f76d32d	0x7fa73f76d32d <poll+45>
eflags         0x293	[ CF AF SF IF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0

Created attachment 331744 [details]
Debug output for stuck "Retrieving message '931985' in INBOX".

Re comment 12.

(Upgraded to 3.20.4 in the mean time, hence need a new custom build I'm afraid. 
Stuck "Retrieving message '123456' in $folder" still happening.)

Thanks for the update. The leftover activity mentioned at comment #16 corresponds to the thread 11 of the backtrace at comment #15. The log in comment #16 shows that the evolution was offline for some time (I do not know neither the reason, nor for how long), then it went online again and while it was connecting this request to retrieve that message was initiated. As the store was still offline the request to move it to online first had been done and that's the place where it left. Usual behaviour is that the connect request is either initiated or it is pushed into the queue of the pending requests for the connection and once the connect is over all the pending requests are notified about it and the execution continues.  This didn't happen here, the request is left waiting for some reason. There is filled bug #742167 for this "when going online" issue.

The backtrace is different from the one at comment #0, respectively at comment #3, thus the cause can be different too.

*** Bug 788218 has been marked as a duplicate of this bug. ***

I am pretty sure that this is the same issue as bug #742167, thus I mark this as a duplicate of it.

*** This bug has been marked as a duplicate of bug 742167 ***

(In reply to Milan Crha from comment #20)
> I am pretty sure that this is the same issue as bug #742167, ...

But maybe not. I just accidentally reproduce something similar, with the same outcome, when I use View->Message Source on a message which is not downloaded yet and before it is downloaded, shortly after the message window appears, I close the new window with an Escape key press. There is left that "Generating message list" activity in the status bar. I do not know whether it's exactly the same thing as you saw here though.

There can be more cases. The below change is at least for the one I could reproduce. I could not reproduce when changing from threaded to not-threaded view and back.

Created commit 7586e5e7e7 in evo master (3.29.1+)
Created commit c5a367c4b7 in evo gnome-3-28 (3.28.1+)