TB account can get stuck when filter for storing decrypted emails is applied...
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
Menu
▾
▴
1 Attachments
#485 TB account can get stuck when filter for storing decrypted emails is applied for more than one account
Hi,
there was a further issue reported in the TB support forum at thunderbird-mail.de which seems to be related to bug#443. This bug has been marked as fixed already, because we thought it would be solved with 1.8.2 beta.
So I am not sure if you want to track it in the existing bug or separately. Please mark this one as a duplicate if you prefer to track it in #443.
I have done some tests and can confirm that an IMAP account gets stuck when the filter for storing a decrypted copy is applied to two (or more) accounts and both are receiving encrypted emails at almost the same time. I think this is because Thunderbird is running the filters for both accounts in parallel.
I have tested this by sending an email from my account A to my account B while putting the sending account A on cc.
This may not be a very common scenario, but I assume that the same will happen too right after the startup of Thunderbird if encrypted messages are downloaded for multiple accounts, that have this the filter applied to.
For my tests I have been using IMAP
Enigmail 1.8.2pre3
Thunderbird 31.6.0
GunPG 1.4.16 on Ubuntu Linux
It was also reported for POP
Enigmail 1.8.2pre3
Thunderbird 31.6.0
gpg4win-2.2.4 on Windows 8.1
(I cannot test this because I do not have a Window 8 installation nor a POP account)
I have attached the logs from my tests with Linux.
Cheers
Susi
Diff:
Yes, there are still various problems (known and unknown) related to the filter. They seem to be related to specific message attributes; I don't think they are related to getting new messages in parallel.
I have some further information that hopefully can help.
a) In the scenario above, just one of the two accounts get stuck. For the other account the filter works fine. I think you can see this in the logs.
b) If I disable the Idling for one of the accounts, let's say A, the filter works fine for account B that still has idling enabled. If then download the messages for A manually, i.e. after B has received the email already and the filter has finished, the filter also works fine for account A too.
c) Running the filters manually always seems to work fine for both accounts.
The log is quite clear - the error is the same as the one you reported initially - the Thunderbird function does not return or execute the defined callback function.
All I can do is implement a workaround that aborts the message processing in this case. I have now added a timeout that jumps in and displays a message if the process is stuck for 30 seconds.
As I cannot reproduce your issue, can you please try the following nightly build:
https://www.enigmail.net/download/nightly/enigmail-nightly-enigmail-1.8-branch-all.xpi
Good news first. I have tested the nighly with Windows xp in a virtual machine today. The issue does not show up - all works well for me. (I had not tested for this under Windows yet, because the guy who reported the problem wrote he would be using Window 8.1)
So I will go back to this guy and ask to test again and provide a log file.
Using Ubuntu, the issue is still present. I have tested with no other add-on active than Enigmail.
Maybe interesting: The new timeout message does not show up during the initial download of the message. After restarting Thunderbird the message appears, but the account keeps stuck. The download does not abort/finish.
The only way out is still to set the filter to be run manually only and restart Thunderbird again. After this, the message is downloaded and the account is back to normal.
I have attached the log file but I guess it won't tell you any news. To figure out if the problem indeed affects Linux only, maybe just Ubuntu and the customized TB-build or maybe even just my own installation, I will also ask others to test with different Linux distributions. I will keep you informed.
I suspect that this may be a specific problem of the Ubuntu version of Thunderbird. Could you try the official Thunderbird version for Linux available from mozilla.org?
Yes, I can certainly do so. I'd just like to wait for some response at thunderbird-mail.de, especially from the user who reported the issue on Win 8.1.
As there is still no response from the guy who reported the issue on Windows 8.1, I have now done a test with the Linux Version from mozilla.org with a fresh TB test profile. The issue has not occurred.
I also performed a cross testing and used the same profile with the Ubuntu build. As supposed, the issue did show up again.
So as far I can test, I am pretty sure the problem is with the adjusted Ubuntu build.
My apologies for the false alarm
It would still be interesting to find out what the problem with the Ubuntu version of Thunderbird is. Can you start the Ubuntu-version of Thunderbird from the command line and see if there is any error message on the console when the processing gets stuck?
Yes, there are a few messages. Right after start up, some confirmations:
enigmail.js: Registered components
mimeVerify.jsm: module initialized
Shortly afterwards:
2015-04-12 15:40:55 autosyncActivities ERROR OnDownloadError: Posteingang of XXX@gmx.de
2015-04-12 15:40:55 autosyncActivities ERROR OnDownloadError: Josef of YYY@t-online.de
At this stage the download hangs. No further messages.
Posteingang of XXX@gmx.de is inbox of the account that in this case has worked fine. The message had been downloaded and the decrypted copy was successfully stored in a local folder.
Josef of YYY@t-online.de is a normal IMAP folder on the account that got stuck. I was a bit surprised about that, because this folder should not be involved at all. I repeated the test and the error occurred more or less randomly for other "normal" folders, but always for the same IMAP account.
I noticed that, because I have done these tests with a fresh profile that I had set up yesterday, by default all my IMAP folders had been marked to be available offline and also to be indexed for the global search.
So I disabled both features for all IMAP-folders of this account. A first test was successful.
To double check, I enabled both features again and repeated the test. Well, it still works fine. With this profile, I currently cannot reproduce the failure anymore.
Using my standard profile, the issue is still present, for both the Ubuntu build as well as the one from mozilla.org. This clearly indicates that the issue is related to the profile.
I enabled IMAP-Logging in Thunderbird and have attached the log file from a session where the issue occurred. Not sure if this can help.
The guy who initially reported this issue on Win 8.1. has also responded in the meantime. He has set up a new profile and also cannot reproduce the problem anymore.
However, this is still a bit strange. I had tested with a brand new profile and was able to reproduce the issue constantly when using the Ubuntu-Build, bot not with the build from mozilla.org.
I have been using the same profile today and the failure does not show up after the changes I mentioned above.
Also worth mentioning: With the nightly build you provided, the behaviour changed a bit. When the account is stuck and I confirm to skip, the account is still stuck, but when closing Thunderbird it is now really closing. There is no more a TB-process running, like it was before.
Well yes, in the nightly build I provided the thing I "fixed" was that if you clicked on Skip, the filter process continues. It seems that the hanging filter process caused Thunderbird to wait before it terminates (and therefore never terminate).
However, this is not of much help if the IMAP folder is still stuck. Unfortunately I have no idea about how to read an IMAP log file, but I have created a Thunderbird bug with all information I have: https://bugzilla.mozilla.org/show_bug.cgi?id=1153646
I think it would be good if you could subscribe to the bug to be able to answer any question (if needed).
Accodring to https://bugzilla.mozilla.org/show_bug.cgi?id=1153646#c2 the problem is solved.