GNU bug report logs - #71452
30.0.50; GNUS hangs on IMAP/s reads starting at commit bbc1803

Previous Next

Full log

Message #29 received at 71452 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: epg <at> pretzelnet.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, 71452 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#71452: 30.0.50; GNUS hangs on IMAP/s reads starting at commit
 bbc1803
Date: Mon, 10 Jun 2024 07:09:52 +0300

[Message part 1 (text/plain, inline)]

On 10/06/2024 00:30, epg <at> pretzelnet.org wrote:
> Dmitry Gutov<dmitry <at> gutov.dev>  writes:
> 
>> OP, could you retest with the latest master and read-process-output-fast set
>> to its default value (t)?
>>
> As of 12d44fe6420e84eab8f750f9a0f8cd73c3e70bb2, still hangs with
> read-process-output-fast t, works with it nil.

Okay, thank you. I can reproduce it too.

FWIW, it hangs here:

Lisp Backtrace:
"accept-process-output" (0xf19ff6a8)
"nnheader-accept-process-output" (0xf19ff610)
"nnimap-wait-for-response" (0xf19ff5a8)
"nnimap-retrieve-headers" (0xf19ff530)
"gnus-retrieve-headers" (0xf19ff4b8)
"gnus-cache-retrieve-headers" (0xf19ff450)
"gnus-retrieve-headers" (0xf19ff3d0)
"gnus-fetch-headers" (0xf19ff360)
"gnus-select-newsgroup" (0xf19ff2c0)
"gnus-summary-read-group-1" (0xf19ff228)
"gnus-summary-read-group" (0xf19ff188)
"gnus-group-read-group" (0xf19ff100)
--Type <RET> for more, q to quit, c to continue without paging--
"gnus-group-select-group" (0xffffdb10)
"funcall-interactively" (0xffffdb08)
"call-interactively" (0xf19ff070)
"command-execute" (0xffffddf8)

Commands can be different, but nnimap-wait-for-response is where it 
stops. And it's not edebug-able: instrumenting the function makes the 
bug go away.

Print-debugging seems to say that there might be something wrong with 
what (forward-line -1) does: output has the ^M chars, and apparently the 
new logic makes it skip over too many characters.

The only thing relevant I found is this bit, which for now I simply 
copied over from read_and_dispose_of_process_output. But the latter 
calls it after "decoding to string" yet before inserting the string into 
the buffer. Can we do this after the decode_coding_c_string call where 
dst_object is the target buffer?

[Vlast_coding_system_used.diff (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.