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

Initialize attr variables in Legacy.switch_get and LegacyFdbEntry.fdb_entry_get #1169

Merged

Conversation

saiarcot895
Copy link
Contributor

When running unit tests for sairedis, there may be random test failures for Legacy.switch_get and LegacyFdbEntry.fdb_entry_get. This is happening because when doing the get call for
SAI_SWITCH_ATTR_DEFAULT_VIRTUAL_ROUTER_ID, the value isn't initialized in this unit test function, with the assumption that it would contain the actual value assuming the get call was successful. There's two problems that happen:

  1. Since a dummy SAI interface is being used for these tests, the get call always succeeds (assuming that the attr list and count arguments are valid), but the value for each attr is not modified at all.
  2. Since this call returns a success, in meta_generic_validation_post_get_objlist, it will see the value for the attr (which is uninitialized memory) and complain that this value is not valid for this attr.

Depending on the uninitialized memory there, the reference counter for this OID may get incremented, and then when deleting the switch object, it will complain that there's still objects present, because it thinks this object exists.

To get around this, initialize attr1 and attr2 to make sure it's all zeroes, and that some random OID won't get added to a reference list.

Signed-off-by: Saikrishna Arcot sarcot@microsoft.com

…_entry_get

When running unit tests for sairedis, there may be random test failures
for Legacy.switch_get and LegacyFdbEntry.fdb_entry_get. This is
happening because when doing the get call for
SAI_SWITCH_ATTR_DEFAULT_VIRTUAL_ROUTER_ID, the value isn't initialized
in this unit test function, with the assumption that it would contain
the actual value assuming the get call was successful. There's two
problems that happen:

1. Since a dummy SAI interface is being used for these tests, the get
call always succeeds (assuming that the attr list and count arguments
are valid), but the value for each attr is not modified at all.
2. Since this call returns a success, in
meta_generic_validation_post_get_objlist, it will see the value for the
attr (which is uninitialized memory) and complain that this value is
not valid for this attr.

Depending on the uninitialized memory there, the reference counter for
this OID may get incremented, and then when deleting the switch object,
it will complain that there's still objects present, because it thinks
this object exists.

To get around this, initialize `attr1` and `attr2` to make sure it's all
zeroes, and that some random OID won't get added to a reference list.

Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
@saiarcot895 saiarcot895 merged commit 4ab46b5 into sonic-net:master Dec 7, 2022
@saiarcot895 saiarcot895 deleted the fix-vs-unit-test-corruption branch December 7, 2022 20:16
yxieca pushed a commit that referenced this pull request Dec 12, 2022
…_entry_get (#1169)

When running unit tests for sairedis, there may be random test failures
for Legacy.switch_get and LegacyFdbEntry.fdb_entry_get. This is
happening because when doing the get call for
SAI_SWITCH_ATTR_DEFAULT_VIRTUAL_ROUTER_ID, the value isn't initialized
in this unit test function, with the assumption that it would contain
the actual value assuming the get call was successful. There's two
problems that happen:

1. Since a dummy SAI interface is being used for these tests, the get
call always succeeds (assuming that the attr list and count arguments
are valid), but the value for each attr is not modified at all.
2. Since this call returns a success, in
meta_generic_validation_post_get_objlist, it will see the value for the
attr (which is uninitialized memory) and complain that this value is
not valid for this attr.

Depending on the uninitialized memory there, the reference counter for
this OID may get incremented, and then when deleting the switch object,
it will complain that there's still objects present, because it thinks
this object exists.

To get around this, initialize `attr1` and `attr2` to make sure it's all
zeroes, and that some random OID won't get added to a reference list.

Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>

Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants