OSError: [Errno -1] ERR_MEM
i can't find the meaning of this error in the micropython error list it is not listed.
OSError: [Errno -1] ERR_MEM
does anyone knows what this means and what to do with it?
thanks for the help,
with pinging in between it is much more stable, it still sometimes gives the same error, i'm gonna build something similar as you have, the error at this point gives me at least an idea where it goes wrong. if i remove it some other things might go wrong
Somewhere in my main loop i am checking connected state (which tries pinging) and causes a reconnect if it drops out. This has worked out to be robust.
@Eric-Waai thats what I found, check_msg only looks to see if any data is there in the socket. I have found that a lot of MQTT services, require a ping, or some other activity to keep the session alive. Otherwise their own inactivity timeout kicks in.
Eric Waai last edited by Eric Waai
thanks it looks like that is the case.
i added a ping every now and then and it's still going
i prefer this before removing errors.
if the error still occurs i maybe remove it but for now it stays
edit: still weird. i assumed that check_msg would be sufficient to keep the connection alive
@Eric-Waai You may find that the remote connection is being closed. You may need to explicitly perform an mqtt Ping to keep the connection alive.
do you have any idea what is the reason of this problem.
i did some testing yesterday, if i don't send anything via mqtt but do check for messages it crashes every time after 5 minutes and 16 seconds.
Milan last edited by
@Eric-Waai Yes, you are right. I've bypassed this case by removing following part of the code:
if res == b"": raise OSError(-1)
i also get this problem with mqtt.
i'm getting this error quite often especially when i send nothing for a long time. but only check for mesages
def wait_msg(self): res = self.sock.read(1) self.sock.setblocking(True) if res is None: return None if res == b"": raise OSError(-1) if res == b"\xd0": # PINGRESP sz = self.sock.read(1) assert sz == 0 return None
i found the piece of code where the error occurs but don't know precise what is going wrong. it looks like no response from the server to me.
it should just try again if you ask me
@robert-hh interesting. I am getting this occasionally when using umqtt.simple to communicate with Losant with TLS. (Despite this umqtt.simple turns out to be more reliable than the underlying AWS Mqtt code).
I am monitoring memory continuously, so it would seem , in my case it is not a system memory issue (2,500,000 bytes free - am I looking at gc.mem_free ) . It would seem this
"return ERR_MEM if the length of the data exceeds the current send buffer size or if the length of the queue of outgoing segment is larger than the upper limit defined in lwipopts.h. The number of bytes available in the output queue can be retrieved with the tcp_sndbuf() function."could well be the culprit. Will investigate this further.
Thanks for providing things.
from the sources, pycom-micropython-sigfox/lib/lwip/doc/rawapi.txt
The tcp_connect() function can return ERR_MEM if no memory is
available for enqueueing the SYN segment. If the SYN indeed was
enqueued successfully, the tcp_connect() function returns ERR_OK.
The tcp_write() function will fail and return ERR_MEM if the length
of the data exceeds the current send buffer size or if the length of
the queue of outgoing segment is larger than the upper limit defined
in lwipopts.h. The number of bytes available in the output queue can
be retrieved with the tcp_sndbuf() function.
The proper way to use this function is to call the function with at
most tcp_sndbuf() bytes of data. If the function returns ERR_MEM,
the application should wait until some of the currently enqueued
data has been successfully received by the other host and try again.
- err_t tcp_close(struct tcp_pcb *pcb)
Closes the connection. The function may return ERR_MEM if no memory
was available for closing the connection. If so, the application
should wait and try again either by using the acknowledgment
callback or the polling functionality. If the close succeeds, the
function returns ERR_OK.