From: Robert Pluim <rpluim@gmail.com>
To: Derek Zhou <derek@3qin.us>
Cc: 40665@debbugs.gnu.org
Subject: bug#40665: 28.0.50; tls hang on local ssl
Date: Sun, 19 Apr 2020 16:34:38 +0200 [thread overview]
Message-ID: <m24kthgh28.fsf@gmail.com> (raw)
In-Reply-To: <86wo6fo78r.fsf@mail.3qin.us>
>>>>> On Sat, 18 Apr 2020 02:44:05 +0000 (UTC), Derek Zhou <derek@3qin.us> said:
Derek> Derek Zhou writes:
>> When this thing happens, the tls handshakes are done properly. However,
>> emacs did not write anything into gnutls before starting to read and
>> obviously cannot get anything out at all. It is not really a hang, but
>> write never happen and the display buffer stays empty.
>>
>> Derek
Derek> Took my nearly the whole day to debug, but this one-line patch fixed my
Derek> problem.
Derek> My server finishes tls handshake within the gnutls_boot itself, and if the
Derek> sentinel is not called right after, it will never be called so write
Derek> will not happen. Someone should review this carefully.
Derek> diff --git a/src/process.c b/src/process.c
Derek> index 91d426103d..6d497ef854 100644
Derek> --- a/src/process.c
Derek> +++ b/src/process.c
Derek> @@ -5937,8 +5937,7 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
Derek> /* If we have an incompletely set up TLS connection,
Derek> then defer the sentinel signaling until
Derek> later. */
Derek> - if (NILP (p->gnutls_boot_parameters)
Derek> - && !p->gnutls_p)
Derek> + if (NILP (p->gnutls_boot_parameters))
Derek> #endif
Derek> {
Derek> pset_status (p, Qrun);
Hereʼs what I think is happening:
The only way for p->gnutls_boot_parameters to become nil is here in
connect_network_socket:
if (p->gnutls_initstage == GNUTLS_STAGE_READY)
{
p->gnutls_boot_parameters = Qnil;
/* Run sentinels, etc. */
finish_after_tls_connection (proc);
}
and finish_after_tls_connection should call the sentinel, but
NON_BLOCKING_CONNECT_FD is still set, so it doesnʼt.
The next chance to call the sentinel would be from
wait_reading_process_output, but only if handshaking has been tried
and not completed, except it is complete already.
wait_reading_process_output then calls delete_write_fd, which clears
NON_BLOCKING_CONNECT_FD, and doesnʼt run the sentinel because
p->gnutls_boot_parameters is nil and p->gnutls_p is true
finish_after_tls_connection never gets another chance to run, since
the socket is connected and handshaking is complete.
After your change, you've fixed this case:
if p->gnutls_boot_parameters is nil, that means the handshake
completed already and the TLS connection is up, so
calling the sentinel is ok.
In other cases where the handshake does not complete straight away in
Fgnutls_boot, it will complete here in wait_reading_process_output
/* Continue TLS negotiation. */
if (p->gnutls_initstage == GNUTLS_STAGE_HANDSHAKE_TRIED
&& p->is_non_blocking_client)
{
gnutls_try_handshake (p);
p->gnutls_handshakes_tried++;
if (p->gnutls_initstage == GNUTLS_STAGE_READY)
{
gnutls_verify_boot (aproc, Qnil);
finish_after_tls_connection (aproc);
}
which always happens after delete_write_fd has been called, which
clears NON_BLOCKING_CONNECT_FD, so finish_after_tls_connection calls
the sentinel.
One change we could make is to set p->gnutls_boot_parameters to nil
here, so that in the sequence
Fgnutls_boot, handshake does not complete
handshake succeeds first time in wait_reading_process_output
delete_write_fd then checks p->gnutls_boot_parameters
the sentinel ends up getting run, but Iʼve not seen the handshake ever
succeed straight away before the delete_write_fd, and if it ever has
in the wild we would have seen bug reports (and this is dragon-filled
code, so I donʼt want to make changes to it if I can help it :-))
In short: I think the change is ok. It passes the network-stream
tests, so Iʼll run with it for a while, and push it in a week or so.
Robert
next prev parent reply other threads:[~2020-04-19 14:34 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 14:06 bug#40665: 28.0.50; tls hang on local ssl Derek Zhou
2020-04-16 16:22 ` Robert Pluim
2020-04-16 18:22 ` Derek Zhou
2020-04-16 20:47 ` Derek Zhou
2020-04-16 23:01 ` Derek Zhou
2020-04-17 18:41 ` Derek Zhou
2020-04-18 2:44 ` Derek Zhou
2020-04-19 14:34 ` Robert Pluim [this message]
2020-04-19 15:34 ` Derek Zhou
2020-04-19 16:12 ` Robert Pluim
2020-04-21 0:27 ` Derek Zhou
2020-04-21 1:41 ` Derek Zhou
2020-04-21 7:39 ` Robert Pluim
2020-04-21 13:37 ` Derek Zhou
2020-04-21 14:03 ` Robert Pluim
2020-04-21 14:45 ` Derek Zhou
2020-04-21 15:02 ` Derek Zhou
2020-04-21 15:04 ` Robert Pluim
2020-04-21 20:20 ` Derek Zhou
2020-04-21 22:20 ` Derek Zhou
2020-04-21 22:29 ` Derek Zhou
2020-04-22 8:32 ` Robert Pluim
2020-04-22 12:25 ` Derek Zhou
2020-04-22 13:12 ` Robert Pluim
2020-04-22 15:16 ` Derek Zhou
2020-04-22 16:14 ` Robert Pluim
2020-04-22 16:57 ` Derek Zhou
2020-04-23 2:20 ` Derek Zhou
2020-04-24 14:23 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-04-24 14:29 ` Robert Pluim
2020-05-07 19:08 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-07-31 23:22 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-08-02 5:34 ` Lars Ingebrigtsen
2020-08-03 5:58 ` Lars Ingebrigtsen
2020-08-03 9:44 ` Robert Pluim
2020-08-03 13:57 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-08-03 16:03 ` Robert Pluim
2020-08-04 8:42 ` Lars Ingebrigtsen
2020-08-04 19:28 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-08-04 19:45 ` Lars Ingebrigtsen
2020-08-03 13:36 ` Derek Zhou via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-04-17 8:35 ` Robert Pluim
2020-04-18 2:46 ` Derek Zhou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m24kthgh28.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=40665@debbugs.gnu.org \
--cc=derek@3qin.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.