Either intentionaly or due to bug in openssl in some marginal
cases SSL_send reports SYSCALL error whilst errno is set to 0.
This either could mean that SSL_send did not made any system
call or errno were prematurely reset with consequent syscalls.
And in consequence sendraw() is not propagate correct errno
ends up in infinite loop trying to send same data.
Such behaviour was usually observed after third consequential
failed SSL send attempt which application was not aware of.
First send failed with syscall errno 32 (Broken pipe) second
one with SSL error 0x1409e10f (bad length) and lastly next
send attemt results with SYSCALL error and errno 0.
Tested using:
* OpenSSL v1.1.1
* musl v1.1.20 (c50985d5c8e316c5c464f352e79eeebfed1121a9)
* Linux 4.4.60+yocto armv7l
winsock define INVALID_SOCKET as (UINT_PTR)(~0)
in win64 it is 0xffffffffffffffff
if pushed by lua_pushnumber, then ssl.core.SOCKET_INVALID is 1.84467440737096E19
tested in win32/64, linux32/64 lua5.1 and lua5.3
The Lua thread that creates the context is saved to be used for
accessing callback related data. However that thread may become garbage
and its memory could be overwritten with anything if the handshake
happens later, in a different thread.
Fixes#75
Thanks @Zash
The number of bytes received by ssl_recv() is being passed to luaL_addlstring() (in recvall()) but it was being left either uninitialized or being set to an error code. The crashing case I found was when the state was not LSEC_STATE_CONNECTED (e.g. when dohandshake() has failed) and ssl_recv() returned immediately without setting "got".
