[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25060: gnutls: asynchronous spurious "fatal error"
From: |
Ted Zlatanov |
Subject: |
bug#25060: gnutls: asynchronous spurious "fatal error" |
Date: |
Mon, 30 Jan 2017 15:10:46 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
On Wed, 25 Jan 2017 00:17:58 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:
LI> Yes, it just means that the peer ended the connection. I think gnutls.c
LI> shouldn't say anything in that case -- any sentinels get the proper
LI> callback and stuff, and as information it's pretty worthless for the
LI> user.
LI> I'm installing the following patch, but if there's any disagreement
LI> here, we can discuss further...
LI> diff --git a/src/gnutls.c b/src/gnutls.c
LI> index 735d2e3..6fa0e10 100644
LI> --- a/src/gnutls.c
LI> +++ b/src/gnutls.c
LI> @@ -582,8 +582,15 @@ emacs_gnutls_handle_error (gnutls_session_t session,
int err)
LI> if (gnutls_error_is_fatal (err))
LI> {
LI> + int level = 1;
LI> + /* Mostly ignore "The TLS connection was non-properly
LI> + terminated" message which just means that the peer closed the
LI> + connection. */
LI> + if (err == GNUTLS_E_PREMATURE_TERMINATION)
LI> + level = 3;
LI> +
LI> + GNUTLS_LOG2 (level, max_log_level, "fatal error:", str);
LI> ret = 0;
LI> - GNUTLS_LOG2 (1, max_log_level, "fatal error:", str);
LI> }
LI> else
LI> {
IIRC that #define wasn't available until recently so we couldn't use it
until now :) Thanks! It resolves the issue for me. We may want to add a
per-connection counter of these, though, in case code or users want to
examine it.
Ted