Debug node causing RangeError: Maximum call stack size exceeded

I'll try to look at the errors the catch node is "cathing" - when it will occur again - in order to understand the cause.

Sorry but I skipped this post

Below the NR and node.js versions

Jun 4 07:17:27 raspberrypi Node-RED[27453]: 4 Jun 07:17:27 - [info] Node-RED version: v0.20.7
Jun 4 07:17:27 raspberrypi Node-RED[27453]: 4 Jun 07:17:27 - [info] Node.js version: v8.16.0
Jun 4 07:17:27 raspberrypi Node-RED[27453]: 4 Jun 07:17:27 - [info] Linux 4.19.57-v7+ arm LE

Running on a RASP Pi 3B+

the current release of NR is v1.0.6 and v1.1.0 should be out in the next couple of months.

Can you upgrade? (I would suggest backing up your SD card before doing the upgrade.)

What exactly is the catch set to catch ? All errors or just some nodes. It does look like a node is sending a cascade of errors and blowing the stack. At a glance it looks like that gpsd node has lost a connection and may be in a retry spin. But hard to tell

The catch node is configure in order to catach the errors coming from all the nodes in the tab (configuration below)
catch node configuration

As per this post
some time ago I tried to update my NR installation but after updating I had an error with the MQTT client and had to switch back to v.0.20.07. Anyway - after solving this NR restart issue - I'll try to update NR again and see if everything will work as expected.

Looking at the other post it looks like you are using docker, is that still true? If so, that is something you should mention right off the bat, even putting it in the topic.

Unfortunately, not having ever used docker, I'm not going to be of much help.

No. I'm using a classic installation on Raspberry. The reference to a NR running on docker was only a test in order to check the correct functionality of my current MQTT Broker.

Ok, in that case change the catch node to only catch errors from the mqtt node to see if that is where the problem is coming from.

The problem causing the "RangeError: Maximum call stack size exceeded" is not related to the MQTT client. The MQTT client works correctly wiyh my current setup (NR v 0.20.07) and the MQTT in and out nodes are outside the TAB where the catch node (getting the errors and so causing NR to restart) is placed.

So what are the other nodes on that tab? Can you provide the flow?

One of the nodes appears to be flooding the system with errors that overwhelm the catch node. You cannot be sure that it is not the mqtt node. As far as I can see the solution is to limit which nodes the catch node is configured to catch, and home in on which one it is. I would start by checking any contrib nodes on the tab, it is more likely to be one of those than a core node, just because they are used a lot less.

Sorry Colin but I didn't get your point.
The catch node that throws me the error and restart NR is "within" the TAB "x". In the TAB "x" there is not any MQTT node....How is it possible that the catch node in the TAB "x" catches errors coming from another TAB (i.e TAB "y"). As far as I know is not possible. So why do you presume that one ore more MQTT nodes (that are in TAB "y") may causing this error?

It's a quite complex TAB with tons on nodes. Anyway I've logged on a file all the errors catched by the "catch" node of the TAB in order to understand which node/s generates the errors that flood the debug node and make NR cash and restart. I'll keep you up-to-date

I didn't realise there aren't any on that tab. If there aren't any then obviously it isn't one of them :slight_smile: I don't think you had previously mentioned that.

I also hadn't realised that you are able to see the errors. I presumed it was flooding so rapidly that the debug node never got a chance to show anything. Again I don't think you had mentioned that you are seeing errors caught.

I've implemented the log on a file just for debug purposes after the NR restart happened. I really don't know if I will be able to get/see te errors cathed by the catch node..I hope so in order to understand the NR restart cause :slight_smile:

If it happens to be connectivity related, maybe you can "speed things up" by disconnecting the Pi's ethernet/wifi?

Unfortunately the radnom restart happend again but I didn't find any writing in the log file I've created.
The strange think is that the error in the syslog is always the same but I didn't get any entry in my personal log file. If - in the syslog file, the debug node throws an error saying that that it received a large number of message that it cannot manage (if I've understood what is behind the error message) I cannot really understand why another node connected to the same "catch" node and taht writes on a local file didn't wrute anything on that file..

Jun 6 15:17:58 raspberrypi Node-RED[10142]: 6 Jun 15:17:58 - [warn] [debug:Errori rilevati sul flow CAMPIONAMENTO SENSORI] Message exceeded maximum number of catches
Jun 6 15:17:58 raspberrypi Node-RED[10142]: 6 Jun 15:17:58 - [error] [debug:Errori rilevati sul flow CAMPIONAMENTO SENSORI] RangeError: Maximum call stack size exceeded

I'm surely missing something....Any clues?

It's difficult to say anything without knowing how you have set the logging up / without seeing your flow. Could you export and share it? Read this first if you haven't yet:

Unfortunately, the node that writes on a local file is located in another tab so I cannot share the json flow file. Anyway I've now put a delay node (configure as a "rate limit") between the catch node and the debug node (that throws me the "maximum call stack size exceeded" error).
I can share the json file of this new configuration (that is really basic).

[{"id":"2759c1fb.04553e","type":"debug","z":"a6dfd68e.7bd928","name":"Errori rilevati sul flow CAMPIONAMENTO SENSORI","active":true,"tosidebar":true,"console":false,"tostatus":true,"complete":"error","x":1380,"y":140,"wires":[]},{"id":"57c5d207.5f6c6c","type":"catch","z":"a6dfd68e.7bd928","name":"Errrori rilevati dal flow \"CAMPIONAMENTO SENSORI\"","scope":null,"x":668.3333740234375,"y":138.33334350585938,"wires":[["26e607ac.208b58"]]},{"id":"26e607ac.208b58","type":"delay","z":"a6dfd68e.7bd928","name":"","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":true,"x":990,"y":140,"wires":[["2759c1fb.04553e","eb0b8bf0.dc641"]]}]

In this way any message collected by the catch node will be slow down and go to the debug node at a rate of 1 msg every second.

I'll leave it in test for some day and see it this fix the error.