forum

PoltoS wrote: ↑

19 Jan 2024 19:39

Do we have more evidence? Can somebody help us investigate the issue in more details by providing us with the remote access?

Surely there must be SOMEONE of all who reported increasing CPU load with more recent version that can assist the developers to examine this more thoroughly?

As I understand, it was about a SEGV crash caused by http calls in release < 4.0.3? Is that correct? It seems like http calls could trigger the error, in combination with a slow response rate on the remote side. (As for what kind of delay is needed to make it slow enough, I am not sure) And the inc...

I don't see any possibility of reproduction. The occurrence is completely unpredictable. One month it was 5 times, another time nothing in 4 months. It's always the same: SEGV in v8 at the same address. Any chance that the segmentation fault you have been seeing could be the same problem that was d...

alphons wrote: ↑

17 Jan 2023 09:06

I shouldn’t have upgraded from the official v3 to official v4 is all I can say.

The bug that affects async http requests was very much present in v3 too, so upgrading to v4 should not have changed anything in that regard at least.

I had a power outage this morning, so my test session was unfortunately abruptly terminated after ~40 hours of uptime

Until that happened, I have not been able to detect any stability issues. I will restart things tonight and carry on testing.

This is in every possible way extremely exciting news for me! When trying to diagnose the nature of the crash, I was experimenting with adding a buffering scheme in HTTPGet and quickly discovered that buffering requests (and setting a limit on how often they are allowed to be sent) clearly helped re...

I *think* that if you have outgoing HTTP requests, seeing new threads created and exited repeatedly is to be expected. For quite some time I have been logging with gdb due to suspected instabilities when using the HTTPGet module to forward status/level changes of devices. The gdb output you are seei...

You have the mighty z-way-server.log in directory /var/log/
but the output from gdb is what you see in the console window. If the server is crashing, you can list the active threads with:
and then backtrace them one by one through:
That is, IIRC

I have been using gdb to try and diagnose another situation rather than this exact one,
but I had to use sudo on the line that calls gdb in order to make it run:

It will be interested to learn if modifying index.js prevents Z-Way from crashing on your system. If so, the module's logic could be enhanced to have the user configure which devices (or device types) should trigger the HTTP request. Well, judging from an ongoing test, modifying index.js in the man...