GNU bug report logs -
#49449
28: TLS connection never gets to "open" stage
Previous Next
Full log
View this message in rfc822 format
It seems that the process/TLS apparatus can get into a state where it is unable to ever call the process sentinel "open\n" event; specifically, an async `url-https` does not make forward progress until the connection times out.
This has been observed on macOS in Emacs 28 now and then, and it looks like there is an invariant violation somewhere. To recap:
The "open\n" event is sent to the sentinel in either of two places:
(A) In finish_after_tls_connection, after having successfully called nsm-verify-connection and the condition
(fd_callback_info[p->outfd].flags & NON_BLOCKING_CONNECT_FD) == 0
being satisfied (process.c:3277).
(B) In wait_reading_process_output, after the descriptor being found writable by `select` and the condition
NILP (p->gnutls_boot_parameters) && !p->gnutls_p
being satisfied (process.c:5900).
There seems to be a gap in the logic, however: it is perfectly possible for the condition in (A) to fail because the descriptor is still marked nonblocking at that point, and for (B) to fail because gnutls_p=true was set already in gnutls_try_handshake.
Lars, it looks like you wrote at least part of the original logic. Can you see what is going on? It is somewhat complex.
For reference, I'm using the reproduction recipe below; it may or may not exhibit the problem in your particular setup. I'm using gnutls 3.6.15.
(defun busy-wait (s)
(let ((t0 (current-time)))
(while (< (time-to-seconds (time-since t0)) s) nil)))
(progn
(url-http
#s(url "https" nil nil "elpa.gnu.org" nil "/packages/archive-contents" nil nil t silent t t)
(lambda (status) (message "callback: status = %S" status))
'(nil) nil 'tls)
(busy-wait 1.0))
This bug report was last modified 3 years and 332 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.