[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Several problems
Re: Several problems
Wed, 30 Jul 2014 16:02:23 -0400
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4.50 (gnu/linux)
Hello David and Dmitry,
I see the following situation (using the Git mirror):
* Dmitry's commit 4c19675328d0de84cc3181cfc118973f591e8243 broke GnuTLS
connections and possibly more. I couldn't even do the initial
* the followup fix was good for the initial connection, but larger
amounts of data fail:
Author: Dmitry Antipov <address@hidden>
Date: Mon Jul 28 18:50:55 2014 +0400
Fix Gnus-related issues reported by David Kastrup <address@hidden> in
* atimer.c (timerfd_callback): Always read expiration data.
(turn_on_atimers) [HAVE_TIMERFD]: Disarm timerfd timer.
* process.c (add_timer_wait_descriptor): Add timer descriptor
to input_wait_mask and non_process_wait_mask as well.
I've only tested with GnuTLS connections.
The symptom seems to be that GnuTLS will read data, then gets a retry,
and finally hangs forever. I can duplicate it by trying to read the last
200 messages in emacs-devel and I believe even as little as 16K will
trigger the behavior. But if I read the last 1 message only (`C-u 1
RET') then things work. If this is indeed a timer problem, it will be
hard to replicate but I hope this is enough data.
It would be nice if we could automate the testing of this behavior. It
can probably be done with a TLS server (`gnutls-serv' for instance) but
in my experience that's a very tricky type of test that tends to throw
spurious errors. So it may just be something we live with.
I have probably missed the discussion about this timerfd feature (having
just come back from vacation), so please forgive my ignorance, but is
this something that should always be enabled, or can it be configurable?
If it interferes with GnuTLS connections, maybe it should be disabled
I am following up to emacs-devel instead of opening a bug report because
that's where David Kastrup posted initially. If you prefer a bug
report, let me know.
- Several problems, David Kastrup, 2014/07/28
- Re: Several problems,
Ted Zlatanov <=