There is no practical memory leak.
The cbk_list is a linked list of SMFND_SMFA_ADEST_INVID_MAP nodes. Each node
represents a pending callback (identified by inv_id) waiting for responses from
agents.
How nodes are added:
In the callback send function (~line 362): a node is allocated with calloc and
added to cbk_list head. It stores inv_id and no_of_cbk = agent_cnt.
How nodes are removed (freed):
smfnd_cbk_resp_err_proc(): when an agent responds with error — finds the node
by inv_id, removes it from the list, and calls free().
smfnd_cbk_resp_ok_proc(): when an agent responds OK — decrements no_of_cbk.
When it reaches 0 (all agents responded), removes the node and calls free().
The TODO concern:
When an agent goes DOWN (NCSMDS_DOWN), if that agent had pending callbacks it
never responded to, the no_of_cbk counter will never reach 0, and the node
stays in cbk_list forever — that's the theoretical leak.
Why it's not a practical issue:
- SMF callbacks have a timeout in SMFD. If agents don't respond within the
timeout, SMFD treats it as a failure and the campaign proceeds/fails
accordingly.
- The SMFND process itself is restarted when the node reboots, clearing all
memory.
- The number of pending callbacks at any time is very small (typically 1 per
upgrade step).
- An agent going down mid-callback is an exceptional/rare event.
So, while the TODO is technically correct (orphaned nodes could remain if an
agent dies mid-callback), it's not a real-world memory leak concern since the
entries are few and bounded, and SMFND doesn't run indefinitely without restart
during upgrades.
---
**[tickets:#2727] smf: Smfnd incorrect handling of client list. Possible memory
leek**
**Status:** assigned
**Milestone:** future
**Created:** Mon Dec 04, 2017 11:37 AM UTC by elunlen
**Last Updated:** Fri Sep 06, 2019 03:16 AM UTC
**Owner:** Thanh Nguyen
From TBD in smf node director smfnd_mds.c mds_svc_event()
Need to clean up the cb->cbk_list, otherwise there will be memory leak. For the
time being we are storing only count of agents, not the adest of agents and
hence it is not possible to clean up cbk_list.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
