Valetudo: Memory leak in Valetudo?

I discovered a small issue when using Home-Assistant to Poll the Map too often (every 10 seconds to get a sort of Live map). The /tmp directory filled and the vacuum locked up. A re-boot fixes the issue obviously.

I had done other things on the vacuum in the past so I might have had less space available than normal.

A quick work-around was to throw this into cron */1 * * * * cd /tmp/maps && ls -t /tmp/maps | tail -n +2 | xargs rm --

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 15 (7 by maintainers)

Most upvoted comments

Testing Node 11.12 shows no signs of the leak so I guess https://github.com/nodejs/node/issues/23862 this is the culprit.

Fixed in Node 11.10 https://github.com/nodejs/node/pull/25993

Hypfer on Mar 23, 2019

Tracing the memory leak is a lot harder than I thought. Stumbling blocks:

Debugging on the robot:

the binary output of pkg does not support the --inspect flag
passing the --inspect flag to pkg --options does not work
using memwatch-sigusr2 (depends on memwatch-next) requires crosscompilation (didn’t want to get into that)

Debugging on the host:

usage of the VAC_MAP_TEST env variable was not self explanatory and could not find more documentation. What kind of file do you have to povide? I only found out it’s not a rendered png 😃
Webserver.js needed slight adaptation to use custom paths for the rrlog files (copied from robot) and temp folder. This effectively mocked the robots filesystem and allows to use the regular code paths that create png maps from logfiles (win!).

Using --inspect was finally possible! Using chromiums debugger for stepping/breaking worked and taking heap snapshots as well. I took several snapshots while requesting 100 maps in between. Unfortunately comparing those snapshots is also not as straight forward as I thought. I can see that the heap increases and creates arrays almost linearly with request count but when trying to attribute it to object class names, function names or anything recognizable from the source I failed because It’s all just very generic names in the heap detail view.

Do the devs have any input for me how to debug this properly, what to look for?

axel-kah on Dec 30, 2018

I just rooted my rockrobo v1 with latest firmwarebuilder (FW v11_003194, --disable-xiaomi), dummycloud_0.1 and Valetudo 0.9 via rrcc. I really like the newly gained power over my vacuum but observed the same behaviour as @dugite-code. Basically every map related call increases the memory footprint of Valetudo process.

I did some measurements in a notebook to stress Valetudo by doing the same api call 1000 times in a row. requests was used to interact with Valetudo API and output of ps via paramiko for the process info. The memory footprint steadily increases to up to 60% before the process terminates when triggering a new map with api/remote/map and requesting the png. measurements_trigger_and_read_n_times_2018_12_29_144840

Simply fetching the same png for 1000 times also steadily increases footprint but only by 0.5% points. measurements_trigger_once_read_n_times_2018_12_29_145514

Doing the same for api/map/latest does also increase footprint somewhat. measurements_fetch_latest_n_times_2018_12_29_155024

I don’t have any experience with node.js apps but I’ll try to use the techniques described here to get a clue why the garbage collection fails: https://www.nearform.com/blog/how-to-self-detect-a-memory-leak-in-node/

axel-kah on Dec 29, 2018