esp8266 memory problems

Posted on
Page
of 2
Prev
/ 2
  • When working with Thing Speak, we need to assume that Thing Speak may ignore our HTTP GET request ... when that happens, the lack of the ability to form a connection is not handled by the ESP8266 and it keeps the socket open.

    I do not believe that your statement is correct. If the connection fails you will get a "recon_cb".

  • @Gordon ... In post #24 ... that was a written recap of what I understood in post #21. I am a big one for verbose but less ambiguous wording when it comes to technology discussions. So yes ... #24 was what you said in #21 ...

    The absence of anyone having made a fuss in the past is not an indication that we have quality or correctness now. I'm a big fan of shooting for the best we can possibly do. You are the architect of all ... if you don't feel that there is value in this area then it is up to folks who think otherwise to civilly make their cases for change to ensure that you have all the information you need to make the decisions for or against a change. My data point is that on("error"), is desirous ... it isn't vital (yet) ... but would have relative high priority in the networking work items.

    I changed the error handler in the ESP8266 port to now detect connection failures and in subsequent sends() requests does now indeed return -1 ...

    However ... now I find that causes a problem because I now get:

    ERROR: Socket error -1 while sending
    

    On my console ... but worse ... my app ends because of the exception because I am no-longer able to detect when I should trigger a setTimeout() for the next round ... I would have to have an on("error") handler (or the solution you suggested using the timer .... which I respectfully ... simply don't like).

  • @tve
    Re #26 ... you are 110% correct ... but unfortunately ... so am I. When I wrote the original post, the lack of ability to form a connection WAS indeed not being handled by the ESP8266 (Espruino port).

    Since then, code has been added to the espconn_reconn_cb() via issue #595.

    So ... YES ... handling a lack of connection CAN be caught in the espconn_reconn_cb() and YES ... at the time of writing ... handling a lack of connection was NOT being handled (but is now).

  • There is a big difference between 'not liking something' and memory leaks, crashes, unexpected resets, etc :)

    I've made an issue for it here and it will get sorted at some point in the future. I just don't know when :)

  • Just to add, continuously rescheduling the same task using a setTimeout is (IMO) a bad idea for embedded things. What happens if something you didn't expect causes an exception? The whole thing will stop. It doesn't have to be network-related at all.

    IMO something like this is a lot more straightforward.

    var inProgress = false;
    function doStuff() {
      if (inProgress) console.log("Last transaction failed...");
      inProgress = true;
      http.get(..., function() {
        inProgress = false;
      });
    }
    setInterval(doStuff, 60000);
    

    Although as you noted earlier it only really works if the period is greater than the socket timeout.

    Also, the socket error printed to the console will almost certainly have come from idle processing, and won't affect the execution of any code. It just means your handler won't get called.

  • In my ideal world we would move to promises rather than callbacks wherever possible and especially in network libraries. I expect that's a huge task though. I am planning though to rewrite for my own purposes the ESP8266 module with promises, probably using promiscuous library although it would be good to hear any opinions on good, small promise libraries. I haven't yet tested any with Espruino.

  • @Gordon I was thinking about the timer workaround ... imagine that a http.get() request is made to a back-end and fails (silently) because there is no callback to say that the network connect request itself failed ... One suggestion was to have a cancel able JS level timer that if not cancelled, would indicate that we had failed to connect ... Imagine that the timer was in fact called ... in our timer callback code we now know we are here because a connect request has failed ... what should we then do? What remediation is possible at the JavaScript level to clean up the internals of todays Espruino? Experience seems to show that I am looping in calls to transmit (to transmit the request).

  • I'm not sure, how is this workaround working. The setTimeout runs timeout, but the http.get need to be wayted, while it calls the callback. But if we are there, then something is happend, whay it is called the callback, and if the callback called after 10 minutes, it will wait 10 minutes.
    And I cannot se, where this errTimeout kill the original http call/socket, if timed out.

  • I put this workaround into the code, and its the same...

    sendTsStart
    { "free": 179, "usage": 844, "total": 1023, "history": 38 }
    ERROR: Out of Memory!
    WARNING: Unable to create string as not enough memory
    WARNING: Unable to create string as not enough memory
    WARNING: Unable to create string as not enough memory
    WARNING: Unable to create string as not enough memory
    Execution Interrupted
    
  • There is no need to free memory or 'clean up the internals of Espruino', because if the socket times out then it's a socket error, which should be reported by sending -1 from the ESP8266 drivers, and Espruino will then see the error and automatically free everything.

    It only doesn't do that right now because the ESP8266 port is broken. When it is fixed the problem will go away.

    Look at it this way: Right now, if Espruino gets an error reported on the socket it frees everything automatically. Sure, it doesn't report the error to your code, but everything gets freed. It's broken right now because it's not getting told there's a socket error.

    So suppose I spend time and add this error reporting code you want? It won't work on ESP8266 right now because ESP8266 isn't reporting the error back to Espruino.

    There's absolutely no point me doing it until the ESP8266 port is working as it should... but then when it's working nobody will have this problem any more and the urgency will go away.

  • @Kolban What do you think when can U correct this problem?

    @Gordon if it is help, to handle the error I think there is a good idea (and it will be usable later too), so we can handle or ignore depends of the application.

    Thanks HyGy

  • @hygy
    When last we exchanged correspondence, you had provided me a sample which, when run for a couple of hours crashed. I was able to run the sample sample and mine too crashed after periods of time. As I dug deep into this, I found that, on occasion, the HTTP call to thingspeak failed in the GET request. That is ok ... that should be a potential occurrence. However, the Espruino port to the ESP8266 was doing something bad. It was ignoring the notification that the HTTP request connection had failed and keeping ESP8266 resources locked up. Since the poor old ESP8266 running Espruino has so little RAM to start with, a couple of such failures and we quickly ended up out of memory.

    As part of Issue #595, we added a detection of a failure to form a connection and associated cleanup. What that means is that when an HTTP request to a partner fails, ESP8266 will now detect that occurrence AND release the Espruino/ESP8266 resources.

    Any build north of 2015-11-14 should contain the fix.

  • Great, thanks @Kolban!

    With the HTTPS stuff (see the other thread) I'll hopefully get the async connect stuff added (I still have to figure out a nice way of handling it) and that should help simplify the ESP8266 side.

    Do you currently handle name resolution as part of the connection? If not, I'd hold off doing that. Hopefully the async changes will make that a lot easier too.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

esp8266 memory problems

Posted by Avatar for hygy @hygy

Actions