Debug node causing RangeError: Maximum call stack size exceeded

General
1

On a random basis NR crashes with an error caused by a debug node (I suppose).

Attachedd the error that my system log registerd and that cause NR to restart

Jun 4 14:31:55 raspberrypi Node-RED[345]: 4 Jun 14:31:55 - [warn] [debug:Errori rilevati sul flow CAMPIONAMENTO SENSORI] Message exceeded maximum number of catches
Jun 4 14:31:55 raspberrypi Node-RED[345]: 4 Jun 14:31:55 - [error] [debug:Errori rilevati sul flow CAMPIONAMENTO SENSORI] RangeError: Maximum call stack size exceeded
Jun 4 14:32:00 raspberrypi Node-RED[345]: 4 Jun 14:32:00 - [info] [mqtt-broker:MQTT con TLS] Disconnected from broker: xxxxx@mqtts://mysite.com:8883
Jun 4 14:32:01 raspberrypi Node-RED[345]: 4 Jun 14:32:01 - [red] Uncaught Exception:
Jun 4 14:32:01 raspberrypi Node-RED[345]: 4 Jun 14:32:01 - TypeError: Cannot read property 'handleError' of undefined
Jun 4 14:32:01 raspberrypi Node-RED[345]: at Object.Node.error (/usr/lib/node_modules/node-red/node_modules/@node-red/runtime/lib/nodes/Node.js:276:30)
Jun 4 14:32:01 raspberrypi Node-RED[345]: at Socket. (/home/pi/.node-red/node_modules/node-gpsd/lib/gpsd.js:64:37)
Jun 4 14:32:01 raspberrypi Node-RED[345]: at emitOne (events.js:116:13)
Jun 4 14:32:01 raspberrypi Node-RED[345]: at Socket.emit (events.js:211:7)
Jun 4 14:32:01 raspberrypi Node-RED[345]: at addChunk (_stream_readable.js:263:12)
Jun 4 14:32:01 raspberrypi Node-RED[345]: at readableAddChunk (_stream_readable.js:246:13)
Jun 4 14:32:01 raspberrypi Node-RED[345]: at Socket.Readable.push (_stream_readable.js:208:10)
Jun 4 14:32:01 raspberrypi Node-RED[345]: at TCP.onread (net.js:601:20)
Jun 4 14:32:01 raspberrypi systemd[1]: nodered.service: Main process exited, code=exited, status=1/FAILURE
Jun 4 14:32:01 raspberrypi systemd[1]: nodered.service: Unit entered failed state.
Jun 4 14:32:01 raspberrypi systemd[1]: nodered.service: Failed with result 'exit-code'.
Jun 4 14:32:02 raspberrypi systemd[1]: nodered.service: Service hold-off time over, scheduling restart.
Jun 4 14:32:02 raspberrypi systemd[1]: Stopped Node-RED graphical event wiring tool.
Jun 4 14:32:02 raspberrypi systemd[1]: Started Node-RED graphical event wiring tool.

The debug node taht throws the error is connected to a catch node that catches errors within a specifi TAB of my flows (called SENSORI GAS).

Below a snaphot of the nodes (the link node - connected to the catch node - simply send the error to a function that - after clarssifying the type of error decide if it's the case to save it to a local log file for further investigation).

debug node error
debug node error959×241 42.1 KB

I'm trying to understand the reason for this error but I'm completely blind. Can someone drive to me the right direction?

2

It seems like something is causing enough errors to exceed the call stack. The only thing that jumps out from the logs to me is the last line here:

Jun 4 14:32:01 raspberrypi Node-RED[345]: 4 Jun 14:32:01 - TypeError: Cannot read property 'handleError' of undefined
Jun 4 14:32:01 raspberrypi Node-RED[345]: at Object.Node.error (/usr/lib/node_modules/node-red/node_modules/@node-red/runtime/lib/nodes/Node.js:276:30)
Jun 4 14:32:01 raspberrypi Node-RED[345]: at Socket. (/home/pi/.node-red/node_modules/node-gpsd/lib/gpsd.js:64:37)

Do you have some GPS location related node? If you do, could that be the cause?

3

Also which version of Node-RED are you running? I didn't find any reference to the message "Message exceeded maximum number of catches" from Node-RED code base, except from a commit from 2015. The file it was in doesn't even exist in the current version.

4

Yes I've got a gpsd node that get some location info but I don't think it could be cause of the NR restart.

The error happens 6 seconds before the gpsd entry (14:31:55 the "RangeError: Maximum call stack size exceeded" and 14:32:01 the gpsd entry). I think that the RangeError: Maximum call stack size exceeded produced by the debug node "cause" the socket disconnection of the gpsd. So it will be the effect and not the cause.. Don't you?

5

Ah you are probably right as there's also MQTT broker disconnection. Have you gone through rhe flow which errors the catch node is catching?

6

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

7

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+

8

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.)

9

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

10

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

11

As per this post
https://discourse.nodered.org/t/mqtt-node-not-working-after-nr-update/22138
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.

12

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.

13

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.

14

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.

15

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.

16

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

17

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.

18

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?

19

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

20

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.