-
Notifications
You must be signed in to change notification settings - Fork 230
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
helper/resource: Kernel Panics on darwin/arm64 (e.g. Apple M1 hardware) #1088
Comments
I can confirm these panics also happen with strictly unit testing within helper/resource itself. |
Here's the relevant socket definitions for the kernel panic ( #define SS_ISCONNECTED 0x0002 /* socket connected to a peer */
#define SS_NBIO 0x0100 /* non-blocking ops */
#define SOF_NODEFUNCT 0x00008000 /* socket cannot be defunct'd */
#define SOF_INCOMP_INPROGRESS 0x00040000 /* incomp socket is being processed */
#define SOF1_INBOUND 0x01000000 /* Created via a passive listener */ |
Since writing Terraform logs does not flush to disk enough to be accurate at time of the kernel panic, have gone down to worst case troubleshooting route of logging to console and capturing a photo by an external camera in the second or two while the OS writes the panic snapshot and before it forcibly restarts the OS. Simplified logs of these have included: terraform-provider-tls (pre #1091):
terraform-plugin-sdk:
The prevalence of |
Some additional captures from testing with last night within terraform-plugin-sdk (TestPanicAtTheDisco being raw logic within the testing framework):
All signs seem to point at Terraform CLI's starting of the go-plugin client (which does perform |
This issue appears to be resolved with macOS Ventura (13.x). Please open a new issue if still encountering this issue. |
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. |
SDK version
Relevant provider source code
It seems any acceptance testing code will do, but potentially more prevalent with providers that are state-only. Maybe due to the acceptance testing code running faster than API-based providers.
Terraform Configuration Files
N/A
Expected Behavior
Acceptance testing (or Go code in general) should never cause the operating system kernel to panic.
Actual Behavior
During acceptance testing, the workstation restarts due to kernel panic.
Steps to Reproduce
TF_ACC=1 go test -count=1 -v ./...
in providers such as:Additional Information
This has happened for a few weeks now to multiple developers across multiple provider codebases. It may potentially be related to #1063. Seems to only happen on darwin/arm64 and not darwin/amd64.
For me, it's happened on a few macOS versions now, with the latest time (today) being with:
Here are some macOS panic snapshots from my workstation: https://gist.github.com/bflad/a709e2c1ddfa980c0c3163565485ee6f
Note that the in-flight task seems to be
provider.test
.The text was updated successfully, but these errors were encountered: