Skip to content

Add L1 test coverage for getCPUInfo matching/parsing logic#325

Draft
Copilot wants to merge 25 commits intosupport/1.8from
copilot/sub-pr-322
Draft

Add L1 test coverage for getCPUInfo matching/parsing logic#325
Copilot wants to merge 25 commits intosupport/1.8from
copilot/sub-pr-322

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Apr 13, 2026 •
edited
Loading

The getCPUInfo function's case-insensitive name matching, PID fallback, and direct-file-read path introduced in #322 had no unit test coverage, leaving those branches unprotected against regressions across different top output formats.

New tests (dcautilTest.cpp)

Six fixture-based tests added under #if !defined(ENABLE_RDKC_SUPPORT) && !defined(ENABLE_RDKB_SUPPORT):

  • getCPUInfo_DirectFileRead_NameMatch – file accessible via access(); line matched by process name
  • getCPUInfo_DirectFileRead_CaseInsensitiveMatch – same path; TELEMETRY2_0 matches telemetry2_0 via strcasestr
  • getCPUInfo_DirectFileRead_PidFallback – name absent from line; matched via pInfo->pid[0]
  • getCPUInfo_Popen_NameMatch – popen path (NULL filename); name match
  • getCPUInfo_Popen_PidFallback – popen path; PID fallback
  • getCPUInfo_Popen_NoMatch – neither name nor PID match; asserts return value is 0

Each test drives getCPUInfo directly using mocked fgets lines representative of real top -b -n 1 output, e.g.:

// PID fallback: line has no process name but PID matches pInfo->pid[0]
const char* test_line = "2268 root 20 0 831m 66m 20m S 27.0 1.3 491:06.82 /usr/bin/foo\n";
// → getCPUInfo parses the line and returns 1

// No match: PID in line (2268) ≠ pInfo->pid[0] (9999), name absent
// → getCPUInfo returns 0

shibu-kv and others added 22 commits March 31, 2026 08:03
@shibu-kv @tabbas651
DELIA-70280: Box boot up time is extended due to Privacy control hangs (
4b333eb 
#305)

* RDKEMW-15927 ,RDKEMW-15007 : [APACA/Xione DE] rbus self-deadlock in XConf privacy mode fetch causing ~188s T2 init delay

Reason for change: When UserSettings sets privacy mode to DO_NOT_SHARE during boot,
the rbus SET handler (t2PropertyDataSetHandler) runs synchronously
on the single rbus callback thread — executing deleteAllProfiles()
with pthread_join, disk I/O, and XConf client restart.

The restarted XConf thread calls appendRequestParams() which uses
getParameterValue(PRIVACYMODES_RFC) to fetch privacy mode. This
issues rbus_get() on T2's own bus handle, requiring the same rbus
callback thread that is already blocked processing the SET handler.
This creates a self-deadlock with a 15s rbus timeout per attempt,
compounded by XCONF_RETRY_TIMEOUT (180s), stalling T2 initialization.

Cascading effect: While T2 is stalled, external callers (e.g.
WPEFramework SystemServices plugin) invoking t2_event_s() block
15s each on rbus_getUint(Telemetry.OperationalStatus), delaying
the dispatch thread by ~188s and blocking sendNotify() for
EVT_ONSYSTEMPOWERSTATECHANGED.

Fix:
- xconfclient.c: Replace getParameterValue(PRIVACYMODES_RFC) with
  direct getPrivacyMode() call from privacycontrol library. The
  platform implementation (provided via meta layer bbappend) reads
  from a local in-memory cache (PRIVACY_STATE), with fallback to
  Thunder JSON-RPC (local HTTP) and persistent storage — none of
  which use rbus, eliminating the self-deadlock.
`
- xconf-client/Makefile.am: Add privacycontrol include path and
  build dependency when IS_PRIVACYCONTROL_ENABLED is set.

- telemetry_busmessage_sender.c: Add fast-fail file marker check
  (T2_COMPONENT_READY) before rbus_getUint() in isCachingRequired()
  to avoid 15s blocking timeout when T2 is not yet ready.
Test Procedure: please refer the ticket comments
Risks: Medium
Signed-off-by: Thamim Razith <ThamimRazith_AbbasAli@comcast.com>

* Addressed the L1 Test cases failure

* RDKEMW-15927, RDKEMW-15007 : [APACA/Xione DE] Fix RBUS handler starvation and race condition on privacyModeVal

Reason for change: When UserSettings sets privacy mode to DO_NOT_SHARE during boot,
the rbus SET handler (t2PropertyDataSetHandler) runs synchronously
on the single rbus callback thread — executing deleteAllProfiles()
with pthread_join, disk I/O, and XConf client restart.

The restarted XConf thread calls appendRequestParams() which uses
getParameterValue(PRIVACYMODES_RFC) to fetch privacy mode. This
issues rbus_get() on T2's own bus handle, requiring the same rbus
callback thread that is already blocked processing the SET handler.
This creates a self-deadlock with a 15s rbus timeout per attempt,
compounded by XCONF_RETRY_TIMEOUT (180s), stalling T2 initialization.

Additionally, privacyModeVal global pointer has no mutex protection,
allowing use-after-free and NULL dereference under concurrent
SET/GET operations during stress scenarios.

Cascading effect: While T2 is stalled, external callers (e.g.
WPEFramework SystemServices plugin) invoking t2_event_s() block
15s each on rbus_getUint(Telemetry.OperationalStatus), delaying
the dispatch thread by ~188s and blocking sendNotify() for
EVT_ONSYSTEMPOWERSTATECHANGED. Under concurrent privacy mode
toggling, PROVIDER_NOT_RESPONDING with 26+ messages queued and
dropped, telemetry events fall back to file caching.

Fix:
- rbusInterface.c: Add privacyModeMutex (PTHREAD_MUTEX_INITIALIZER)
  to serialize all reads/writes of privacyModeVal in SET and GET
  handlers, preventing use-after-free and NULL dereference.

- rbusInterface.c: Add privacyModeCallbackWorker() detached thread.
  The SET handler now validates input, updates privacyModeVal under
  mutex, calls setPrivacyMode() for persistence, then dispatches
  heavy callbacks (mprofilesDeleteCallBack, privacyModesDoNotShareCallBack)
  to the worker thread. RBUS handler returns immediately, preventing
  handler thread starvation and cascading 180s timeout loops.

- xconfclient.c: Replace getParameterValue(PRIVACYMODES_RFC) with
  direct getPrivacyMode() call from privacycontrol library. The
  platform implementation (provided via meta layer bbappend) reads
  from a local in-memory cache (PRIVACY_STATE), with fallback to
  Thunder JSON-RPC (local HTTP) and persistent storage — none of
  which use rbus, eliminating the self-deadlock.

- xconf-client/Makefile.am: Add privacycontrol include path and
  build dependency when IS_PRIVACYCONTROL_ENABLED is set. Add else
  branch for libxconfclient_la_CFLAGS to define the variable in all
  automake conditions, fixing autoreconf failure.

- telemetry_busmessage_sender.c: Add fast-fail file marker check
  (T2_COMPONENT_READY) before rbus_getUint() in isCachingRequired()
  to avoid blocking on rbus timeout when T2 is not ready.

- persistence.c: Change rm -f to rm -rf in clearPersistenceFolder()
  non-LIBSYSWRAPPER path. PRIVACYMODE_PATH is a directory, not a
  file; rm -f fails silently leaving stale persistence data.

Test Procedure: Concurrent stress test with multiple privacy mode toggles
(SHARE/DO_NOT_SHARE via curl JSON-RPC), telemetry marker submissions
(telemetry2_0_client), rbuscli reads, and SIGUSR1 signal — all
running simultaneously in background.
Risks: Medium
Signed-off-by: Thamim Razith <ThamimRazith_AbbasAli@comcast.com>

* Addressed the shibu review comments

* Addressed the empty check on path  on fetchLocalConfigs and clearPersistenceFolder

* Apply suggestion from @Copilot

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Apply suggestion from @Copilot

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Removed the extra space for addressed the style formatting

* Addressed the astyle format issue

* Fix dangling pointer in rbusInterface.c GET handler: call rbusValue_SetString after ownership transfer

Agent-Logs-Url: https://github.com/rdkcentral/telemetry/sessions/d5b743ff-3289-4141-b51a-399971064c4c

Co-authored-by: shibu-kv <89052442+shibu-kv@users.noreply.github.com>

---------

Signed-off-by: Thamim Razith <ThamimRazith_AbbasAli@comcast.com>
Co-authored-by: tabbas651 <thamimrazith_abbasali@comcast.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
@shibu-kv
Changelog updates for hotfix 1.8.5v1
96522ab
@yogeswaransky
BES1-941: Update dcautil.h
36cc492
@yogeswaransky
Update dcaproc.c
5ed035d
@yogeswaransky
Update dcaproc.c
fa217de
@yogeswaransky
Update dcaproc.c
686b55d
@yogeswaransky
Update dcaproc.c
4691dfe
@yogeswaransky
Update dcaproc.c
b61db1a
@yogeswaransky
BES1-941: Update dcaproc.c
166397e
@yogeswaransky
BES1-941: Update dcaproc.c
64b8ebb
@yogeswaransky
BES1-941: Update dcaproc.c
85a438c
@yogeswaransky
BES1-941: Update reportgen.c
dc06b86
@yogeswaransky
BES1-941: Update dcaproc.c
934c31e
@yogeswaransky
RDKEMW-16851: Update dcautil.h
c732533
@yogeswaransky
RDKEMW-16851: Update dcaproc.c
d7703f9
@yogeswaransky
RDKEMW-16851: Update dcaproc.c
8423c8b
@yogeswaransky
RDKEMW-16851: Revert Info log lines to debug log lines
349537a 
Signed-off-by: Yogeswaran K <yogeswaransky@gmail.com>
Initial plan
8640655
@yogeswaransky
Merge remote-tracking branch 'origin/support/1.8' into copilot/sub-pr…
9c62c11 
…-306

# Conflicts:
#	CHANGELOG.md

Co-authored-by: yogeswaransky <166126056+yogeswaransky@users.noreply.github.com>
@yogeswaransky
RDKEMW-16851: Update dcaproc.c
280222b 
Signed-off-by: Yogeswaran K <yogeswaransky@gmail.com>
@yogeswaransky
RDKEMW-16851: Update dcaproc.c
c990e15 
Signed-off-by: Yogeswaran K <yogeswaransky@gmail.com>
Initial plan
13ecfda
Copilot AI mentioned this pull request Apr 13, 2026
Merged
6 tasks
Base automatically changed from copilot/sub-pr-306 to support/1.8 April 13, 2026 13:13
Copy link
Copy Markdown
Contributor Author

Copilot AI commented Apr 13, 2026

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Copilot AI changed the title [WIP] [WIP] Addressing feedback: Add additional L1 test cases for buffer length increase Add L1 test coverage for getCPUInfo matching/parsing logic Apr 13, 2026
Copilot AI requested a review from shibu-kv April 13, 2026 13:26
@shibu-kv
@tabbas651 @yogeswaransky
RDKEMW-16851: Increase Process name buffer length from 16 to 64 (#322) (
0ec0a02 
#330)

* DELIA-70280: Box boot up time is extended due to Privacy control hangs (#305)

* RDKEMW-15927 ,RDKEMW-15007 : [APACA/Xione DE] rbus self-deadlock in XConf privacy mode fetch causing ~188s T2 init delay

Reason for change: When UserSettings sets privacy mode to DO_NOT_SHARE during boot,
the rbus SET handler (t2PropertyDataSetHandler) runs synchronously
on the single rbus callback thread — executing deleteAllProfiles()
with pthread_join, disk I/O, and XConf client restart.

The restarted XConf thread calls appendRequestParams() which uses
getParameterValue(PRIVACYMODES_RFC) to fetch privacy mode. This
issues rbus_get() on T2's own bus handle, requiring the same rbus
callback thread that is already blocked processing the SET handler.
This creates a self-deadlock with a 15s rbus timeout per attempt,
compounded by XCONF_RETRY_TIMEOUT (180s), stalling T2 initialization.

Cascading effect: While T2 is stalled, external callers (e.g.
WPEFramework SystemServices plugin) invoking t2_event_s() block
15s each on rbus_getUint(Telemetry.OperationalStatus), delaying
the dispatch thread by ~188s and blocking sendNotify() for
EVT_ONSYSTEMPOWERSTATECHANGED.

Fix:
- xconfclient.c: Replace getParameterValue(PRIVACYMODES_RFC) with
  direct getPrivacyMode() call from privacycontrol library. The
  platform implementation (provided via meta layer bbappend) reads
  from a local in-memory cache (PRIVACY_STATE), with fallback to
  Thunder JSON-RPC (local HTTP) and persistent storage — none of
  which use rbus, eliminating the self-deadlock.
`
- xconf-client/Makefile.am: Add privacycontrol include path and
  build dependency when IS_PRIVACYCONTROL_ENABLED is set.

- telemetry_busmessage_sender.c: Add fast-fail file marker check
  (T2_COMPONENT_READY) before rbus_getUint() in isCachingRequired()
  to avoid 15s blocking timeout when T2 is not yet ready.
Test Procedure: please refer the ticket comments
Risks: Medium


* Addressed the L1 Test cases failure

* RDKEMW-15927, RDKEMW-15007 : [APACA/Xione DE] Fix RBUS handler starvation and race condition on privacyModeVal

Reason for change: When UserSettings sets privacy mode to DO_NOT_SHARE during boot,
the rbus SET handler (t2PropertyDataSetHandler) runs synchronously
on the single rbus callback thread — executing deleteAllProfiles()
with pthread_join, disk I/O, and XConf client restart.

The restarted XConf thread calls appendRequestParams() which uses
getParameterValue(PRIVACYMODES_RFC) to fetch privacy mode. This
issues rbus_get() on T2's own bus handle, requiring the same rbus
callback thread that is already blocked processing the SET handler.
This creates a self-deadlock with a 15s rbus timeout per attempt,
compounded by XCONF_RETRY_TIMEOUT (180s), stalling T2 initialization.

Additionally, privacyModeVal global pointer has no mutex protection,
allowing use-after-free and NULL dereference under concurrent
SET/GET operations during stress scenarios.

Cascading effect: While T2 is stalled, external callers (e.g.
WPEFramework SystemServices plugin) invoking t2_event_s() block
15s each on rbus_getUint(Telemetry.OperationalStatus), delaying
the dispatch thread by ~188s and blocking sendNotify() for
EVT_ONSYSTEMPOWERSTATECHANGED. Under concurrent privacy mode
toggling, PROVIDER_NOT_RESPONDING with 26+ messages queued and
dropped, telemetry events fall back to file caching.

Fix:
- rbusInterface.c: Add privacyModeMutex (PTHREAD_MUTEX_INITIALIZER)
  to serialize all reads/writes of privacyModeVal in SET and GET
  handlers, preventing use-after-free and NULL dereference.

- rbusInterface.c: Add privacyModeCallbackWorker() detached thread.
  The SET handler now validates input, updates privacyModeVal under
  mutex, calls setPrivacyMode() for persistence, then dispatches
  heavy callbacks (mprofilesDeleteCallBack, privacyModesDoNotShareCallBack)
  to the worker thread. RBUS handler returns immediately, preventing
  handler thread starvation and cascading 180s timeout loops.

- xconfclient.c: Replace getParameterValue(PRIVACYMODES_RFC) with
  direct getPrivacyMode() call from privacycontrol library. The
  platform implementation (provided via meta layer bbappend) reads
  from a local in-memory cache (PRIVACY_STATE), with fallback to
  Thunder JSON-RPC (local HTTP) and persistent storage — none of
  which use rbus, eliminating the self-deadlock.

- xconf-client/Makefile.am: Add privacycontrol include path and
  build dependency when IS_PRIVACYCONTROL_ENABLED is set. Add else
  branch for libxconfclient_la_CFLAGS to define the variable in all
  automake conditions, fixing autoreconf failure.

- telemetry_busmessage_sender.c: Add fast-fail file marker check
  (T2_COMPONENT_READY) before rbus_getUint() in isCachingRequired()
  to avoid blocking on rbus timeout when T2 is not ready.

- persistence.c: Change rm -f to rm -rf in clearPersistenceFolder()
  non-LIBSYSWRAPPER path. PRIVACYMODE_PATH is a directory, not a
  file; rm -f fails silently leaving stale persistence data.

Test Procedure: Concurrent stress test with multiple privacy mode toggles
(SHARE/DO_NOT_SHARE via curl JSON-RPC), telemetry marker submissions
(telemetry2_0_client), rbuscli reads, and SIGUSR1 signal — all
running simultaneously in background.
Risks: Medium


* Addressed the shibu review comments

* Addressed the empty check on path  on fetchLocalConfigs and clearPersistenceFolder

* Apply suggestion from @Copilot



* Apply suggestion from @Copilot



* Removed the extra space for addressed the style formatting

* Addressed the astyle format issue

* Fix dangling pointer in rbusInterface.c GET handler: call rbusValue_SetString after ownership transfer

Agent-Logs-Url: https://github.com/rdkcentral/telemetry/sessions/d5b743ff-3289-4141-b51a-399971064c4c



---------






* Changelog updates for hotfix 1.8.5v1

* BES1-941: Update dcautil.h

* Update dcaproc.c

* Update dcaproc.c

* Update dcaproc.c

* Update dcaproc.c

* Update dcaproc.c

* BES1-941: Update dcaproc.c

* BES1-941: Update dcaproc.c

* BES1-941: Update dcaproc.c

* BES1-941: Update reportgen.c

* BES1-941: Update dcaproc.c

* RDKEMW-16851: Update dcautil.h

* RDKEMW-16851: Update dcaproc.c

* RDKEMW-16851: Update dcaproc.c

* RDKEMW-16851: Revert Info log lines to debug log lines



* Initial plan

* RDKEMW-16851: Update dcaproc.c



* RDKEMW-16851: Update dcaproc.c



---------

Signed-off-by: Thamim Razith <ThamimRazith_AbbasAli@comcast.com>
Signed-off-by: Yogeswaran K <yogeswaransky@gmail.com>
Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>
Co-authored-by: tabbas651 <thamimrazith_abbasali@comcast.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Yogeswaran K <166126056+yogeswaransky@users.noreply.github.com>
Co-authored-by: Yogeswaran K <yogeswaransky@gmail.com>
@shibu-kv
Copy link
Copy Markdown
Contributor

shibu-kv commented Apr 14, 2026

@copilot rebase copilot/sub-pr-322 branch with support/1.8 for his PR. The PR should only contain unit tests updates.

Merge branch 'support/1.8' to rebase PR onto support/1.8
e406202 
Co-authored-by: shibu-kv <89052442+shibu-kv@users.noreply.github.com>
Copy link
Copy Markdown
Contributor Author

Copilot AI commented Apr 14, 2026

@copilot rebase copilot/sub-pr-322 branch with support/1.8 for his PR. The PR should only contain unit tests updates.

Done (commit e406202). Merged support/1.8 into the branch — the PR diff now shows only the unit test additions in dcautilTest.cpp (254 lines, no dcaproc.c changes).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@shibu-kv shibu-kv Awaiting requested review from shibu-kv

Copilot code review Copilot Awaiting requested review from Copilot Copilot will automatically review once the pull request is marked ready for review

At least 1 approving review is required to merge this pull request.

Assignees

@shibu-kv shibu-kv

Copilot code review Copilot

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@shibu-kv @yogeswaransky