Compiling error on debug
Answered
Hello! I've been using GoLand for the past year and encountered the following error for the first time while trying to debug an application. Wasn't able to find any other reference to this error in the internet Some details:
- In the past I was able to debug the same application without any issues
- If I try to Run the application, the compilation is successful and the application runs normally
- Other applications within the same environment are being compiled successfully when debugging
- No configuration changes were made on this specific project or in GoLand settings
runtime.textsectionmap: reloc 1 (R_ADDR) to non-macho symbol runtime.text.1 type=1 (STEXT)
runtime.textsectionmap: unsupported obj reloc 1 (R_ADDR)/8 to runtime.text.1
panic: machorelocsect: size mismatch
goroutine 3372 [running]:
cmd/link/internal/ld.machorelocsect(0x14000160000, 0x14001e2a5b0, 0x14025277380, {0x14044880000?, 0x0?, 0x1002d9b80?})
cmd/link/internal/ld/macho.go:1256 +0x214
cmd/link/internal/ld.relocSectFn.func1.1()
cmd/link/internal/ld/asmb.go:203 +0x4c
created by cmd/link/internal/ld.relocSectFn.func1 in goroutine 1
cmd/link/internal/ld/asmb.go:202 +0x1e4
Compilation finished with exit code 1Version:
- GoLand 2023.2.1 (Build #GO-232.9559.64, built on August 25, 2023) running on Mac Silicon
- Go version go1.22.2 darwin/arm64
I cannot share the code because it's from a corporate application.
Any clue on what I might be missing?
Thanks in advance!
Please sign in to leave a comment.
Hi,
Could you please update GoLand to 2024.1 version?
Most likely, it happens due to version mismatches between Delve (that we're using under the hood) and 1.22 version of Go.
In 2024.1, GoLand bundles the latest Delve version that supports 1.22.
I just hit this exact same scenario. I'm already on GoLand 2024.1. I'm guessing this isn't a coincidence… what else might be happening here?
Thanks!
Appreciate you getting back to me so quickly, Daniil.
I updated my GoLand to 2024.1 but I'm still facing the same issue, just like Dluhring.
New version's build is #GO-241.14494.238
Hi,
Is there a chance to reproduce it on an open-source or hello-world project?
I can see that it crashes in linker/compiler natively in Go, so I'm not sure what might cause this issue without reproducer.
Have you tried to compile it with other Go versions, for example 1.21.9? Do you use CGO in this project?
Debugging works as expected when downgrading go version to 1.21.x, stops working from 1.22.0.
CGO is enabled in this project.
I tried replicating the problem in other applications (some from the internet) with no success so far. Will update here if I end up finding one.
Sure, it seems a problem on Go side then, I'd also ask Go team to troubleshoot this problem: https://github.com/golang/go/issues but they also unlikely will know the root cause without some code samples/examples.
I'm trying to reproduce with Go 1.21.9, but GoLand is making it a little difficult: I've installed go1.21.9, but when I try to change GoLand's confiured GOROOT to this installation and click apply, within a few seconds GoLand has changed the GOROOT to `~/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.22.0.darwin-arm64`. I've even forcibly removed this directory, and GoLand seems to put it back again without me having a say.
Any tips for getting GoLand to stick with a particular Go version are appreciated! I've installed Go via homebrew, in case that's relevant.
Please check your go.mod file. It shouldn't contain a toolchain directive if you wouldn't want to use it.
Also, invoke go env and make sure that GOTOOLCHAIN is not set to any particular Go version.
Just found this too, you're absolutely right, thanks! A nice-to-have would be GoLand having a notification that this switch is happening explicitly, in case it's relevant to the user. But agreed this was user error nonetheless.
And, debugging works again with 1.21.9. Very interesting.
Sure, we're going to provide a notification in that case soon (GO-16061).
That's awesome!
Submitted this to Go — please correct anything I got wrong on there!
https://github.com/golang/go/issues/66993