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

    https://github.com/micropython/micropython-lib/blob/master/errno/errno.py

    does anyone knows what this means and what to do with it?



  • @timh
    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.



  • @timh
    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.



  • @milan
    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.



  • @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)[0]
    			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.


  • Global Moderator

    @eric-waai said in OSError: [Errno -1] ERR_MEM:

    ERR_MEM

    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.

    and

    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.

    and

    • 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.


Log in to reply
 

Pycom on Twitter