could not launch process: could not find symbol value for runtime.buildVersion

[ttllyy]

@npcode dlv version: Delve Debugger Version: 0.11.0-alpha Build: cf3a07b584847e25aa95e8663c2d99cf5d9c7cd4

Operation systerm: win7

go version: go version go1.5.1 windows/amd64 or go version go1.6 windows/amd64

idea version: 16 idea golang plugin version: Version: 0.11.1149

Some beego project debug lauch error, but not all project.

could not launch process: Could not determine version number: could not find symbol value for runtime.buildVersion

How Can I slove the problem? Thanks!

[ttllyy]

import “github.com/mattn/go-sqlite3” will debug error if I delete import “github.com/mattn/go-sqlite3” , no error. I install github.com/mattn/go-sqlite3 command: go get github.com/mattn/go-sqlite3

[LakeIshikawa]

Just to add some info: exact same error seemingly happens whenever trying to use any library that has native bindings of a particular C library (tried with https://github.com/gotk3/gotk3 and https://github.com/go-gl/gl).

The error goes away and the debugger works when the libraries are not imported.

[alexbrainman]

I am pretty sure this bug is because Go does not include DWARF information into Windows executable it builds if program uses CGO. See golang/go#10776 for details.

Alex

[silasdavis]

I am also experiencing this issue on Arch Linux, if I run something like:

dlv --listen=localhost:40573 --headless=true exec /tmp/TestRunnergo --

I get the following error reading runtime.buildVerison:

could not launch process: Unreadable version number: could not read string len input/output error

If I remove a certain import it works. I'm pretty sure I would be pulling in some code with c bindings with the import in question, but I haven't checked for sure. My go version is:

go version go1.6.2 linux/amd64

[silasdavis]

I can confirm that gotk3 causes the same issue as @LakeIshikawa indicated. Reproduction here: https://github.com/silasdavis/delve-failer/blob/master/test/runner/main.go

[silasdavis]

References to this info being missing seem to refer to Windows, so perhaps some other cause on Linux

[aarzilli]

@silasdavis: can't reproduce this. What version of delve are you using? Is your copy of gotk3 updated? Care to send a compiled binary?

[silasdavis]

Hi @aarzilli I've added a binary compiled on my system (https://github.com/silasdavis/delve-failer/blob/master/bin/maindotgo) with a runner here: https://github.com/silasdavis/delve-failer/blob/master/delve-run.sh.

operating system is: Arch Linux; 4.6.3-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux go version: go1.6.2 linux/amd64 gcc version: (GCC) 6.1.1 20160602

[silasdavis]

Oh and yes, gotk is latest

[aarzilli]

@silasdavis: I installed a arch vm and compiled your test program there and it worked. The most obvious difference between the binary I produced and yours is that the options -fstack-check=specific -fstack-protector-strong were passed to gcc when building your binary.

[silasdavis]

Hm, thanks for that, did you try the binary I compiled? To be clear the program does run for me (it outputs 'hello') but I see:

could not launch process: Unreadable version number: could not read string len input/output error

And delve does not launch properly.

[aarzilli]

I did try the binary you compiled and it does have that problem for me too. Do you have any clue as to where those gcc options would come from?

[silasdavis]

I have no idea where those options come from. On Arch I do see the stack-protector-strong flag set in /etc/makepkg.conf but this is related to how Arch compiles custom packages and I don't see why it would be used. I can't find any other default flag settings for GCC (open to suggestions of where to look). I also don't know how cgo/gc chooses flags for GCC. It seems that cgo uses GCC to compile a c function to call out when calling c. After some searching I can't find any clear information as to how this effects the binary produced. Using objdump (is that how you found out the flags? I found them with objdump -s --section=.debug_str bin/maindotgo | head -100 after some effort but would like to know a way to print them nicely) it is clear that when I import gotk I end up with a GCC binary, which I think is an archive, whereas without I can a non-gcc plain go binary.

I presume that by using cgo we don't opt in to having all our code compiled by gccgo? I'm guessing it's just the enclosing binary that get's compiled by GCC with various gc-compiled and gcc-compiled code inside.

It seems a bit odd that -fstack-protector-strong or fstack-check would cause these issues. They all related to protection added to the stack in the object code to guard against overflows, whereas the issue I seem to be seeing looks like reading unrelated binary metadata. Are there any other differences you can see between our binaries? Are you using GCC 6.1.1?

[aarzilli]

is that how you found out the flags?

I use dwarfdump.

I presume that by using cgo we don't opt in to having all our code compiled by gccgo? I'm guessing it's just the enclosing binary that get's compiled by GCC with various gc-compiled and gcc-compiled code inside.

Yes, that's correct.

It seems a bit odd that -fstack-protector-strong or fstack-check would cause these issues. They all related to protection added to the stack in the object code to guard against overflows, whereas the issue I seem to be seeing looks like reading unrelated binary metadata

I don't know how those work exactly also whatever is adding those options could also add other protection.

Are you using GCC 6.1.1?

DW_AT_producer GNU C11 6.1.1 20160602 -m64 -mtune=generic -march=x86-64 -g -O2 -fPIC -fmessage-length=0

[silasdavis]

Hm, this is frustrating, CFLAGS can be set in source files like:

// #cgo CFLAGS: -DPNG_DEBUG=1

But there's nothing with the stack-protector-strong flag in gotk3 obviously. Also with environment variables CGO_CFLAGS, CGO_CPPFLAGS, CGO_CXXFLAGS but I have none of these set. I can't find any particularly help information on how else they get set.

[silasdavis]

It seems I had managed to install a hardening-wrapper around my gcc: https://www.archlinux.org/packages/community/x86_64/hardening-wrapper/ as a dependency to something else, which is a rather nasty dependency to pull in for nginx!

I thought this was setting the stack-protector-strong. Oddly I still seem to have that being used to compile the binary, but removing the wrapper from my system does fix the problem, so it must be messing with GCC somehow. Although a diff of dwarfdump -s is identical for the working and non-working binary. So I'm at a loss, but at least it fixed it...

[aarzilli]

Thanks a lot for looking into this!

[xfreshx]

Have the same issue. Every module that has c-bindings under the hood gives me the same could not launch process: Could not determine version number: could not find symbol value for runtime.buildVersion

windows 8.1 x64

D:\projects>dlv version Delve Debugger Version: 0.11.0-alpha Build: 142d8827997378ff84434615edeec665f0092e05

D:\projects>go version go version go1.6.3 windows/amd64

[alexbrainman]

Have the same issue.

This will not fix until golang/go#10776 is fixed.

Alternatively you could use "internal" linker like

go build -ldflags="-linkmode=internal" ...

(see go help build and go tool link command output for details).

Alex

[xfreshx]

Yea, i saw that, but neither objdump --dwarf nor gdb doesn't give me any error. However, that link option helped me. Thank you a lot, Alex!

UPD: Though it starts, delve hangs on the first function that uses C function. In my case this is Exec from sql module.

UPD2: Switching driver from "github.com/mattn/go-sqlite3" to "github.com/mxk/go-sqlite/sqlite3" helped me to break through the issue.

[binlaniua]

@alexbrainman you saved me, thanks

[dlsniper]

I think this could be closed as Go 1.8 + latest delve seem to solve the issue.

[aarzilli]

mmhh the upstream counterpart and its cousin https://github.com/golang/go/issues/13672, that causes #631, are both still open.

[asampal]

I'm still seeing this error with Go 1.8.1, delve 1.0 rc, IntelliJ Idea 2017.2 EAP and the GO plugin version 172.2103.15.5. Considering the issue is declared closed for the latest Go/delve, am I missing something?

[dlsniper]

@asampal are you using Windows? If so edit your run configuration via Run | Edit Configurations... | select the config you want | click the link under Go tool arguments box that says: -ldflags="-linkmode internal". It it also known to work on some OS X cases, but I'm not sure when it applies. As for the Go plugin, see here: https://blog.jetbrains.com/go/2017/03/31/nightly-builds-of-the-go-plugin-for-intellij-idea-and-other-ides/ on how to get the latest nightly which includes the most updated delve version. You can also ping me on Gophers Slack in #gogland if you need further help.

[asampal]

@dlsniper , I pinged you on #gogland.