I am using claws-mail-3.9.3-1.fc20.i686 and I have a POP3 (TLS) account which locks up the program every time I try to fetch e-mails from it. After entering password and accepting their certificate GUI locks up totally - no reaction to events, no repainting, 1 CPU core hogged (100%) The busy loop is at inc.c:858-860. #0 session_is_running (session=session@entry=0x877c250) at session.c:243 #1 0x080f59c3 in inc_pop3_session_do (session=0x8783388) at inc.c:858 #2 inc_start (inc_dialog=inc_dialog@entry=0x8795670) at inc.c:631 #3 0x080f70b8 in inc_all_account_mail (mainwin=0x84d9ec8, autocheck=1, notify=0) at inc.c:384 #4 0x080f8042 in defer_check_all (data=data@entry=0x1) at main.c:313 #5 0x48066262 in g_timeout_dispatch (source=source@entry=0x86fa738, callback=0x80f8020 <defer_check_all>, user_data=0x1) at gmain.c:4451 #6 0x48065556 in g_main_dispatch (context=0x8497de0) at gmain.c:3066 #7 g_main_context_dispatch (context=context@entry=0x8497de0) at gmain.c:3642 #8 0x48065920 in g_main_context_iterate (context=0x8497de0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713 #9 0x48065dc3 in g_main_loop_run (loop=loop@entry=0x840a7e8) at gmain.c:3907 #10 0x4372d700 in IA__gtk_main () at gtkmain.c:1257 #11 0x080828cf in main (argc=1, argv=0xbffff214) at main.c:1551 Program never goes out of frame #1 above. The issue is 100%-reproducible. I tried Thunderbird and it fetches e-emails from that account with no problems. Workaround: disable problematic account.
Maybe this is related to #2416 but in my case the network log ends with: Begin TLS negotiation now.
Raising severity since a major feature - fetching e-mails from a POP3 server - doesn't work on a particular account (with 100% reproducibility) while the same e-mail account works fine in Thunderbird. IMHO there may be 2 bugs here: - failure to fetch e-mails from POP3 account (busy loop) - GUI totally locked up by a busy loop in POP3 fetching thread (is this by design?)
lowering severity since it appears to affect you alone
(In reply to comment #2) Hi, > Raising severity since a major feature - fetching e-mails from a POP3 server > - doesn't work on a particular account (with 100% reproducibility) while the > same e-mail account works fine in Thunderbird. > > IMHO there may be 2 bugs here: > - failure to fetch e-mails from POP3 account (busy loop) > - GUI totally locked up by a busy loop in POP3 fetching thread (is this by > design?) POP3 fetching isn't done in a thread, but in GTK's main loop using a state machine. The busy loop is the real bug. Is the server public ? I could investigate if so - apparently having an account wouldn't be needed as the bugs happens on TLS negotiation. By the way, thanks for your high quality bug reports :)
I reproduced the problem with --debug option. The log (personal data replaced with XXX) ends with: inputdialog.c:469:return string = ******** inputdialog.c:277:keeping session password for account inc.c:793:getting new messages of account XXXXXXXXXXX... session.c:189:session (0x93e7cf0): connected [09:43:35] POP3< +OK Hello there. [09:43:35] POP3> STLS [09:43:36] POP3< +OK Begin SSL/TLS negotiation now. ssl.c:229:waiting for SSL_connect thread... ssl.c:247:SSL_connect thread returned 0 ssl_certificate.c:389:got XXXXXXXXXXXXXX.110.cert first try ssl_certificate.c:236:got cert! 0x9040ee8 ssl_certificate.c:399:got cert 0x88cb848 alertpanel.c:254:Creating alert panel dialog... alertpanel.c:213:called inc_lock (lock count 1) alertpanel.c:223:called inc_unlock (lock count 0) alertpanel.c:107:return value = 1 [09:43:40] POP3> USER XXXXXXXXXXXXXXX The mail server is public: cba.pl You're right, it's enough to configure an account in claws-mail using cba.pl, TLS on, "test" username to reproduce the problem (I have just verified it). However, I'm not sure now if I was really able to fetch e-mails from that server with TLS on in Thunderbird. Possibly I had to switch to plain POP3. And now I am unable to re-check this in Thunderbird because I have already uninstalled it and don't want to install it again :) Anyway, as you confirmed, busy loop is a problem, so I'd appreciate if you could investigate it...
(In reply to comment #5) > The mail server is public: cba.pl > You're right, it's enough to configure an account in claws-mail using > cba.pl, TLS on, "test" username to reproduce the problem (I have just > verified it). > Just tried here: [12:45:15] NNTP< 211 783 6901 7683 dk.edb.system.unix * Account 'test': Connecting to POP3 server: cba.pl:995... [12:45:37] POP3< +OK Hello there. [12:45:37] POP3> USER mir [12:45:37] POP3< +OK Password required. [12:45:37] POP3> PASS ******** [12:45:42] POP3< -ERR Login failed. *** error occurred on authentication *** Authentication failed. No endless loop here. Using POP3: Use SSL for POP3 connection Send (SMTP): Use SSL for SMTP connection If I shift to use STARTSSL the problems occurs. However, if I try with IMAP4 instead of POP3 STARTTLS works flawlessly! To me it seems like a misconfigured server cause the server never returns with an answer to the login request.
Changes related to this bug have been committed. Please check latest Git and update the bug accordingly. You can also get the patch from: http://git.claws-mail.org/ ++ ChangeLog 2014-04-21 13:51:03.507432172 +0200 http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=ea9e88b501a28bb83e32f14c576a0392e82ddbf4 Merge: 88e6033 e664b67 Author: Colin Leroy <colin@colino.net> Date: Mon Apr 21 13:51:03 2014 +0200 Merge branch 'master' of file:///home/git/claws http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=e664b676602274aa7e7056444de88fa8f5684185 Author: Colin Leroy <colin@colino.net> Date: Mon Apr 21 13:49:46 2014 +0200 Fix bug #3139, "Mainwindow unresponsive due to a busy loop" In case of unexpected return from gnutls_record_recv(), set errno to a fatal error.
(In reply to comment #5) > The mail server is public: cba.pl > You're right, it's enough to configure an account in claws-mail using > cba.pl, TLS on, "test" username to reproduce the problem (I have just > verified it). > > Anyway, as you confirmed, busy loop is a problem, so I'd appreciate if you > could investigate it... Thanks for the server's name, it helped. Adding a bit of debugging showed that gnutls_record_recv() returns GNUTLS_E_UNEXPECTED_PACKET. I don't know how to recover from that, but in case of unexpected results from gnutls_record_recv(), I missed setting errno to a fatal error so that the connection would be dropped. As it was previously set to EAGAIN by network read code, and gnutls_record_recv() does not set it, it was stuck in an infinite loop. For the record, gnutls-cli -starttls -p 110 cba.pl fails with: *** Fatal error: An unexpected TLS packet was received. *** Server has terminated the connection abnormally. And openssl s_client -starttls pop3 -host cba.pl -port 110 fails with: 140066369763008:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: I'll mark the bug fixed as we didn't catch the error, but I guess I can't fix the error itself :)
Strange, suddenly works here with gnutls!! dpkg -s gnutls-bin Package: gnutls-bin Status: install ok installed Priority: optional Section: net Installed-Size: 916 Maintainer: Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org> Architecture: amd64 Multi-Arch: foreign Source: gnutls28 Version: 3.2.13-2 (In reply to comment #8) > > For the record, gnutls-cli -starttls -p 110 cba.pl fails with: > *** Fatal error: An unexpected TLS packet was received. > *** Server has terminated the connection abnormally. > gnutls-cli --starttls -p 110 cba.pl Processed 166 CA certificate(s). Resolving 'cba.pl'... Connecting to '95.211.144.89:110'... - Simple Client Mode: +OK Hello there. user test +OK Password required. pass test -ERR Login failed. - Peer has closed the GnuTLS connection > And openssl s_client -starttls pop3 -host cba.pl -port 110 fails with: > 140066369763008:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version > number:s3_pkt.c:337: > But openssl: 140476822103696:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
No more busy loop when querying this POP3+TLS server in claws-mail a9065aec26499a0e1294c73b6d9e6f039976521e; just a quick error message. And thanks for discovering that this server supports IMAP+SSL now :)
*** Bug 2416 has been marked as a duplicate of this bug. ***