Actions (particularly ExecuteProcess) exist indefinitely
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 155
- Forks
- 182
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 6
Description
Bug report
Required Info:
- Operating System:
- Ubuntu 20.04
- Installation type:
- both
- Version or commit hash:
- foxy
- DDS implementation:
- fastrtps
- Client library (if applicable):
- launch
Steps to reproduce issue
I have created a wrapper around the LaunchService which can dynamically add new Nodes and/or shutdown existing nodes.
New nodes are dynamically added by calling LaunchService.include_launch_description during runtime.
Nodes are stopped by emitting a ShutdownProcess event.
Expected behaviour
After ShutdownProcess, the node exits and the Node/ExecuteProcess object is destroyed.
Actual behavior
I observed that the Node (ExecuteProcess) object is not destroyed until the LaunchService completely shutdown. This is also the case if the node exits on it's own (without a ShutdownProcess event).
Additional information
The result is a small memory leak. Which stacks up in my use case of long lived LaunchService.
I looked at LaunchService._prune_and_count_entity_future_pairs where the Action is removed from entity_future_pairs. The Action is indeed pruned. However there are still ~18 references to it in event handlers.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at LaunchService._prune_and_count_entity_future_pairs and inspect the event-handler references that remain after an Action is removed from entity_future_pairs. Reproduce dynamic node shutdown and natural process exit in a long-lived LaunchService, then verify the Node or ExecuteProcess object can be released before the service itself shuts down.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100