Skip to content

Add missing trainprogram destructor to fix resource leaks - #4573

Closed
Qhilm wants to merge 2 commits into
cagnulein:masterfrom
Qhilm:fix/trainprogram-destructor
Closed

Add missing trainprogram destructor to fix resource leaks#4573
Qhilm wants to merge 2 commits into
cagnulein:masterfrom
Qhilm:fix/trainprogram-destructor

Conversation

@Qhilm

@Qhilm Qhilm commented Apr 22, 2026

Copy link
Copy Markdown
Contributor

Problem

The trainprogram class was missing a destructor, causing memory leaks:

  • zwift_auth_token (allocated at line 38 with new)
  • zwift_world (allocated at line 635 with new)
  • h (lockscreen pointer, allocated at line 642 with new)
    These are heap-allocated resources that were never freed, leading to memory leaks on every trainprogram object destruction.

Root Cause

The trainprogram class follows the RAII pattern but was missing the destructor to clean up heap-allocated resources.

Solution

Add a destructor that properly deletes the heap-allocated members:

  • delete zwift_auth_token;
  • delete zwift_world;
  • delete h;
    The pelotonOCRsocket is already properly parented to the trainprogram object via new QUdpSocket(this), so Qt's parent-child mechanism will clean it up automatically.

Changes

  • src/trainprogram.h - Add destructor declaration ~trainprogram();
  • src/trainprogram.cpp - Add destructor implementation with proper delete statements

The trainprogram class was missing a destructor, causing memory leaks:
- zwift_auth_token (allocated at line 38 with new)
- zwift_world (allocated at line 635 with new)
- h (lockscreen pointer, allocated at line 642 with new)

These are heap-allocated resources that were never freed, leading to memory leaks
on every trainprogram object destruction.

Fix: Add destructor that properly deletes these members before object destruction.

The pelotonOCRsocket is already properly parented to the trainprogram object via
new QUdpSocket(this), so Qt's parent-child mechanism will clean it up.
@cagnulein

Copy link
Copy Markdown
Owner

This is true only when you create a new program or loading a new one. It should be negligible for regular session. What do you think?

I'm saying so because it's always hard to test if a patch is fine or not even if it seems safe

@Qhilm

Qhilm commented Apr 22, 2026

Copy link
Copy Markdown
Contributor Author

I agree with you on both points: It's a very rare memory leak and it's impossible to properly test.

Up to you. I like tidy code, but I have a slight OCD ;)

@cagnulein

Copy link
Copy Markdown
Owner

Me too :) but I learned that 2 minutes of easy work can value a lot of headaches in the future 😂

@stale

stale Bot commented May 12, 2026

Copy link
Copy Markdown

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale Bot added the wontfix This will not be worked on label May 12, 2026
@stale stale Bot closed this May 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wontfix This will not be worked on

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants