[gnutls-help] Regression bug between 2.x and 3.2?

Nikos Mavrogiannopoulos nmav at gnutls.org
Sun Jun 15 22:47:29 CEST 2014

On Fri, 2014-06-13 at 16:21 +0000, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> >  Could you provide a gnutls trace (use GNUTLS_DEBUG_LEVEL=6 or more),
> With GNUTLS 3.2.13, here's the point of failure (SSOCK#1000 is our callback's output that shows that it
> could write only 528 bytes -- GNUTLS was pushing 1053).  After that the control gets back from
> gnutls_record_send() with a GNUTLS_E_EAGAIN return code rather than the callback is tried one
> more time (it's how send() should have been used).

>From that description I think that this is pretty much expected. A call
to gnutls_record_send() can be interrupted, and had to be called again
(I believe that was the case in all gnutls versions). If that's not
clear from the documentation please let me know what could be improved.

>   Note that we're using non-blocking output
> in the callback.  So when the device is full, it won't accept any data at all and won't block,
> so the callback does a short wait, then tries again and returns immediately if anything at all
> has been written successfully.

That sounds a pretty typical use case. The way to make that work in the
old and new gnutls, would be to call gnutls_record_send() until it
doesn't return GNUTLS_E_AGAIN or GNUTLS_E_INTERRUPTED, with the same
parameters as before (or null). 

> mini-eagain.c is not a good test, IMO.

It's purpose is to test whether interruption of gnutls calls works as
expected, but had proved to be too limited, and thus the
tests/suite/ecore was added, which was a check more to real world. I
haven't checked these tests for years though. If you think that there is
something missing from being checked don't hesitate to enhance the


More information about the Gnutls-help mailing list