How to determine which setWatch callback function triggers the E.getErrorFlags() CALLBACK error

Mon 2020.03.30

A new flag has appeared, 'CALLBACK'

[
  "CALLBACK",
  "LOW_MEMORY",
  "MEMORY"
 ]

https://www.espruino.com/Reference#l_E_getErrorFlags

'CALLBACK': A callback (setWatch, setInterval, on('data',...)) caused an error and so was removed

When I attempt to view memory free at this point, I'm faced with another issue,

=undefined
>process.memory()
Execution Interrupted
> 

Instead of reporting back, the WebIDE is locked up at this point. I've viewed WebIDE :: Settings >> Console and am able to verify that the keypresses aren't being sent through, which makes sense as they don't show in the console either.

I also note that the low level peripherals still output pulses, so am unable to control the device at this point. I made mention of the suggestion/ability to reset these in post #12 three weeks ago:

post #9 - #12 Tutorial example output anomaly using low level access PPI on MDBT42Q breakout board

Disconnecting the WebIDE and then powering down the device are the only ways I've discovered to get back access.

There doesn't appear to be many forum responses for the CALLBACK flag with E.getErrorFlags()

What methods may be employed to determine which callback causes the error flag to be set?

Try stripping your code back until you get just that error.

Normally, when something like that happens there'll be a stack trace written to the console, but it's possible you are executing code on upload, and it's that code which is causing the issue.

A new flag has appeared, 'CALLBACK'

It appeared because I imagine you modified code such that a callback function caused an error.

Although sometimes it happens if you Ctrl-C out of a function that's executing a lot in the background.

Tue 2020.03.31

'Try stripping your code back until you get just that error'

As I did that, that particular CALLBACK error goes away. Hoping that might give a clue here.

'but it's possible you are executing code on upload'

No, making sure all code lines are within functions. Occurs during runtime setInterval.

'Normally, . . . there'll be a stack trace written to the console'

Well, I guess this isn't normal. A few console.log lines that I expected did occur, then just that output before the next interval ticked off.

'I imagine you modified code such that a callback function caused an error'

Yes, I stripped out all console.log statements within a setWatch under the assumption this was a timing or update to the console delay issue, and I removed any single line comments used for debug notes inside that function, in order to free up JsVars. I find it a bit of a stretch to think it is that one, after doing all that, but the wonderment still exists, how to distinguish.

'sometimes it happens if you Ctrl-C out of a function'

Okay, makes sense, but didn't do that in this case.

Any other ideas, tips, suggestions to narrow down to which of the three? I'll continue to parse clean up, as I have no other right now.

At this point, adding back in console.log statements is the only idea I could come up with. I also noticed that I had 600+ JsVars before I started to run individual functions. As soon as the setWatch was assigned, that dropped down to 47. Did a simple memory check with a text line such as "abcdef..." out to 216 chars. Under the assumption 12 JsVars, that string would use 18 JsVars plus a bit of overhead for the var name and function wrapper. In this case 550 JsVars got used up, somehow. 550 x 12 = 6600 chars! But, there just aren't that many inside any of the setWatch functions.

Does this seem a reasonable (6600 seems exsessive to me) number just creating/adding the setWatch to the environment? Do any called functions inside the setWatch have to be re-added in to that total?

I remember elsewhere (two years ago and can't locate in forum) that 100 JsVars was a minimum needed for execution overhead, plus what ever arrays/vars were in use. To upload, the total number of bytes, times two to allow for unpacking/parsing plus some large margin, divided by 12 or 16 maybe, is a really rough estimate of what has to be on hand before an upload should start. Am I remembering that correctly?

Wed 2020.04.01

Could this concept be a potential cause?

I plucked out several hundred lines more, and now have ~1000 JsVars available.

My analogWrite function spits out ~4-16 pulses, to which a setWatch responds.

Consistently, I now get this error, despite not typing in 'Ctrl + C' myself

ERROR: Ctrl-C while processing interval - removing it.
Execution Interrupted during event processing.
New interpreter error: CALLBACK,MEMORY

>
{ "free": 82, "usage": 2418, "total": 2500, "history": 11

Here is my observation and question.

When writing the callback for the setWatch, my (human) memory model creates a RAM map that has one area that contains the condensed function code, and only one instance of that code to execute.

During runtime, when the callback is tripped several times, the amount of free space drops seriously, as in the above case, and in other attempts mentioned in other threads.

Q: Does the act of tripping the setWatch force a new linked area of RAM, thereby gobbling up that space? Also note that gabage collection ceases to be available at that point, and re-uploading or powereing off the device are the only options.

@Gordon, is this how callbacks use RAM?

Ctrl-C while processing interval - removing it.

Did you Ctrl-C? If not, it's likely the IDE realising that the device is locked up (probably handling the analogWrite) and creating one for you.

If that's the case then you're executing code on upload, which would explain a lot of your issues. It's something that's come up a lot on questions that you have asked in the past, so might be the same again here.

My analogWrite function spits out ~4-16 pulses

Do you have an oscilloscope? I bet you'll find it's a lot more than that - analogWrite just keeps going.

Most likely even if you think you are stopping it using setTimeout, the sequence of pulses comes so fast that Espruino becomes occupied handling them and can't execute the setTimeout to turn them off.

Does the act of tripping the setWatch force a new linked area of RAM

No, it doesn't. It shouldn't use RAM (unless your code inside it allocated something)

Wed 2020.04.01

'Did you Ctrl-C?'
'then you're executing code on upload'

Although I didn't explicitly say, the sentence right above the error in post #4 does indicate that I didn't issue the 'Ctrl + C' implying it is a runtime situation.

'Do you have an oscilloscope? I bet you'll find it's a lot more than that'

I'll gladly take your money!! I have slowed the frequency so I am able to count pulses as I mentioned in the other thread. Triggering on that isn't showing any more that what is intended to be sent. I stopped using the logic analyzer after many tests showed that step was just time consuming, and was only validating the visible scope output.

Is there an 'assert' function to detect out of bounds conditions as in 'C'?

https://developer.mozilla.org/en-US/docs/Web/API/console/assert

Initial searching implies there isn't as only the 'log()' function is listed within the class description.

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

Is there an 'assert' function to detect out of bounds conditions as in 'C'?

No... But you can just add console.assert = function(x){if(!x) throw new Error("Assert Failed")}; and job done

Thr 2020.04.02

Thank you for that confirmation Gordon. While I had substituted a conditional test along with 'throw'ing my own formatted error, I wanted to make sure from a message bubble up procedure standpoint, that the assert feature didn't already exist.

Note to those overriding as in the example above, that the procedural handling will be slightly different than what MDN explains at the link in #6 post above.

EDIT:   Sun 2020.04.19
Found a method to capture unhandled exceptions:
http://www.espruino.com/Reference#l_process_uncaughtException