• Memory is getting written over. In 'C' it's the dreaded missing null line terminator. Used to malloc heapfree etc.

    I guarantee this is not what's happening in JS.

    what is the proper technique to discover a possible memory overrun

    http://www.espruino.com/Reference#l_E_errorFlag

    It'll get called when Espruino's had some difficulty allocating memory. It may not have 100% failed at that point, but it's got close.

    However, if you have problems even without that and you HAVEN'T seen any MEMORY error on the console, it's not an error to do with memory getting used up

  • Sat 2020.03.28

    post #2 'However, if you have problems even without that and you HAVEN'T seen any MEMORY error on the console, it's not an error to do with memory getting used up'

    If I understand the above, I don't appear to have problems as nothing was being displayed, and I 'hadn't' seen a MEMORY error while reducing the file size, but I do now see a New interpreter error: FIFO_FULL error, so not sure if that is inclusive for the above statement.

    Okay, worked all day on this. While I have been extra careful over the last two years to make sure all code is inside separate functions so no execution occurs during upload, I've double checked and verified this is the case, along with making sure nothing other than several vars are initialized, only a function call to display a shortcut list of function call names is rendered. I ripped out many tens of lines of code to get the file size waaay down, so that there were around 600-700 JSVARS available, so as not to run into the ~100 JSVAR minimum that I have read elsewhere that must not be exceeded.

    I issue a reset(1) within the WebIDE. I clear the console, button upper left. Even with now a much smaller code file, now when I just upload that file, a new error appears, but not the MEMORY error mention in the response above.

    I even unplugged the MDBT42Q, in case something corrupt remained, but is consistent, despite nothing I am intentionally doing would be causing a 'FIFO_FULL' error:

    New interpreter error: FIFO_FULL
    >
    

    This error is consitent with what I witnessed yesterday, post #3 with the significantly larger file but during runtime. So, maybe that 'FIFO_FULL' flag has always been there, as I wasn't aware to even detect that until the suggestion in post #2. What is really puzzling is the now 'LOW_MEMORY' flag, despite only using 70% of memory. This actually ran several days ago with only ~200 JSVARS remaining, so with an additional 400 free now, shouldn't be an issue.

    I upload the code file from the Right-hand editor side, and the following is observed, and entering the command, flags can be seen that are set:

    New interpreter error: FIFO_FULL
    >
    
    
    >E.getErrorFlags()
    [
      "FIFO_FULL",
      "LOW_MEMORY"
     ]
    =undefined
    > 
    

    While creating the content for this post, I entered dump() and re-ran a memory check, and now the flags are reset!

    { "free": 667, "usage": 1833, "total": 2500, "history": 602,
      "gc": 0, "gctime": 3.90625, "stackEndAddress": 536928592, "flash_start": 0, "flash_binary_end": 428148,
      "flash_code_start": 442368, "flash_length": 524288 }
    =undefined
    
    
    
    >E.getErrorFlags()
    [  ]
    =undefined
    > 
    



    The new question, what is causing the FIFO_FULL error when just uploading code? I'm not seeing the MEMORY error and there are 600+ JSVARS available, so there shouldn't be a memory issue, correct?

    http://www.espruino.com/Reference#l_E_getErrorFlags
    'FIFO_FULL': The receive FIFO filled up and data was lost. This could be state transitions for setWatch, or received characters.
    'LOW_MEMORY': Memory is running low - Espruino had to run a garbage collection pass or remove some of the command history
    'MEMORY': Espruino ran out of memory and was unable to allocate some data that it needed.

    What is the trip point for low memory as I've stripped 30%+ and still get the flag on upload:

    { "free": 871, "usage": 1629, "total": 2500, "history": 726,
    

    Note that running a forced garbage collection process.memory does clear the flag.

About

Avatar for Gordon @Gordon started