Provider crashing on resource destroy

[voided]

What happened?

Similar to #36, I'm getting a provider segfault when destroying resources.

Generated from https://github.com/lord-kyron/terraform-provider-phpipam via pulumi package add terraform-provider registry.terraform.io/lord-kyron/phpipam.

It was mentioned in #36 that TF providers using the v1 SDK had issues (that looked to be resolved), but based on the stack trace it looks like this one is using v2.

    error: rpc error: code = Unavailable desc = error reading from server: EOF:
    
    Stack trace from the terraform-provider-phpipam_v1.6.2 plugin:
    
    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xaa0e1d]
    
    goroutine 85 [running]:
    github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ApplyResourceChange(0xc000395ec0, {0xde4a88?, 0xc0004b1980?}, 0xc000251450)
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.26.1/helper/schema/grpc_provider.go:926 +0x2bd
    github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ApplyResourceChange(0xc00025da40, {0xde4a88?, 0xc0004b0fc0?}, 0xc0001fef50)
        github.com/hashicorp/terraform-plugin-go@v0.15.0/tfprotov5/tf5server/server.go:818 +0x56f
    github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ApplyResourceChange_Handler({0xc85400, 0xc00025da40}, {0xde4a88, 0xc0004b0fc0}, 0xc0001feee0, 0x0)
        github.com/hashicorp/terraform-plugin-go@v0.15.0/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:419 +0x1a6
    google.golang.org/grpc.(*Server).processUnaryRPC(0xc00026c1e0, {0xde9260, 0xc000454000}, 0xc0004bc5a0, 0xc0003a1890, 0x13170a0, 0x0)
        google.golang.org/grpc@v1.55.0/server.go:1337 +0xdb8
    google.golang.org/grpc.(*Server).handleStream(0xc00026c1e0, {0xde9260, 0xc000454000}, 0xc0004bc5a0, 0x0)
        google.golang.org/grpc@v1.55.0/server.go:1714 +0x9da
    google.golang.org/grpc.(*Server).serveStreams.func1.1()
        google.golang.org/grpc@v1.55.0/server.go:959 +0x8d
    created by google.golang.org/grpc.(*Server).serveStreams.func1 in goroutine 35
        google.golang.org/grpc@v1.55.0/server.go:957 +0x154
    
    Error: The terraform-provider-phpipam_v1.6.2 plugin crashed!
    
    This is always indicative of a bug within the plugin. It would be immensely
    helpful if you could report the crash with the plugin's maintainers so that it
    can be fixed. The output above should help diagnose the issue.

Example

1.  import * as pulumi from "@pulumi/pulumi";
    import * as phpipam from "phpipam";
   
    const config = new pulumi.Config("phpipam");
   
    const provider = new phpipam.Provider("phpipam", {
      appId: config.require("appId"),
      endpoint: config.require("endpoint"),
      username: config.require("username"),
      password: config.requireSecret("password"),
    });
   
    new phpipam.Section(
      "section",
      {
        name: "Section Name",
      },
      { provider }
    );

2. pulumi up - successful

3. Comment out phpipam.Section resource and pulumi up again - segfault in the terraform-provider-phpipam_v1.6.2 plugin.

Output of pulumi about

CLI          
Version      3.144.1
Go Version   go1.23.4
Go Compiler  gc

Plugins
KIND      NAME                VERSION
language  nodejs              3.144.1
resource  terraform-provider  0.5.4
resource  terraform-provider  0.5.4

Host     
OS       ubuntu
Version  22.04
Arch     x86_64

This project is written in nodejs: executable='/home/voided/.nvm/versions/node/v22.12.0/bin/node' version='v22.12.0'

Current Stack: organization/space-ipam/prod

TYPE                           URN
pulumi:pulumi:Stack            urn:pulumi:prod::space-ipam::pulumi:pulumi:Stack::space-ipam-prod
pulumi:providers:phpipam       urn:pulumi:prod::space-ipam::pulumi:providers:phpipam::phpipam
phpipam:index/section:Section  urn:pulumi:prod::space-ipam::phpipam:index/section:Section::section


Found no pending operations associated with prod

Backend        
Name           desktop-dev
URL            file:///mnt/z/pulumi-state/organization
User           voided
Organizations  
Token type     personal

Dependencies:
NAME            VERSION
tsconfig-paths  4.2.0
typescript      5.7.2
@pulumi/pulumi  3.144.1
@types/node     22.10.2
phpipam         1.6.2

Pulumi locates its logs in /tmp by default

Additional context

I can happily provide my state file privately, please let me know how to share it!

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[guineveresaenger]

Hi @voided, thank you for making us aware.

We're still working on debugging this kind of bug on dynamically bridged providers, where we have no provider cedentials, but we've come a bit further since #36, so hopefully, your statefile is not needed! 🤞

Could you please run both your above program steps with
PULUMI_DEBUG_GRPC_LOGS=pulumi-logs.json and PULUMI_TF_DEBUG_GRPC=tf-logs.json set? Then send us the logs via a gist here.

Thank you so much!

[voided]

@guineveresaenger those flags didn't seem to generate a pulumi-logs.json in the cwd, but it did create tf-logs.json.

https://gist.github.com/voided/2722f889aea115128111ad12e9dd88f8

STEP ONE file is when creating the initial resources with pulumi up, which is successful.
STEP TWO file is when commenting out the phpipam.Section and running pulumi up, which fails.

[guineveresaenger]

I'm sorry -I sent you the wrong environment variable for the Pulumi logs. I'm sorry for the trouble. Could you generate the Pulumi GRPC logs as follows:

PULUMI_DEBUG_GRPC=pulumi-logs.json pulumi up ? (Note there's no LOGS in the env var).

Thank you for the TF logs!

[voided]

@guineveresaenger Logged both files this time: https://gist.github.com/voided/2812657a4f78404c701ca0505593e45e

Same naming pattern as before, "STEP ONE" for the pulumi up that succeeds, and "STEP TWO" for the pulumi up that tries to destroy a resource and fails.

[iwahbe]

Thanks for working with us to collect logs. We'll take a look at getting this fixed.