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

fix: fix slice init length #1288

Merged
merged 1 commit into from
Oct 7, 2024
Merged

fix: fix slice init length #1288

merged 1 commit into from
Oct 7, 2024

Conversation

cuishuang
Copy link
Contributor

Description

The intention here should be to initialize a slice with a capacity of len(prof.Location) rather than initializing the length of this slice.

The online demo: https://go.dev/play/p/q1BcVCmvidW

Type of change

  • Bug fix (non-breaking change which fixes an issue)

How has this been tested?

  • Test A
  • Test B

How has this been benchmarked?

  • Benchmark A, on Macbook pro M1, 32GB RAM
  • Benchmark B, on x86 Intel xxx, 16GB RAM

Checklist:

  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • I did not modify files generated from templates
  • golangci-lint does not output errors locally
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

@CLAassistant
Copy link

CLAassistant commented Oct 4, 2024

CLA assistant check
All committers have signed the CLA.

@ivokub
Copy link
Collaborator

ivokub commented Oct 4, 2024

Thanks for the PR. Right now it indeed seems that we initialize the nodes differently. I'll further check if we don't somehow assume that first len(prof.Location) values are there for inserting something, but currently it looks like not.

@ivokub ivokub added the bug Something isn't working label Oct 4, 2024
@cuishuang
Copy link
Contributor Author

Thanks for the PR. Right now it indeed seems that we initialize the nodes differently. I'll further check if we don't somehow assume that first len(prof.Location) values are there for inserting something, but currently it looks like not.

I have searched many Go repositories, and this is a common issue. I am trying to solve it at the Go toolchain level

@ivokub
Copy link
Collaborator

ivokub commented Oct 4, 2024

Thanks for the PR. Right now it indeed seems that we initialize the nodes differently. I'll further check if we don't somehow assume that first len(prof.Location) values are there for inserting something, but currently it looks like not.

I have searched many Go repositories, and this is a common issue. I am trying to solve it at the Go toolchain level

Interesting! Imo it is a very good find. Indeed we have based our profiling implementation on the Go standard one, but capturing different metrics.

@cuishuang
Copy link
Contributor Author

Thanks for the PR. Right now it indeed seems that we initialize the nodes differently. I'll further check if we don't somehow assume that first len(prof.Location) values are there for inserting something, but currently it looks like not.

I have searched many Go repositories, and this is a common issue. I am trying to solve it at the Go toolchain level

Interesting! Imo it is a very good find. Indeed we have based our profiling implementation on the Go standard one, but capturing different metrics.

Thank you for your recognition!

I am preparing to add a detection item in go vet to avoid this issue. In the future, it may only be necessary to update the Go version, as there will be relevant detection items in the latest toolchain

@ivokub
Copy link
Collaborator

ivokub commented Oct 7, 2024

I checked - in gnark this code path is never called and cannot be called without modifying the internal implementation. And even if it is initalized incorrectly, then later in selectNodesForGraph the nil entries are filtered out. But the issue is valid in any case.

Thanks for reporting!

@ivokub ivokub self-requested a review October 7, 2024 23:29
Copy link
Collaborator

@ivokub ivokub left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@ivokub ivokub merged commit ca8e156 into Consensys:master Oct 7, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants