GDB - Attach to and break a running Go application - gdb

I compiled a simple go application with debug flags:
go build -gcflags "-N -l" -o main main.go
main.go
package main
import (
"fmt"
"time"
)
func main() {
for i := 0; true; i++ {
fmt.Println("number:", i)
time.Sleep(time.Second)
}
}
In gdb, I attached to its pid and executed break and break 11.
gdb --pid=<pid>
Gdb reports that the breakpoints are successfully set, but they don't ever get hit. Is there a way to get this working?

Note: that same setup (even when adding your runtime-gdb.py to your .gdbrc) risks to not work with Ubuntu 13.10, where you would get a "SyntaxError" message, as illustrated in:
blog post "Debugging Go 1.2 on Ubuntu 13.10 with GDB" from Michael Susens-Schurter (schmichael)
issue 6698 (gdb: upgrade to be python 3 compatible)
The problem is that Ubuntu 13.10 links GDB against Python 3.3 while the script golang ships is for Python 2. Someone has already filed an issue, and it appears to be fixed upstream (so expect Go 1.3 to Just Work).
Luckily backporting the fix is easy. Simply move your exist runtime-gdb.py out of the way and download the upstream version in its place.
If your $GOROOT is /usr/local/go the following should Just Work:
sudo mv /usr/local/go/src/pkg/runtime/runtime-gdb.py /usr/local/go/src/pkg/runtime/runtime-gdb.py.orig
cd /usr/local/go/src/pkg/runtime/
sudo wget https://go.googlecode.com/hg/src/pkg/runtime/runtime-gdb.py

the go/src/pkg/runtime/runtime-gdb.py script needs to be loaded inside gdb to effectively be able to debug go programs.
You can add it to the .gdbrc file.

Related

how to compile Ignite application on CMake?

I did compile Ignite Application successfully.
but The Binary didn't work.
/tmp/tmp.Nw0IPD6ru3/cmake-build-debug-local-container/planet_engine: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory
how can I make to it work?
Also, I compiled C++ Examples successfully. such as ignite-compute-example.
and, I execute that but I got an error message.
An error occurred: JVM library is not found (did you set JAVA_HOME environment variable?)
and I using a nightly release version 2.8.0.20190213 because I couldn't build to version 2.7 in my environment.
I posted environment values down.
IGNITE_HOME=
TERM=xterm-256color
SHELL=/bin/bash
LIBRARY_PATH=/root/jre1.8.0_201/lib/amd64/server:/root/jre1.8.0_201/lib/amd64/
LC_NUMERIC=ko_KR.UTF-8
SSH_TTY=/dev/pts/0
JRE_HOME=/root/jre1.8.0_201
USER=root
LS_COLORS=rs=0:d...
LD_LIBRARY_PATH=/root/jre1.8.0_201/lib/amd64/server:/root/jre1.8.0_201/lib/amd64/
CLASS_PATH=/root/jdk-11.0.2/lib:
LC_TELEPHONE=ko_KR.UTF-8
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/jdk-11.0.2/bin
LC_IDENTIFICATION=ko_KR.UTF-8
JAVA_HOME=/root/jdk-11.0.2
LANG=en_US.UTF-8
LC_MEASUREMENT=ko_KR.UTF-8
JDK_HOME=/root/jdk-11.0.2/lib
SHLVL=1
HOME=/root
LOGNAME=root
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
LC_TIME=ko_KR.UTF-8
LC_NAME=ko_KR.UTF-8
_=/usr/bin/env
Thank you for reading. :)
I got it.
I am working on a docker container environment.
and therefore I am using remote build and debug with ssh and gdb.
finally, I found out why it couldn't find libjvm.so and why couldn't read environment values such as JAVA_HOME.
because it is working in gdb for now.
I confirmed that it is working when without gdb.
I will find a solution.
and, if I have been found, I will update the answer.
[Solved]
I share how I make solved that.
I was using an Oracle JDK-11 through source install.
but Ignite C++ client need something different with latest released jdk versions.
Ignite need a directory structure like this
JAVA_HOME/ (as JDK install directory)
- jre/
- lib/
- lib/
...
I solved by apt install openjdk-8-jdk.
openjdk-8-jdk have structure for what Ignite need.
i added JAVA_HOME, IGNITE_HOME, at /etc/environment.
It works finally.
but I got another problem. HAHA
I am so sad.
This also GDB problem..

Pabot - Unable to run parallel robotframework tests

So, I'm working on a robotframework test project, and the goal is to run several test suites in parallel. For this purpose, pabot was chosen as the solution. I am trying to implement it, but with little success.
My issue is: after installing Pabot (which, I might say, I did by cloning the project and running "setup.py install", instead of using pip, since the corporate proxy I'm behind has proven an obstacle I can't overcome), I created a new directory in the project tree, moved some suites there, and ran:
pabot --processes 2 --outputdir pabot_results Login*.robot
Doing so results in the following error message:
2018-10-10 10:27:30.449000 [PID:9676] [0] EXECUTING Suites.LoginAdmin
2018-10-10 10:27:30.449000 PID:400 EXECUTING Suites.LoginUser
2018-10-10 10:27:30.777000 PID:400 FAILED Suites.LoginUser
2018-10-10 10:27:30.777000 [PID:9676] [0] FAILED Suites.LoginAdmin
WARN: No output files in "pabot_results\pabot_results"
Output:
[ ERROR ] Reading XML source '' failed: invalid mode ('rb') or filename
Try --help for usage information.
Elapsed time: 0 minutes 0.578 seconds
Upon inspecting the stderr file that was generated, I have this message:
Traceback (most recent call last):
File "C:\Python27\Lib\site-packages\robotframework-3.1a2.dev1-py2.7.egg\robot\running\runner.py", line 22, in
from .context import EXECUTION_CONTEXTS
ValueError: Attempted relative import in non-package
Apparently, this has to do with something from the runner.py script, which, if I'm not mistaken, came with the installation of robotframework. Since manually modifying that script does not seem to me the optimal solution, my question is, what am I missing here? Did I forget to do anything while setting this up? Or is this an issue of compatibility between versions?
This project is using Maven as the tool to manage dependencies. The version I am running is 3.5.4. I am using a Windows 10, 64bit system; I have Python 2.7.14, and Robot Framework 3.1a2.dev1. The Pabot version is 0.44. Obviously, I added C:\Python27 and C:\Python27\Scripts to the PATH environment variable.
Edit: I am also using robotframework-maven-plugin version 1.4.0.8, if that happens to be relevant.
Edit 2: added the error messages in text format.
I believe I've come across an issue similar when setting up parallel execution on my machine. Firstly I would confirm that pabot is installed using pip show robotframework-pabot.
Then you should define the directory your results are going to using -d.
I then modified the name of the -o to Output.xml to make it easy to identify.
This is a copy of the code I use. Runs optimally with 8 processes
pabot --processes 8 -d results -o Output.xml Tests
Seems that you stumbled on a bug in the prerelease version of robot framework (3.1a2.dev1).
Please install a release version of robot framework. For example 3.0.4.
Just in case anyone happens to stumble upon this issue in the future:
Since I can't use pip, and I tried a good deal of workarounds that eventually made things more unstable, I ended up saving my project and removing everything Python-related from my system, so as to allow me to install everything from scratch. In a Windows 10, 64bit system, I used:
Python 2.7.14
wxPython 2.8.12.1, win64, unicode, for py27
setuptools 40.2.0 (to allow me to use the easy_install command)
Robot Framework 3.0.4
robotremoteserver 1.1
Selenium2Library 3.0.0
and Pabot version 0.45.
I might add that, when installing the Selenium2Library the way I described above, it eventually tries to download some things from the pip repositories - which, if you have a proxy, will cause you trouble. I solved this problem by browsing https://pypi.org/simple/selenium/, manually downloading the 2.53.6 .tar.gz file, then extracting it and running setup.py install on the command line.
PS: Ideally, though, anyone should be able to use proxy settings from the command line (--proxy http://user:password#server:port) to get pip and then use it; however, for some reason, probably related to network security configurations that I didn't want to lose time with, this didn't work in my case.

ERROR: Failed to build PhantomJS! Building Qt Base failed

I have Debian Linux(64-bit) in VirtualBox.
Ram: 8Gb (for Debian 4Gb)
CPU: i5-3470
If any other details are needed please tell me.
I have followed instructions written here, and here you can see the console log.
For some reason I am unable to to build phantomjs and I can't understand why its not working... Have searched a lot, but couldn't find any thread which would be about this error.
--- EDIT ---
When I executed this command:
./configure --with-openssl-includes=/usr/include/openssl-1.0/ --with-openssl-libraries=/usr/lib/openssl-1.0/
Output was this:
--with-openssl-includes=/usr/include/openssl-1.0/: invalid command-line switch
--with-openssl-libraries=/usr/lib/openssl-1.0/: invalid command-line switch
The output of the console has changed but I still get errors: https://pastebin.com/wbgi8syg
Looks like you are on stretch (or later) and that you are already aware of the libssl vs libssl1.0 case.
Therefore, if you don't have libssl-dev installed, this line will get you further:
python build.py --qt-config "-I /usr/include/openssl-1.0/ -L /usr/lib/openssl-1.0/"
If you already have it installed and my suggestion doesn't work, you can uninstall libssl-dev for the time to build phantomjs which will likely avoid having to play further with configuration related variables.

Remote debugging with root privileges

i've got a trouble. Can't debug my program remotly due to can't call wiringPiSetupGpio(). I'm using netbeans to develop and debug my programs. I'm almost sure I need run debugging as root user but... how can I do that?
Is it possible to force netbeans start something like 'sudo gdb' insead of normal user? Or maybe to force my account in raspberry pi to call 'sudo gdb' when whatever try to call 'gdb'?
To force netbeans start gdb as root, you need to install netbeans as root. make sure your netbeans intall dir is in /usr/local and not in /home/[user_name]. You have to run netbeans installation as sudo
This is an old post but since I was facing the same issue I will post how I resolved this:
The problem for me did not seem to be the gdb, but the gdbserver running on the Raspi (or Beaglebone in my case).
I added a debug configuration to debug the application as root, therefore I added a script to the Beaglebone /usr/local/sbin/gdbserver and added the following lines:
#!/bin/bash
sudo /usr/bin/gdbserver $*
and made it executable:
sudo chmod a+x /usr/local/sbin/gdbserver
and see that in the file /etc/login.defs the lines
ENV_SUPATH PATH= ....
ENV_PATH PATH= ....
contain /usr/local/sbin. then in the debug configuration for the root execution I changed the command gdbserver to /usr/local/sbin/gdbserver. If that still doesn't work you might have to do this too:
sudo visudo
and add
<your_user> ALL=(root) NOPASSWD:/usr/bin/gdbserver
I hope this helps.

Fabric and virtualenv working on Ubuntu but not on Solaris

I have a project that runs on Ubuntu and Solaris. Fabric works fine with Ubuntu but does not on Solaris. If I try something inside a virtualenv it fails with workon: command not found.
This is how my fabfile.py looks like:
with prefix('workon %s' % env.virtualenv):
sudo('manage.py collectstatic --noinput')
I put those lines in .profile on both platforms:
export WORKON_HOME=$HOME/.virtualenvs
source /path/to/virtualenvwrapper.sh
That's all I've done. Why does Ubuntu work but Solaris doesn't? Any ideas?
It's Virtualenvwrapper that's failing, not Fabric or Virtualenv. Try using Virtualenv directly with:
with prefix('source path/to/virtualenv/bin/activate'):
sudo('manage.py collectstatic --noinput')
EDIT:
to try to fix virtualenvwrapper, try wrapping your code in the following, and see if it solves the original error.
with prefix('source path/to/virtualenvwrapper.sh'):
Consider where you have put the following?
export WORKON_HOME=/opt/virtual_envs
source /usr/local/bin/virtualenvwrapper.sh
According to man bash, the -l flag, that fabric issues, will cause the the following to happen
[bash] looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
I had this bootstrap code in .bashrc, which wasn't being sourced by bash -l. I moved those two lines to .profile, and can now do the fabric lines below. (I don't have .bash_profile or .bash_login)
with cd('/www/code'):
with prefix('workon code'):
run('./manage.py validate')