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: move saving logic outside captor package #25

Merged
merged 4 commits into from
Aug 4, 2024
Merged

fix: move saving logic outside captor package #25

merged 4 commits into from
Aug 4, 2024

Conversation

alegrey91
Copy link
Owner

Fix #21

Signed-off-by: Alessio Greggi <ale_grey_91@hotmail.it>
Signed-off-by: Alessio Greggi <ale_grey_91@hotmail.it>
@alegrey91 alegrey91 requested a review from ccoVeille August 3, 2024 22:22
@@ -35,13 +40,29 @@ by passing the function name symbol and the binary args.
`,
Example: " harpoon -f main.doSomething ./command arg1 arg2 ...",
Run: func(cmd *cobra.Command, args []string) {
opts := captor.CaptureOptions{

functionSymbolList := strings.Split(functionSymbols, ",")
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm always worried when I see such code

And empty string will lead to a slice of 1 string with empty string in it.

So []string{""}

I would either check the length of functionSymbols before splitting, or I would skip in the for loop when strings.TrimSpace(item) == ""

I'm unsure if it can happen with your cost. But I cannot help myself to raise this to your attention

Copy link
Owner Author

Choose a reason for hiding this comment

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

Couldn't agree more with you. I'll add some checks to avoid that sometimes like so could happen. Thanks for raising the issue.

Copy link
Owner Author

Choose a reason for hiding this comment

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

Since the --function flag is marked as required, we should never face with an empty value in input.
So for now I would skip any control and add them in the future.

cmd/capture.go Outdated
syscalls, err := captor.Capture(functionSymbol, args, captureOpts)
if err != nil {
fmt.Printf("error capturing syscall: %v", err)
os.Exit(1)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is a bad pattern.

No os.Exit should be found outside main.go

It's outside the scope of your PR, and could be addressed in another one.

But here I would use RunE not Run because RunE signature supports returning an error.

So the os.Exit can be found in main.go only

This way you can test your code, and you will have one code to handle things

Copy link
Collaborator

Choose a reason for hiding this comment

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

Please note it could also mean you could use errors wrapping

So instead of this
fmt.Printf("error capturing syscall: %v", err)

You would use return fmt.Errorf("error capturing syscall: %w", err)

This way the fmt.Printis only present in main.go

Copy link
Owner Author

Choose a reason for hiding this comment

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

I'm removing this bad pattern from capture.go, but for the other files I'll open another PR.
I don't want to fill this PR with too many commits out of scope.

}
exitFuncProbe, err := bpfModule.GetProgram(uprobeExitFunc)
if err != nil {
fmt.Printf("error loading program (%s): %v\n", uprobeExitFunc, err)
os.Exit(-1)
return nil, fmt.Errorf("error loading program (%s): %v", uprobeExitFunc, err)
Copy link
Collaborator

Choose a reason for hiding this comment

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

All errors should be wrapped with %w, not %v

@ccoVeille
Copy link
Collaborator

PR and commit message talk about "captore" while it should be capture

@alegrey91
Copy link
Owner Author

PR and commit message talk about "captore" while it should be capture

This was intentionally named captor since is the package name, where the Capture function is implemented. Not sure this is the right name for describing "someone who captures something" but this was the expected meaning.

@ccoVeille
Copy link
Collaborator

Captor then, but it's connoted I think, maybe catcher then?

@ccoVeille
Copy link
Collaborator

PR and commit message talk about "captore" while it should be capture

I think I get what you didn't get, and that created confusion.

I was not reporting than captor was a bad name at first.

I reported you used captorE with a trailing "e" in PR and commit message

@alegrey91 alegrey91 changed the title fix: move saving logic outside captore package fix: move saving logic outside captor package Aug 4, 2024
@alegrey91
Copy link
Owner Author

PR and commit message talk about "captore" while it should be capture

I think I get what you didn't get, and that created confusion.

I was not reporting than captor was a bad name at first.

I reported you used captorE with a trailing "e" in PR and commit message

I see! thanks for clarifying ;)

Signed-off-by: Alessio Greggi <ale_grey_91@hotmail.it>
Signed-off-by: Alessio Greggi <ale_grey_91@hotmail.it>
@alegrey91 alegrey91 requested a review from ccoVeille August 4, 2024 21:25
@alegrey91 alegrey91 merged commit 91b2e5a into main Aug 4, 2024
@alegrey91
Copy link
Owner Author

Thanks for the review @ccoVeille.
I learned something new about the difference between Run and RunE :)

@ccoVeille
Copy link
Collaborator

Yes, you should take a look at other files and refactor them too.

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

Successfully merging this pull request may close these issues.

factor out saving logic from function Capture under internal/captor
2 participants