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

IsNil in pdata causes panic: nil pointer dereference #1731

Closed
pavolloffay opened this issue Sep 3, 2020 · 3 comments
Closed

IsNil in pdata causes panic: nil pointer dereference #1731

pavolloffay opened this issue Sep 3, 2020 · 3 comments
Labels
bug Something isn't working

Comments

@pavolloffay
Copy link
Member

Describe the bug

IsNil methods from pdata package cause panic: nil pointer dereference.

Steps to reproduce

func TestNil(t *testing.T) {
	rs := pdata.Resource{}
	assert.Equal(t, true, rs.IsNil())
}

What did you expect to see?

Not panic either false or true.

What did you see instead?

panic

What version did you use?

What config did you use?

Environment

Additional context

cc @tigrannajaryan

@pavolloffay pavolloffay added the bug Something isn't working label Sep 3, 2020
@pavolloffay
Copy link
Member Author

The method logic should be for instance

func (ms Resource) IsNil() bool {
	if ms.orig == nil {
		return true
	}
	return *ms.orig == nil
}

@tigrannajaryan
Copy link
Member

rs := pdata.Resource{}

This is not a valid usage as it is described in the comments for pdata.Resource:

// Must use NewResource function to create new instances.
// Important: zero-initialized instance is not valid for use.
type Resource struct {

@pavolloffay
Copy link
Member Author

This is not a valid usage as it is described in the comments for pdata.Resource:

How does the consumer of the resource/pdata structs know that the struct is zero initialized? There should be an API to check for that.

MovieStoreGuy pushed a commit to atlassian-forks/opentelemetry-collector that referenced this issue Nov 11, 2021
….Context (open-telemetry#1731)

* Store Span instead of local/remote SpanContext in Context

Now that the SpanContext has a remote identifier, storing a Span's
SpanContext two separate ways in a Context (one for local another for
remote) is unnecessary and adds complication throughout the project when
determining heredity of a Span. This moves to storing the Span directly
in the Context uniformly (for both local and remote) as current Span. In
the process, it updates the getter/setter functionality the `trace`
package provides and replaces the distributed heredity logic throughout
the project with just using the current Span as the parent if it exists.

* Update trace/context.go

Co-authored-by: Anthony Mirabella <a9@aneurysm9.com>

* Assert propagators context remote state

Co-authored-by: Anthony Mirabella <a9@aneurysm9.com>
hughesjj pushed a commit to hughesjj/opentelemetry-collector that referenced this issue Apr 27, 2023
…y#1731)

Bumps [boto3](https://github.com/boto/boto3) from 1.24.17 to 1.24.18.
- [Release notes](https://github.com/boto/boto3/releases)
- [Changelog](https://github.com/boto/boto3/blob/develop/CHANGELOG.rst)
- [Commits](boto/boto3@1.24.17...1.24.18)

---
updated-dependencies:
- dependency-name: boto3
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Troels51 pushed a commit to Troels51/opentelemetry-collector that referenced this issue Jul 5, 2024
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 a pull request may close this issue.

2 participants