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] Arbitrated client token memory leakage #443

Open
2 tasks done
amgross opened this issue Dec 26, 2024 · 0 comments · May be fixed by #444
Open
2 tasks done

[BUG] Arbitrated client token memory leakage #443

amgross opened this issue Dec 26, 2024 · 0 comments · May be fixed by #444
Labels

Comments

@amgross
Copy link
Contributor

amgross commented Dec 26, 2024

Describe the bug

In ArbitratedClientManager::performClientRequest, in case of none oneway API token is aquired:

token = m_arbitrator->prepareClientReceive(request);

The token is released just as part of calling m_arbitrator->clientReceive(token), but this call is done just if codec status is OK:
if (request.getCodec()->isStatusOk() == true)
{
// Complete the receive through the arbitrator.
err = m_arbitrator->clientReceive(token);

Hence if m_arbitrator->send fails, the token won't get released:
err = m_arbitrator->send(&request.getCodec()->getBufferRef());
request.getCodec()->updateStatus(err);

To Reproduce

Loop calls of none oneway API on arbitrated client, where transport layer send fails.
You expect in first tomes to get the send fail, till memory leakege block your system and then the token getting will fail:

if (token == 0U)
{
request.getCodec()->updateStatus(kErpcStatus_Fail);
}

Expected behavior

Token is always released before exiting ArbitratedClientManager::performClientRequest

Screenshots

Desktop (please complete the following information)

  • OS: windows
  • eRPC Version:1.13.0

Steps you didn't forgot to do

  • I checked if there is no related issue opened/closed.
  • I checked that there doesn't exist opened PR which is solving this issue.

Additional context

@amgross amgross added the bug label Dec 26, 2024
@amgross amgross linked a pull request Dec 26, 2024 that will close this issue
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

1 participant