Interval Stopping Unexpectedly After Running for Some Time (using MDBT42Q breakout, fw 2v01)

After running for some time (a few weeks or so) the interval set with setInterval() and modified periodically with changeInterval() will unexpectedly stop. Interval periods are set between 1000ms and 100ms. When I connect to the device I try to use changeInterval() on the console and get "Uncaught Error: Unknown Interval" so it appears the interval is gone, as if clearInterval() was called. I checked to see if that could be the case and am not seeing anything. Is there a reason why the an interval would stop except calling clearInterval()? Is there a max time an interval can run?

I would say check your, and all libraries for clearInterval.
A clearWatch in DHT22 cleared all my watches. It's a different command, but similar behaviour and effects... And a related conversation .

It's really likely that clearInterval got called with undefined as an argument as @AkosLukacs says.

If you install the 2v03 firmware then I've changed the way it works, so if you call clearInterval(undefined) rather than just clearInterval() then it'll throw an exception.

What you can then do is either leave a PC connected to the serial port of the MDBT42Q logging what it outputs, or you can log it to RAM:

var log="";
LoopbackB.on('data',d=>log+=d);
NRF.on('disconnect', function(reason) { LoopbackA.setConsole(); });

Now when you disconnect all outputs get logged to log. When you reconnect you can just run print(log) to see what got printed - and if there was an exception then it'll be in there along with a stack trace of where it occurred.

Thank you both for the reply. I read your other conversation regarding clearWatch() and agree with the suggestions. I'll also try @Gordon error logging suggestion using both 2v01 and 2v03 firmware versions. Will post back if I discover anything.

Update: I ran a similar script on a pixljs and could see the error when in a state running a high-frequency interval. I'm guessing the interval is too frequent causing a backlog of operations and resulting in a low memory error. I will try increasing the interval period and re-running the test.

1 Attachment

Great - at least that's some help.

You could try printing process.memory().usage every so often to see if there's some kind of leak that gets worse over time?

Thanks for the tip. I ran some experiments with different intervals and I did see the memory usage increase from 219 to 254 when reducing the interval from 2000ms to 200ms and vice-versa saw the memory use decrease when increasing the interval, so I think this is a helpful tool to determine what the fastest interval can be.

If you need to you can actually look in global["\xff"].timers to see what intervals are running - might be some help?

For the 'out of memory' problem you should hopefully see the memory usage keep rising over time as well.