gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data

[Wilmer van der Gaast]

Hello Nikos,

Thanks for your response.

This is with GnuTLS 3.0.17 (currently available in Debian testing). I'm 
attaching logs from that version, and also logs generated with GnuTLS 
2.12.18 which does not have this problem.

On 08-04-12 13:55, Nikos Mavrogiannopoulos wrote:
>
> Since you received eagain, I think that the promise is kept, there was
> no blocking. However, this scenario should be improbable in normal TLS.

Okay, so I did add one interpretation here, which makes sense for normal 
Unix sockets but possibly not for TLS: I'm assuming that EAGAIN here 
means that the operation would've blocked if I didn't make the socket 
non-blocking. (IIRC EWOULDBLOCK is an alias for EAGAIN so it seems like 
a reasonable assumption to me?)

To check my facts here I've run strace against my program:

epoll_ctl(3, EPOLL_CTL_DEL, 12, {EPOLLIN, {u32=12, u64=12}}) = 0
recvfrom(12, 0xaf3070, 5045, 0, 0, 0)   = -1 EAGAIN (Resource 
temporarily unavailable)

So it looks like GnuTLS is indeed trying to read more data from the 
socket even though we still have something buffered?

> I'd be interested to see the reason of the eagain. Could you provide
> debugging information of level 2 or more for your scenario?

Attached to this e-mail now. Hope it helps. The condition does seem to 
trigger some asserts at least.


Thanks,

Wilmer van der Gaast.

-- 
+-------- .''`.     - -- ---+  +        - -- --- ---- ----- ------+
| wilmer : :'  :  gaast.net |  | OSS Programmer   www.bitlbee.org |
| lintux `. `~'  debian.org |  | Full-time geek  wilmer.gaast.net |
+--- -- -  ` ---------------+  +------ ----- ---- --- -- -        +
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls.dbg
URL: </pipermail/attachments/20120409/57e242c1/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls-ok.dbg
URL: </pipermail/attachments/20120409/57e242c1/attachment.asc>