GNOME Bugzilla – Bug 560057
evolution entering endless loop while trying to fetch headers form nntp server
Last modified: 2013-09-13 00:59:59 UTC
Please describe the problem: I created a usenet account on a news server, subscribe to a few groups, and click on a newsgroup to fetch headers (and probably articles) and evolution would enter an endless loop. Below is a stacktrace. Messages from the debug log: NNTP_STREAM_LINE(22): '423 Bad article number' NNTP_COMMAND: 'head 949749' NNTP_STREAM_LINE(22): '423 Bad article number' NNTP_COMMAND: 'head 949750' NNTP_STREAM_LINE(22): '423 Bad article number' NNTP_COMMAND: 'head 949751' NNTP_STREAM_LINE(22): '423 Bad article number' NNTP_COMMAND: 'head 949752' NNTP_STREAM_LINE(22): '423 Bad article number' NNTP_COMMAND: 'head 949753' NNTP_STREAM_LINE(22): '423 Bad article number' NNTP_COMMAND: 'head 949754' NNTP_STREAM_LINE(22): '423 Bad article number' NNTP_COMMAND: 'head 949755' NNTP_STREAM_LINE(22): '423 Bad article number' NNTP_COMMAND: 'head 949756' Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information: (gdb) p o $23 = (unsigned char *) 0x8c7b400 "423 Bad article number" (gdb) p oe $24 = (unsigned char *) 0x8c7b7ff "" (gdb) p oe +1 $25 = (unsigned char *) 0x8c7b800 "\b\004" (gdb) p *is $26 = {parent = {parent_object = {klass = 0x8cbb030, magic = 2007188717, hooks = 0x0, ref_count = 2, flags = 0, next = 0x0, prev = 0x0}, eos = 0}, source = 0x8bc54e0, mode = CAMEL_NNTP_STREAM_LINE, state = 0, buf = 0x8c46398 "423 Bad article number\r\n\n.news.schlund.de!schlund.de!newsfeed01.sul.t-online.de!t-online.de!news.germany.com!aioe.org!not-for-mail\r\nFrom: MalcolmO <user@domain.invalid>\r\nNewsgroups: alt.conspiracy,alt"..., ptr = 0x8c46398 "423 Bad article number\r\n\n.news.schlund.de!schlund.de!newsfeed01.sul.t-online.de!t-online.de!news.germany.com!aioe.org!not-for-mail\r\nFrom: MalcolmO <user@domain.invalid>\r\nNewsgroups: alt.conspiracy,alt"..., end = 0x8c463b0 "\n.news.schlund.de!schlund.de!newsfeed01.sul.t-online.de!t-online.de!news.germany.com!aioe.org!not-for-mail\r\nFrom: MalcolmO <user@domain.invalid>\r\nNewsgroups: alt.conspiracy,alt.illuminati,de.soc.polit"..., linebuf = 0x8c7b400 "423 Bad article number", lineptr = 0x8c7b400 "423 Bad article number", lineend = 0x8c7b800 "\b\004"} (gdb) bt
+ Trace 209538
Thomas, Im working on 4 other blockers atm. I would be looking at it, later this week or starting next week. Thanks.
Sucks, I missed this out. I'll take up next week.
*** Bug 571061 has been marked as a duplicate of this bug. ***
*** Bug 378121 has been marked as a duplicate of this bug. ***
Thomas: which groups do this for you? I just tried alt.conspiracy and it doesn't do that for me. Akhil: Those two are different, that g_assert is still there, maybe changing it to regular test, with an explanation as "check if didn't quit yet" may help there. Or looking for value of camel_application_is_exiting would help there as well, or even better, whether the operation was canceled? I do not know.
Well, just tried it again, with the latest evolution trunk version and it happened again. I interrupted the loop and debugged a bit. it looks, like an error condition is not handled in camel_read(). Here is the relevant sectionn of my gdb session: NNTP_STREAM_LINE(22): '423 Bad article number' NNTP_COMMAND: 'head 960498' C-c C-c Program received signal SIGINT, Interrupt.
+ Trace 212822
Thread 3058797424 (LWP 7478)
Hope that helps.
I deleted the account and created it again. The new account differed from the previous as I chose "no authorization" and did not check to use short notation for newsgroups as I did in the previous configure. And ... ala, even a big newsgroup like alt.conspiracy would be fetched without problems. So, I would suggest to close this bug. thomas
Ah, nice. (In reply to comment #6) > Well, just tried it again, with the latest evolution trunk version and it > happened again. I interrupted the loop and debugged a bit. it looks, like an > error condition is not handled in camel_read(). It's fine, because it's handled a bit later, in camel-nntp-summary.c, in add_range_head function: 371 ret = camel_nntp_raw_command_auth(store, ex, &line, "head %u", i); 372 /* unknown article, ignore */ 373 if (ret == 423) 374 continue; it seems your summary got broken, and reported too big range of heads, whatever that means in NNTP. Your range was (those 'high' and 'low' arguments):
+ Trace 212842
and it was making progress, even quite slow. I was interested in a reproducer, but if you're fine with this, then ok, feel free to close this bug.