-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
SIGSEGV: segmentation violation code=0x1 - help #49992
Comments
macos version? |
I am also facing similar issue go version go1.17.2 darwin/amd64 OSX version - 10.15.7
runtime stack: goroutine 1 [syscall]: |
What version of golang.org/x/sys do you use? Could you try updating your golang.org/x/sys dependency? Thanks. Maybe a dup of #45702 |
|
The golang.org/x/sys version I was using: golang.org/x/sys v0.0.0-20210124154548-22da62e12c0c |
Thanks. Then it is not #45702.
Do you know what's the difference between the machines? Also, is it reproducible with Go 1.16 ?
The faulting PC is not in the Go binary. It is probably from libSystem or a library that is dynamically linked in. Could you run it in a debugger and print what that address is? Thanks. |
His machine is: MacOS Monterey 12.0.1 with go1.17.3
Yes - it's reproducable with go1.16.11 darwin/amd64
Could you give me some more guidance on how to do this? I'm very new to golang. Thank you. |
Run the binary under Would it be possible to share the source code of your program and the procedure of reproducing the crash? Thanks. |
@cherrymui |
@cranzy thanks. Could you make sure the golang.org/x/sys dependency is updated? Could you paste the new output for the failure? Thanks. If this is reproducible, with Go 1.17, could you try building your binary with environment variable |
Hi there, I would like to add onto this issue because I am facing a similar problem. go version go1.17.2 darwin/amd64
Expected behavior: What actually happened:
|
@OsOmE1 I'm not sure what you're trying to do. Do you intentionally make it segfault at the ptrace call? It cannot be recovered as we switch to a different stack when issuing the actual syscall. |
Yes I do, this is an anti debugging technique and to make sure our pt_deny was successful we try to pt_attach and if it was successful it will segfault. If the ptrace call was tampered with, it will not. But thank you for pointing me in the right direction. Any other pointers on how I could make this work are always appreciated |
this worked for me seeing a similar issue. |
Thanks! |
No new info |
Works on 1.18.3 as well on Big Sur 11.6.5 darwin/amd64 |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
I get it both on 1.17.3 and 1.17.4
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Basically building locally a go binary. The binary that I produce is working on other people's MacOS machines but not on mine.
The way the binary is build is standard GOOS=$(1) GOARCH=$(2) go build where GOOS is darwin and GOARCH is amd64.
What did you expect to see?
Running go binary
What did you see instead?
The text was updated successfully, but these errors were encountered: