bug#71452: 30.0.50; GNUS hangs on IMAP/s reads starting at commit bbc1803

[Dmitry Gutov]

On 10/06/2024 00:30, epg@pretzelnet.org wrote:
> Dmitry Gutov<dmitry@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
Description: Text Data