Skip to content
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

[BUG] k32w DiagnosticDataProviderImpl encodes random bytes as "utf-8" #26891

Closed
bzbarsky-apple opened this issue May 26, 2023 · 0 comments · Fixed by #26892
Closed

[BUG] k32w DiagnosticDataProviderImpl encodes random bytes as "utf-8" #26891

bzbarsky-apple opened this issue May 26, 2023 · 0 comments · Fixed by #26892
Labels

Comments

@bzbarsky-apple
Copy link
Contributor

Reproduction steps

  1. Try to read ThreadMetrics from a k32w device.
  2. Discover that some of the the thread names have a garbage char at the end.

Bug prevalence

Always

GitHub hash of the SDK that was being used

58420de

Platform

k32w

Platform Version(s)

All.

Anything else?

The problem is this code:

            strncpy(thread->NameBuf, taskStatusArray[x].pcTaskName, kMaxThreadNameLength - 1);
            thread->NameBuf[kMaxThreadNameLength] = '\0';
            thread->name.Emplace(CharSpan::fromCharString(thread->NameBuf));

which leaves one char at the end of the name with a random value.

bzbarsky-apple added a commit to bzbarsky-apple/connectedhomeip that referenced this issue May 26, 2023
The old code was copying in N-1 chars, then creating a string of length N from
them, so ending up with a random byte in the string, which could lead to the
string not being valid UTF-8.

Fixes project-chip#26891
andy31415 pushed a commit that referenced this issue May 29, 2023
The old code was copying in N-1 chars, then creating a string of length N from
them, so ending up with a random byte in the string, which could lead to the
string not being valid UTF-8.

Fixes #26891
bzbarsky-apple added a commit to bzbarsky-apple/connectedhomeip that referenced this issue May 30, 2023
The old code was copying in N-1 chars, then creating a string of length N from
them, so ending up with a random byte in the string, which could lead to the
string not being valid UTF-8.

Fixes project-chip#26891
andy31415 pushed a commit that referenced this issue May 30, 2023
The old code was copying in N-1 chars, then creating a string of length N from
them, so ending up with a random byte in the string, which could lead to the
string not being valid UTF-8.

Fixes #26891
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant