we are trying to debug Go code and getting this error:
could not launch process: decoding dwarf section info at offset 0x0: too short
our settings:
WITSC02X6385JGH:orderer sjain68$ uname -a
Darwin WITSC02X6385JGH 17.7.0 Darwin Kernel Version 17.7.0: Fri Jul 6 19:54:51 PDT 2018; root:xnu-4570.71.3~2/RELEASE_X86_64 x86_64
WITSC02X6385JGH:orderer sjain68$ go version
go version go1.11 darwin/amd64
WITSC02X6385JGH:orderer sjain68$ dlv version
Delve Debugger
Version: 1.1.0
Build: $Id: 1990ba12450cab9425a2ae62e6ab988725023d5c
Things we have tried:
Update dlv using VS Code -> Go: Install/Update Tools
Try running from command line:
WITSC02X6385JGH:orderer sjain68$ /Users/sjain68/go/bin/dlv debug github.com/hyperledger/fabric/orderer --headless=true --listen=127.0.0.1:41305 --api-version=2 --log=true --
API server listening at: 127.0.0.1:41305
INFO[0002] launching process with args: [/Users/sjain68/go/src/github.com/hyperledger/fabric/orderer/debug] layer=debugger
debugserver-#(#)PROGRAM:debugserver PROJECT:debugserver-902.0.79.7
for x86_64.
Got a connection, launched process /Users/sjain68/go/src/github.com/hyperledger/fabric/orderer/debug (pid = 9278).
Exiting.
could not launch process: decoding dwarf section info at offset 0x0: too short
Note that the binary that we are trying to debug does gets executed. Its just that the debugger does not launch.
Another thing we tried from this link:
WITSC02X6385JGH:orderer sjain68$ export GOFLAGS="-ldflags=-compressdwarf=false"; dlv debug
could not launch process: decoding dwarf section info at offset 0x0: too short
Someone said to run GOCACHE=off go build ... and output of that is pasted here.
How can we fix this?
I had the same issue after updateing Go.
Updating Delve package from console helped:
go get -u github.com/go-delve/delve/cmd/dlv
The solution that worked for us was to upgrade Go version
$ go version
go version go1.13.3 darwin/amd64
So Go 1.11 is the culprit.
make sure you aren't using flags that remove the debug info from your build ie -ldflags="-s -w" .
https://lukeeckley.com/post/useful-go-build-flags/
Related
When I build source on Golang, I saw the warning message, but I couldn't find answer about it.
$ go build --mod=mod -o main main.go
# command-line-arguments
ld: warning: -no_pie is deprecated when targeting new OS versions
specs
version : go version go1.18 darwin/amd64
os : Monterey 12.6
build command : go build --mod=mod -o [binary name] main.go
From GitHub: link
There are a few options:
- wait for the next Go 1.19.x and 1.18.x releases, probably early next month
- build Go from the master branch
- pass -buildmode=pie flag to go build and go test for a workaround
- use older version of the system linker
This seems to be a known issue. See Github for more information.
As a workaround you can pass the -buildmode=pie flag to your go build command.
It doesn't hang Goland, but I can't use step into, step over and other debug buttons. When starting debugging, it prints:
GOPATH=/Users/a/go:/Users/a/sdk/go1.16.3 #gosetup
/Users/a/sdk/go1.16.3/bin/go build -o /private/var/folders/xg/45g_0kp96gj_11cftvnq919r0000gn/T/___go_build_Mur_go -gcflags all=-N -l /Users/a/GoProjects/Main/Mur.go #gosetup
"/Users/a/Library/Application Support/JetBrains/Toolbox/apps/Goland/ch-0/211.7142.13/GoLand.app/Contents/plugins/go/lib/dlv/macarm/dlv" --listen=0.0.0.0:54550 --headless=true --api-version=2 --check-go-version=false --only-same-user=false exec /private/var/folders/xg/45g_0kp96gj_11cftvnq919r0000gn/T/___go_build_Mur_go --
API server listening at: [::]:54550
debugserver-#(#)PROGRAM:LLDB PROJECT:lldb-1205.0.27
for arm64.
Got a connection, launched process /private/var/folders/xg/45g_0kp96gj_11cftvnq919r0000gn/T/___go_build_Mur_go (pid = 97777).
It's a known issue, please see GO-11011.
You can download GoLand Nightly via Toolbox App with the fix or compile Delve manually and specify a path to it, please see the corresponding issue.
Suddenly on the afternoon of January 6, 2021, my Selenium Protractor tests under OSX stopped working with the mysterious error
spawn Unknown system error -86
I did some research and discovered that error number 86 is the same as
Bad CPU type in executable
and ran the following to compare the cpu architecture of my chromedriver binary to my system:
% file chromedriver_87.0.4280.88
chromedriver_87.0.4280.88: Mach-O 64-bit executable arm64
% uname -a
Darwin kobl179273m 19.6.0 Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.141.2.2~1/RELEASE_X86_64 x86_64
% uname -p
i386
How can I fix the chromedriver binary used by my Selenium so that it will run on my Intel x64 mac and clear the "system error -86" or "Bad CPU type" message?
The issue is described in https://github.com/angular/webdriver-manager/issues/476.
This has been now fixed in 12.1.8 so just update to that webdriver manager.
For most users this can be accomplished with
npm uninstall protractor && npm install protractor
Edit: this answer should be considered deprecated now that the underlying bug in webdriver-manager has been fixed. A better solution would be to upgrade to the newest version of webdriver-manager. The answer below may be useful if people need to use an older version of webdriver-manager which still has the bug.
As per Deepak Srinivasan's comment above, this error is caused by https://github.com/angular/webdriver-manager/issues/476
Root Cause:
The ChromeDriver team added "_m1" to the end of the filename for their Apple Silicon ARM builds of Chromedriver -- but both the Silicon and Intel versions of chromedriver have "mac64" in the filename, and the version number is exactly the same. This causes webdriver-manager to always download the Silicon build of Chromedriver, even on Intel macs. As a general solution, simply avoid using the chromedriver that has _m1 in its filename if you are on an Intel mac.
Solution 1: Downgrade to Chrome 86.0.4240.198 and Chromedriver 86.0.4240.22. These versions work together and are the most recent versions prior to the new and problematic support for Silicon ARM
Chrome 86 download page:
https://google-chrome.en.uptodown.com/mac/download/2920124
Disable auto-updates in Chrome: https://superuser.com/questions/1359017/how-do-i-disable-automatic-updates-of-google-chrome-on-mac-os-x
Chromedriver 86: https://chromedriver.storage.googleapis.com/index.html?path=86.0.4240.22/
% webdriver-manager update --versions.chrome=86.0.4240.22
Solution 2: Modify the webdriver-manager npm package to point to the correct chromedriver (thanks to ciekaway from the angular github issue page for this fix)
Modify the following file
node_modules/webdriver-manager/built/lib/files/file_manager.js
or, if using protractor
node_modules/protractor/node_modules/webdriver-manager/built/lib/files/file_manager.js
Near the top of the downloadFile method around line 166, add the following line to remove "_m1" from the name of the file:
fileUrl.url = fileUrl.url.replace(/_m1/, '');
It needs to be after the beginning of the .then block that starts with
binary.getUrl(binary.version()).then(fileUrl => {
it also needs to be before the next reference to fileUrl.
For example:
binary.getUrl(binary.version()).then(fileUrl => {
binary.versionCustom = fileUrl.version;
fileUrl.url = fileUrl.url.replace(/_m1/, '');
let filePath = path.resolve(outputDir, binary.filename());
Note that this solution is temporary. It will be overwritten by an npm install. The Chromedriver and/or the webdriver-manager team will probably fix this issue, at which point you should clear the modified version of your webdriver-manager and download the fix from npm.
For macOS Catalina Version 10.15.6 (19G73)
In my case I was working with Rails and Capybara for feature tests. What worked for me was
First, find the actual chromedriver location running:
which chromedriver
# Which returned:
/Users/alex/.webdrivers/chromedriver
Then, install chromedriver via Homebrew:
brew install chromedriver
Then, remove old chromedriver reference found at previous location with:
rm /Users/alex/.webdrivers/chromedriver
Now, link the old chromedriver reference to the one installed with brew:
ln -s /usr/local/bin/chromedriver /Users/alex/.webdrivers/chromedriver
Then, open Finder app, then click on Go menu and then click Go to folder ... option, and enter this route:
/usr/local/Caskroom/chromedriver/
There you should see a folder with the chromedriver version you have installed, something like this:
88.0.4324.96
Enter that folder and you should see the chromedriver binary file.
Right click on it, and click on Open
Now, you should get a terminal window popping up with the output:
Last login: Sun Jan 31 12:29:15 on ttys001
/usr/local/Caskroom/chromedriver/88.0.4324.96/chromedriver ; exit;
~ /usr/local/Caskroom/chromedriver/88.0.4324.96/chromedriver ; exit;
Starting ChromeDriver 88.0.4324.96 (68dba2d8a0b149a1d3afac56fa74648032bcf46b- refs/branch-heads/4324#{#1784}) on port 9515
Only local connections are allowed.
Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
ChromeDriver was started successfully.
Finally, press Ctrl+C to stop the execution and quit the terminal window.
Now, you should be able to run capybara tests.
npm uninstall protractor && npm install protractor
If you use webdrivers gem, upgrade it:
bundle update webdrivers
My system is WSL 2 in Windows 10.
OS: Debian 10 buster
Kernel: x86_64 Linux 4.19.104-microsoft-standard
Shell: zsh 5.7.1
CPU: AMD Ryzen 9 4900HS with Radeon Graphics # 16x 2.994GHz
Golang info:
go version go1.15.2 linux/amd64
GOROOT="/usr/local/go"
GOPATH="/mnt/c/workspace/6.824"
And I met a problem when I build a project by plugin model:
$ go build -buildmode=plugin ../mrapps/wc.go
build command-line-arguments: cannot find module for path _/mnt/c/workspace/6.824/src/mr
It is so strange that "_/mnt"
How can I solve it?
Why has a "_" before the path?
Help me, please.
I would try and use go mod instead of relying on GOPATH
unset GOPATH
cd /mnt/c/workspace/6.824/
go mod init "yourProject"
go build -buildmode=plugin mrapps/wc.go
You are using go mod. And you can try the following command to fix:
cd 6.824
go mod init "6.824-golabs-2020"
# change file src/mrapps/wc.go line9 to `import "6.824-golabs-2020/src/mr"`
cd src
go build -buildmode=plugin mrapps/wc.go
More details about mod you can refer to https://golang.org/ref/mod
Iam trying to analyse core file of GO program generated by gcore using delve. Below are steps I have followed. I got Unrecognized format error
$go version
go version go1.13.1 darwin/amd64
$/Users/sudhakar/go/bin/dlv version
Delve Debugger
Version: 1.4.0
Build: 37bee98a8821843314b561bc6ab328dfff2aad1b
$./hello &
[1] 72335
$gcore 72335
$sudo gcore 72335
$/Users/sudhakar/go/bin/dlv core ./hello /cores/hello-72335-20200427T185443Z
unrecognized core format
At the time of this post darwin/amd64 is not supported by delve.
Ref: https://github.com/go-delve/delve/blob/master/Documentation/usage/dlv_core.md
However this can change over time (delve may add support to this arch) attaching screenshot of documentation (at the time of this post)
Special thanks to delve-dev list member (Choudhary Sourya Vastayan) who pointed me to this.