RDKEMW-16851: Increase Process name buffer length from 16 to 64 by Copilot · Pull Request #322 · rdkcentral/telemetry

Copilot · 2026-04-10T08:57:52Z

Fetch support/1.8 branch
Verify dcaproc.c is identical between support/1.8.5 and support/1.8
Merge support/1.8 into branch to align history
Verify diff against support/1.8 shows only dcaproc.c changes (1 file, 21 insertions, 20 deletions)
Push changes to remote
Action needed: Please retarget PR RDKEMW-16851: Increase Process name buffer length from 16 to 64 #322 base from topic/BES1-941 to support/1.8 in GitHub UI (Edit → Base branch)

#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>

Signed-off-by: Yogeswaran K <yogeswaransky@gmail.com>

…-306 # Conflicts: # CHANGELOG.md Co-authored-by: yogeswaransky <166126056+yogeswaransky@users.noreply.github.com>

yogeswaransky

LGTM

Copilot

Pull request overview

This PR updates the DCA process-usage collection logic to better handle longer process names and to make CPU/memory extraction from top output more robust.

Changes:

Replace unbounded memcpy(..., strlen()+1) with a bounded copy into pInfo.processName.
Clear existing marker->cpuValue / marker->memValue before repopulating them.
Update top | grep ... command construction to try matching either by process name or by PID, and make an existing debug log reachable by moving a return.

Copilot · 2026-04-10T10:18:46Z

+        strncpy(pInfo.processName, processName, BUF_LEN - 1);
+        pInfo.processName[BUF_LEN - 1] = '\0';


The PR title/description says the process name buffer is increased from 16 to 64, but this change still writes into pInfo.processName sized by BUF_LEN (which is currently 16 in source/dcautil/dcautil.h). As a result, longer process names will still be truncated here. If the intent is truly a 64-byte process name, the buffer size needs to be updated at the type/define level (or introduce a dedicated PROC_NAME_BUF_LEN) and ensure all related code uses that size consistently.

Copilot · 2026-04-10T10:18:46Z

+            inFp = v_secure_popen("r", "top -n 1 -c | grep -v grep | { grep -i '%s' || grep -E '^[[:space:]]*%d[[:space:]]'; }", pInfo->processName, pInfo->pid[0]);
 #else
-            sprintf(command, "top -n 1 -c | grep -v grep |grep -i '%s'", pInfo->processName);
+            snprintf(command, CMD_LEN, "top -n 1 -c | grep -v grep | { grep -i '%s' || grep -E '^[[:space:]]*%d[[:space:]]'; }", pInfo->processName, pInfo->pid[0]);
            inFp = popen(command, "r");


The { grep -i ... || grep -E ...; } fallback in a pipeline won’t work as intended: the first grep consumes all stdin even when it finds no matches, so the second grep runs with EOF and cannot match by PID. If you need a name-or-PID match from a single top output stream, use a single filter (e.g., a single grep -E with alternation, or awk matching either $1==pid or the command column contains the name).

shibu-kv · 2026-04-10T21:23:51Z

        {
 #ifdef LIBSYSWRAPPER_BUILD
-            inFp = v_secure_popen("r", "top -n 1 -c | grep -v grep |grep -i '%s'", pInfo->processName);
+            inFp = v_secure_popen("r", "top -n 1 -c | grep -v grep | { grep -i '%s' || grep -E '^[[:space:]]*%d[[:space:]]'; }", pInfo->processName, pInfo->pid[0]);


This adds more advanced regex capabilities which is more oriented towards bash. This may not work on all limited busy box provided shell capabilities.

shibu-kv

Please refer to comments from previous review submission

Signed-off-by: Yogeswaran K <yogeswaransky@gmail.com>

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

Copilot · 2026-04-13T12:28:28Z

+        /* match by process name (case-insensitive), PID as fallback */
+        if(strcasestr(top_op, pInfo->processName) == NULL)
+        {
+            int line_pid = 0;
+            if(sscanf(top_op, "%d", &line_pid) != 1 || line_pid != pInfo->pid[0])


The new matching/parsing logic (case-insensitive name match with PID fallback, plus the direct-file read path) isn’t covered by existing unit tests (current tests only exercise the NULL-pInfo case for getCPUInfo). Adding gtest coverage for these new branches would help prevent regressions across different top output formats and ensure the fallback behavior works as intended.

@copilot Create a separate pull request with adding additional L1 test cases .

shibu-kv · 2026-04-13T13:12:21Z

+        /* match by process name (case-insensitive), PID as fallback */
+        if(strcasestr(top_op, pInfo->processName) == NULL)
+        {
+            int line_pid = 0;
+            if(sscanf(top_op, "%d", &line_pid) != 1 || line_pid != pInfo->pid[0])


@copilot Create a separate pull request with adding additional L1 test cases .

Copilot · 2026-04-13T13:13:33Z

@shibu-kv I've opened a new pull request, #325, to work on those changes. Once the pull request is ready, I'll request review from you.

shibu-kv and others added 18 commits March 31, 2026 08:03

Changelog updates for hotfix 1.8.5v1

96522ab

BES1-941: Update dcautil.h

36cc492

Update dcaproc.c

5ed035d

Update dcaproc.c

fa217de

Update dcaproc.c

686b55d

Update dcaproc.c

4691dfe

Update dcaproc.c

b61db1a

BES1-941: Update dcaproc.c

166397e

BES1-941: Update dcaproc.c

64b8ebb

BES1-941: Update dcaproc.c

85a438c

BES1-941: Update reportgen.c

dc06b86

BES1-941: Update dcaproc.c

934c31e

RDKEMW-16851: Update dcautil.h

c732533

RDKEMW-16851: Update dcaproc.c

d7703f9

RDKEMW-16851: Update dcaproc.c

8423c8b

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

349537a

Signed-off-by: Yogeswaran K <yogeswaransky@gmail.com>

Initial plan

8640655

Copilot AI assigned Copilot and yogeswaransky Apr 10, 2026

Copilot AI mentioned this pull request Apr 10, 2026

RDKEMW-16851: Increase Process name buffer length from 16 to 64 #306

Closed

Copilot started work on behalf of yogeswaransky April 10, 2026 08:57 View session

Copilot AI changed the title ~~[WIP] [RDKEMW-16851] Increase process name buffer length from 16 to 64~~ RDKEMW-16851: Increase Process name buffer length from 16 to 64 Apr 10, 2026

Copilot AI requested a review from yogeswaransky April 10, 2026 09:02

Copilot finished work on behalf of yogeswaransky April 10, 2026 09:02

Copilot started work on behalf of yogeswaransky April 10, 2026 09:46 View session

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>

Copilot finished work on behalf of yogeswaransky April 10, 2026 09:56

yogeswaransky changed the base branch from topic/BES1-941 to support/1.8 April 10, 2026 10:13

yogeswaransky approved these changes Apr 10, 2026

View reviewed changes

yogeswaransky marked this pull request as ready for review April 10, 2026 10:14

yogeswaransky requested a review from a team as a code owner April 10, 2026 10:14

Copilot AI review requested due to automatic review settings April 10, 2026 10:14

Copilot started reviewing on behalf of yogeswaransky April 10, 2026 10:14 View session

Copilot AI reviewed Apr 10, 2026

View reviewed changes

shibu-kv reviewed Apr 10, 2026

View reviewed changes

shibu-kv requested changes Apr 10, 2026

View reviewed changes

yogeswaransky added 2 commits April 13, 2026 12:14

RDKEMW-16851: Update dcaproc.c

280222b

Signed-off-by: Yogeswaran K <yogeswaransky@gmail.com>

RDKEMW-16851: Update dcaproc.c

c990e15

Signed-off-by: Yogeswaran K <yogeswaransky@gmail.com>

Copilot AI review requested due to automatic review settings April 13, 2026 12:23

Copilot started reviewing on behalf of yogeswaransky April 13, 2026 12:24 View session

Copilot AI reviewed Apr 13, 2026

View reviewed changes

shibu-kv approved these changes Apr 13, 2026

View reviewed changes

Copilot AI mentioned this pull request Apr 13, 2026

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

Draft

shibu-kv merged commit e6c65e5 into support/1.8 Apr 13, 2026
8 checks passed

shibu-kv deleted the copilot/sub-pr-306 branch April 13, 2026 13:13

github-actions bot locked and limited conversation to collaborators Apr 13, 2026

		strncpy(pInfo.processName, processName, BUF_LEN - 1);
		pInfo.processName[BUF_LEN - 1] = '\0';

Conversation

Copilot AI commented Apr 10, 2026 • edited by yogeswaransky Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yogeswaransky left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 10, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 10, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

shibu-kv Apr 10, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

shibu-kv left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

shibu-kv Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

shibu-kv Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI commented Apr 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Copilot AI commented Apr 10, 2026 •

edited by yogeswaransky

Loading