Skip to content

[code sync] Merge code from sonic-net/sonic-swss:202511 to 202511_azd#252

Merged
mssonicbld merged 2 commits into
Azure:202511_azdfrom
mssonicbld:sonicbld/202511_azd-merge
Jun 28, 2026
Merged

[code sync] Merge code from sonic-net/sonic-swss:202511 to 202511_azd#252
mssonicbld merged 2 commits into
Azure:202511_azdfrom
mssonicbld:sonicbld/202511_azd-merge

Conversation

@mssonicbld

Copy link
Copy Markdown
Collaborator
* 17396300 - (origin/202511) Fix HFTelOrch double-delete of NotificationConsumer on shutdown (#4702) (2026-06-27) [mssonicbld]<br>```

mssonicbld and others added 2 commits June 27, 2026 19:13
<!--
Please make sure you have read and understood the contribution guildlines:
https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md

1. Make sure your commit includes a signature generted with `git commit -s`
2. Make sure your commit title follows the correct format: [component]: description
3. Make sure your commit message contains enough details about the change and related tests
4. Make sure your pull request adds related reviewers, asignees, labels

Please also provide the following information in this pull request:
-->
**What I did**

Fixed a double-delete of the HFTel ASIC `NotificationConsumer` in `HFTelOrch` by aligning ownership with the orchagent `Executor` model.

- Replaced `std::shared_ptr<swss::NotificationConsumer>` with a non-owning `swss::NotificationConsumer*` in `hftelorch.h`.
- Allocate the consumer with `new` and pass it directly to `Notifier` in `hftelorch.cpp` (same pattern as `PortsOrch`).
- On failed `SAI_SWITCH_ATTR_TAM_TEL_TYPE_CONFIG_CHANGE_NOTIFY` registration, delete the `Notifier` and clear the pointer before throwing.
- Updated `doTask(NotificationConsumer&)` to compare against the raw pointer instead of `shared_ptr::get()`.

**Why I did it**

`HFTelOrch` was introduced in `a18824e6` (#3759) with dual ownership: a `shared_ptr` member and a `Notifier`/`Executor` that also deletes `m_selectable` in `~Executor()`. On graceful shutdown, `~HFTelOrch` destroyed the consumer first and `~Orch` destroyed it again, causing SIGSEGV in `redisFree()` during `~NotificationConsumer`.

This was observed on SONiC as repeated orchagent cores during stop/restart. The failure is most visible once full teardown runs (e.g. after graceful SIGTERM/SIGINT shutdown paths such as #4400), but the ownership bug has existed since HFTel was added.

**How I verified it**

- Code review against `orch.h` (`Executor` owns and deletes `m_selectable`) and `portsorch.cpp` (reference ownership pattern).
- `git diff --check` on the changed files (no whitespace issues).
- Prior GDB analysis on DUT: stack showed double `~NotificationConsumer`, `redisFree()`, and `std::_Sp_counted_base::_M_release()`; no SAI failure in `sairedis.rec` at crash time.

Recommended DUT verification (post-build):

1. Confirm HFTel is enabled: `sudo grep -i "High Frequency Telemetry" /var/log/syslog`
2. Stop/restart orchagent repeatedly: `docker exec swss supervisorctl stop orchagent` (or restart `swss`)
3. Confirm no new cores: `ls -lt /var/core/orchagent*.core*`

**Details if related**

- Introduced by: `a18824e6` — [orchagent]: HFTOrch init (#3759)
- Often exposed by: graceful orchagent shutdown / repeated restarts (related: `bd39b131` — [orchagent] Async swss.rec (#4400))
- Scope: `orchagent/high_frequency_telemetry/hftelorch.{h,cpp}` only
- Do not delete the consumer in `~HFTelOrch`; `~Executor` handles it after `addExecutor()`
- Observed: six identical orchagent cores on DUT over ~48 minutes (2026-05-19);

Fixed the issue sonic-net/sonic-buildimage#27464

Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
@mssonicbld mssonicbld requested a review from prsunny as a code owner June 28, 2026 03:03
@mssonicbld mssonicbld merged commit b979b79 into Azure:202511_azd Jun 28, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant