Skip to content

RDKEMW-17520: ctrlm release 1.1.14 #210

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.

Sign up for GitHub

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

Closed
klu339 wants to merge 2 commits into from
Closed

RDKEMW-17520: ctrlm release 1.1.14 #210

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
46afe91
Revert "RDKEMW-16763 : rf4ce init failure causes deadlock (#198)"
klu339 Apr 22, 2026
93f019b
RDKEMW-17520: ctrlm release 1.1.14
klu339 Apr 22, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,12 @@ Generated by [`auto-changelog`](https://github.com/CookPete/auto-changelog).

<!-- auto-changelog-above -->

#### [1.1.14](https://github.com/rdkcentral/control/compare/1.1.13...1.1.14)

> 22 April 2026

- Revert "RDKEMW-16763 : rf4ce init failure causes deadlock (#198)" [`46afe91`](https://github.com/rdkcentral/control/commit/46afe91eebd92de4ae23174d07c4b1f015e618e1)

#### [1.1.13](https://github.com/rdkcentral/control/compare/1.1.12...1.1.13)

> 21 April 2026
Expand Down
28 changes: 2 additions & 26 deletions src/rf4ce/ctrlm_rf4ce_network.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,6 @@
#include <algorithm>
#include <regex>
#include <limits.h>
#include <errno.h>
#include <sys/sysinfo.h>
#include "ctrlm.h"
#include "ctrlm_log.h"
Expand Down Expand Up @@ -412,31 +411,8 @@ ctrlm_hal_result_t ctrlm_obj_network_rf4ce_t::hal_init_request(GThread *ctrlm_ma

// Block until initialization is complete or a timeout occurs
XLOGD_INFO("Waiting for %s initialization...", name_get());
struct timespec timeout;
clock_gettime(CLOCK_REALTIME, &timeout);
timeout.tv_sec += 2; // this operation should complete in under 100 ms under normal circumstances

int sem_result = -1;
do {
errno = 0;
sem_result = sem_timedwait(&semaphore_, &timeout);
if(sem_result == -1 && errno == EINTR) {
XLOGD_INFO("interrupted");
} else {
break;
}
} while(1);

if(sem_result == -1) {
if(errno == ETIMEDOUT) {
XLOGD_ERROR("Timeout waiting for %s initialization", name_get());
} else {
XLOGD_ERROR("Error waiting for %s initialization: %s", name_get(), strerror(errno));
}
init_result_ = CTRLM_HAL_RESULT_ERROR;
} else {
sem_destroy(&semaphore_);
}
sem_wait(&semaphore_);
sem_destroy(&semaphore_);
Comment on lines 412 to +415

Copilot AI Apr 22, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sem_wait() here can block indefinitely if the HAL thread never calls hal_init_confirm() (e.g., init failure, thread creation failure, or missed callback), reintroducing the deadlock scenario this code previously guarded against. Also sem_wait() return value isn’t checked/handled (e.g., EINTR), yet sem_destroy() is called unconditionally. Consider restoring a bounded wait (sem_timedwait with a reasonable timeout + logging) and handling EINTR/other errors, or otherwise guarantee sem_post() occurs on every init path before destroying the semaphore.

Copilot uses AI. Check for mistakes.

ready_ = (CTRLM_HAL_RESULT_SUCCESS == init_result_);

Expand Down
Loading