rticommunity / rticommunity/rticonnextdds-examples
[BUG] memory leak in connext_dds/listeners example
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 148
- Forks
- 153
- PR merge metrics
- No merged PRs in 30d
Description
System information
- RTI Product:
- Version: 7.1.0
- Operating system: Linux
- Compiler: gcc
- Compiler version: 11.0.0
- Additional information:
What is the current behavior?
Memory leak
Steps to reproduce the issue
Compile example examples/connext_dds/listeners
Run publisher and/or subscriber with option -c 2 using valgrind. A memory leak is reported.
Expected behavior
There should not be any memory leak.
Suggested solutions
The problem is that in the publisher
DataWriterListener *writer_listener = new DataWriterListener();
is never released. And in the subscriber
ParticipantListener *participant_listener = new ParticipantListener();
ReaderListener *reader_listener = new ReaderListener();
SubscriberListener *subscriber_listener = new SubscriberListener();
are never released.
Also for consistency, the sub application checks for null pointer after creating the listeners, but the pub application does not check for this. After creating the DW listener we should add the following:
DataWriterListener *writer_listener = new DataWriterListener();
**if (participant_listener == NULL) {
std::cerr << "participant listener instantiation error" << std::endl;
return EXIT_FAILURE;
}**
Note : in the subscriber if the DR listener can not be created the application will terminate gracefully with a memory leak because the participant and the subscriber listeners are not deleted.
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 in examples/connext_dds/listeners and inspect the publisher and subscriber listener creation and termination paths. Run the example with option -c 2 under Valgrind to reproduce the reported leaks, then verify that listener allocations are released on normal and failed-creation paths and that the allocation checks are consistent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, linux
- Domain
- developer-experience
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 58/100