Closed randoms closed 2 years ago
Thank you @randoms ! I have a question. How can you check the memory leak?
Run audio play and send audio message to the node. Find its pid, for example 12345, run the following command to view memory usage.
watch -n 1 "cat /proc/12345/status | grep VmRSS"
And you will find memory is running up slowly. I found this issue on my robot working for several days. audio play node ate up over 50% memory of my robot.
Hmm, I tried, but in my environment, #206 does not solve the issue properly. VmRSS is getting larger and larger.
I checked with valgrind --tool=memcheck
$ roslaunch audio_play play.launch
... logging to /home/shingo/.ros/log/8b19ff44-3d40-11ed-9837-d05099c29feb/roslaunch-ecublens-4942.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://133.11.216.78:38087/
SUMMARY
========
PARAMETERS
* /audio_play/channels: 1
* /audio_play/device:
* /audio_play/do_timestamp: False
* /audio_play/dst: alsasink
* /audio_play/format: mp3
* /audio_play/sample_format: S16LE
* /audio_play/sample_rate: 16000
* /rosdistro: kinetic
* /rosversion: 1.12.15
NODES
/
audio_play (audio_play/audio_play)
ROS_MASTER_URI=http://pr1040:11311
process[audio_play-1]: started with pid [5060]
==5060== Memcheck, a memory error detector
==5060== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5060== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==5060== Command: /home/shingo/ros/kinetic/devel/lib/audio_play/audio_play audio:=audio __name:=audio_play __log:=/home/shingo/.ros/log/8b19ff44-3d40-11ed-9837-d05099c29feb/audio_play-1.log
==5060==
^C[audio_play-1] killing on exit
==5060==
==5060== HEAP SUMMARY:
==5060== in use at exit: 3,320,449 bytes in 29,304 blocks
==5060== total heap usage: 74,506 allocs, 45,202 frees, 3,388,729,989 bytes allocated
==5060==
==5060== LEAK SUMMARY:
==5060== definitely lost: 33,792 bytes in 65 blocks
==5060== indirectly lost: 138,537 bytes in 63 blocks
==5060== possibly lost: 53,450 bytes in 1,470 blocks
==5060== still reachable: 2,977,718 bytes in 27,280 blocks
==5060== of which reachable via heuristic:
==5060== length64 : 7,736 bytes in 185 blocks
==5060== newarray : 1,664 bytes in 24 blocks
==5060== suppressed: 0 bytes in 0 blocks
==5060== Rerun with --leak-check=full to see details of leaked memory
==5060==
==5060== For counts of detected and suppressed errors, rerun with: -v
==5060== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
shutting down processing monitor...
... shutting down processing monitor complete
done
$ roslaunch audio_play play.launch
... logging to /home/shingo/.ros/log/8b19ff44-3d40-11ed-9837-d05099c29feb/roslaunch-ecublens-20723.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://133.11.216.78:37307/
SUMMARY
========
PARAMETERS
* /audio_play/channels: 1
* /audio_play/device:
* /audio_play/do_timestamp: False
* /audio_play/dst: alsasink
* /audio_play/format: mp3
* /audio_play/sample_format: S16LE
* /audio_play/sample_rate: 16000
* /rosdistro: kinetic
* /rosversion: 1.12.15
NODES
/
audio_play (audio_play/audio_play)
ROS_MASTER_URI=http://pr1040:11311
process[audio_play-1]: started with pid [20983]
==20983== Memcheck, a memory error detector
==20983== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==20983== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==20983== Command: /home/shingo/ros/kinetic/devel/lib/audio_play/audio_play audio:=audio __name:=audio_play __log:=/home/shingo/.ros/log/8b19ff44-3d40-11ed-9837-d05099c29feb/audio_play-1.log
==20983==
^C[audio_play-1] killing on exit
==20983==
==20983== HEAP SUMMARY:
==20983== in use at exit: 4,946,231 bytes in 31,321 blocks
==20983== total heap usage: 84,254 allocs, 52,933 frees, 3,396,926,425 bytes allocated
==20983==
==20983== LEAK SUMMARY:
==20983== definitely lost: 16,384 bytes in 1 blocks
==20983== indirectly lost: 0 bytes in 0 blocks
==20983== possibly lost: 51,728 bytes in 1,483 blocks
==20983== still reachable: 4,761,167 bytes in 29,411 blocks
==20983== of which reachable via heuristic:
==20983== length64 : 7,736 bytes in 185 blocks
==20983== newarray : 1,664 bytes in 24 blocks
==20983== suppressed: 0 bytes in 0 blocks
==20983== Rerun with --leak-check=full to see details of leaked memory
==20983==
==20983== For counts of detected and suppressed errors, rerun with: -v
==20983== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
shutting down processing monitor...
... shutting down processing monitor complete
done
The number of definitely lost
is now much lesser!
audio play node called
gst_buffer_new_and_alloc
to allocate buffer here, but not unref the buffer later.Add
gst_buffer_unref
can fix this issue.