-
Notifications
You must be signed in to change notification settings - Fork 593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(mme): Fixed memory leaks observed during network initiated dedicated bearer deactivation procedure #8417
fix(mme): Fixed memory leaks observed during network initiated dedicated bearer deactivation procedure #8417
Conversation
Thanks for opening a PR! 💯 A couple initial guidelines
Howto
More infoPlease take a moment to read through the Magma project's
If this is your first Magma PR, also consider reading
|
Oops! Looks like you failed the Howto
|
Oops! Looks like you failed the Howto
|
@rsarwad can you please add into the Summary the dump of the memory leak? it would help for tracing back exact leak output on the logs, thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Oops! Looks like you failed the Howto
|
1 similar comment
Oops! Looks like you failed the Howto
|
feg-workflow 2 files 145 suites 30s ⏱️ Results for commit 89101dc. ♻️ This comment has been updated with latest results. |
Oops! Looks like you failed the Howto
|
Oops! Looks like you failed the Howto
|
@rsarwad could you fix the commit title inline with the PR title as it is a single commit PR, commit title is expected to follow semantic rules as well. |
07462e8
to
a762755
Compare
Oops! Looks like you failed the Howto |
…ted bearer deactivation procedure Signed-off-by: Rashmi <rashmi.sarwad@radisys.com>
a762755
to
89101dc
Compare
fix(agw): Fixed memory leaks observed during network initiated dedicated bearer deactivation procedure
Summary
Inconsistently memory leak was observed during execution of test_attach_detach_dedicated_deactivation_timer_expiry.py
Cause for leak is, on first timer timer expiry, mme shall start the timer with some arguments, for which memory would be allocated. So part of start, if timer has valid timer id then first timer is stopped and started again. As part of stop, it returns the memory allocated for timer arguments.
Since timer has expired, timer id will not be found in the timer queue, so timer argument returned from stop was corrupted/incorrect. When start the timer again; it was not starting. Since it was not started, it was resulting into memory leak.
Memory allocated to timer argument would be freed, either on final timer expiry or while stopping using api, esm_ebr_stop_timer()
Below is the back trace where memory leak was observed,
Test Plan
Executed s1ap sanity test suite
Executed test_attach_detach_dedicated_deactivation_timer_expiry.py test case and stopped all services to check memory leaks. This is repeated multiple times.
Signed-off-by: Rashmi rashmi.sarwad@radisys.com