Skip to content

schema.MapAttribute struct without ElementType member causes segmentation fault #699

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.

Sign up for GitHub

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

Jump to bottom
Closed
mschuchard opened this issue Mar 23, 2023 · 2 comments · Fixed by #706
Closed

schema.MapAttribute struct without ElementType member causes segmentation fault #699

mschuchard opened this issue Mar 23, 2023 · 2 comments · Fixed by #706
Assignees
@bflad
Labels
bug Something isn't working
Milestone
v1.3.0

Comments

@mschuchard
Copy link

mschuchard commented Mar 23, 2023 •
edited
Loading

Module version

1.1.1

Relevant provider source code

schema.Schema{
  Attributes: map[string]schema.Attribute{
    // generic example following
    "foo": schema.MapAttribute{
      Description: "A Map attribute",
      Required:    true,
    },
  },
}

Adding e.g. ElementType: types.StringType, to the schema above fixes the issue as expected.

Expected Behavior

A clean runtime error thrown that the struct is missing the ElementsAs member.

Actual Behavior

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x6483df]

goroutine 83 [running]:
github.com/hashicorp/terraform-plugin-framework/types/basetypes.MapType.TerraformType(...)
	/home/matt/go/pkg/mod/github.com/hashicorp/[email protected]/types/basetypes/map.go:66
github.com/hashicorp/terraform-plugin-framework/internal/toproto6.SchemaAttribute({0xf950c0, 0xc000111080}, {0xe1d5c1, 0x6}, 0xc000112120, {0xf99408?, 0xc000262000?})
	/home/matt/go/pkg/mod/github.com/hashicorp/[email protected]/internal/toproto6/schema_attribute.go:26 +0x158
github.com/hashicorp/terraform-plugin-framework/internal/toproto6.Schema({0xf950c0, 0xc000111080}, {0xf999c0, 0xc00011e3c0})
	/home/matt/go/pkg/mod/github.com/hashicorp/[email protected]/internal/toproto6/schema.go:26 +0x2e6
github.com/hashicorp/terraform-plugin-framework/internal/toproto6.GetProviderSchemaResponse({0xf950c0, 0xc000111080}, 0xc00018f610)
	/home/matt/go/pkg/mod/github.com/hashicorp/[email protected]/internal/toproto6/getproviderschema.go:51 +0x52e
github.com/hashicorp/terraform-plugin-framework/internal/proto6server.(*Server).GetProviderSchema(0xc000254580, {0xf950c0?, 0xc000110f90?}, 0x1546e10)
	/home/matt/go/pkg/mod/github.com/hashicorp/[email protected]/internal/proto6server/server_getproviderschema.go:23 +0xc7
github.com/hashicorp/terraform-plugin-go/tfprotov6/tf6server.(*server).GetProviderSchema(0xc00031d680, {0xf950c0?, 0xc0001104e0?}, 0x0?)

There are several more lines, but their stack trace pertains to the gRPC server and are omitted for brevity.

Steps to Reproduce

Executing an acceptance test would be the easiest reproduction step.
@mschuchard mschuchard added the bug Something isn't working label Mar 23, 2023
@chrismarget-j
Copy link

I have also wished for something slightly more graceful than a nil pointer dereference in cases like these.

@mschuchard mschuchard mentioned this issue Mar 24, 2023
Closed
@bflad bflad self-assigned this Mar 27, 2023
@bflad bflad added this to the v1.3.0 milestone Mar 27, 2023
bflad added a commit that referenced this issue Mar 29, 2023
@bflad
all: Refactor schema validation to support type-specific logic and pr…
1f275d6 
…event AttributeTypes/ElementType field panics

Reference: #574
Reference: #699
Reference: #704
Reference: #705

The goal of this change is to enable easier schema validation within the framework logic. This is achieved by implementing new internal interfaces that implement shared logic across all schema types, then introduce methods on attribute types which currently implement type-specific validation logic.

The new `ValidateImplementation()` methods on attribute types, while technically exported, cannot be implemented externally due to their usage of internal types. This follows the existing implementation of the framework where attribute types already cannot be extended due to the `Equal(fwschema.Attribute)` method requirement. Therefore these new `ValidateImplementation()` methods do not need to worry about compatibility promises and can be modified or removed in the future.

This change also includes some breadcrumbs for other schema validation requests.
@bflad bflad mentioned this issue Mar 29, 2023
Merged
bflad added a commit that referenced this issue Mar 30, 2023
@bflad
all: Refactor schema validation to support type-specific logic and pr…
d763289 
…event AttributeTypes/ElementType field panics (#706)

Reference: #574
Reference: #699
Reference: #704
Reference: #705

The goal of this change is to enable easier schema validation within the framework logic. This is achieved by implementing new internal interfaces that implement shared logic across all schema types, then introduce methods on attribute types which currently implement type-specific validation logic.

The new `ValidateImplementation()` methods on attribute types, while technically exported, cannot be implemented externally due to their usage of internal types. This follows the existing implementation of the framework where attribute types already cannot be extended due to the `Equal(fwschema.Attribute)` method requirement. Therefore these new `ValidateImplementation()` methods do not need to worry about compatibility promises and can be modified or removed in the future.

This change also includes some breadcrumbs for other schema validation requests.
@bflad bflad mentioned this issue Apr 5, 2023
Closed
@github-actions
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 30, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bflad bflad

Labels
bug Something isn't working
Projects
None yet
Milestone
v1.3.0
3 participants
@bflad @mschuchard @chrismarget-j