eclipse c++ debugging google test with spaces in test name on Linux - linux

I am trying to debug a google test using eclipse (helios) on Linux, when i run a test (without debugging) using --gtest_filter option (example --gtest_filter=Something*) it runs normally.
when i am trying to run the debugger it pop up this error message:
without specifiying arguments the debugger works normally, what could be the problem?

problem Solved.
Solution:
use:
--gtest_filter='Something*' instead of "Something*"
in my case the reason was because of the way eclipse pass arguments to gdb, so the command that will run is:
gdb ./program_name --gtest_filter=Something*
so the * bothers the gdb (maybe think it is paramater for gdb command).

Related

Is there a way to get printouts from an pyqt5 application built with fbs for Windows without being a debug build?

Use case: Would like to add CLI functionality to a application built with fbs.
When building for Ubuntu it prints out everything when I run this application from the command line, which is what I want. Building with the same settings but for Windows instead I'm not getting any printouts when I try to run this from Powershell or Command Prompt. On Windows the application also seems to be put into the background making it less obvious when it is finished. When application hits an unhandled exception it does not print the error into the command line but into its own window.
Is there a setting you can use to allow printouts for Windows? I know you have a debug build setting which does this but releasing a release as a debug build does not seem right.
cmd /c <name-of-app>.exe This resolves the issue not knowing when the application is done, it does not print out any messages however. It also prints out any unhandled exceptions into its own window.

GDB doesn't show source code when using list command

I'm trying to debug a segfault, but it seems that some common gdb commands aren't working as expected. If I do the following:
gdb ./executable_name
break main
run
list
I get the following error:
(gdb) list
1 <built-in>: No such file or directory.
Similarly, if I let the program run until it segfaults, and then try and inspect a particular frame in the stack using
bt
up
list
I get a similar but shorter error:
(gdb) list
1 in <built-in>
I've used GDB on other Ubuntu-based systems before and haven't had a problem like this, so I'm assuming I still need to set GDB up correctly on my system so that it knows where to look for an executable's corresponding source code. Would anyone know how I could get GDB to display source code whilst using the list command when debugging?
I should have looked more before asking the above question. The above executable was not built in debug mode. I'm using ROS and catkin, so using catkin build -DCMAKE_BUILD_TYPE=Debug in the package directory solved the problem.

How to debug pyramid test cases in pycharm 3

I am evaluating Pycharm 3 for pyramid development. My question is how can I debug / set breakpoint pyramid test cases in pycharm 3.
To run test cases, I give following command
python setup.py test -q
I configure this in pycharm, to run test cases from pycharm. But If I set debug pointer / breakpoint, control wont stop. It run test cases without stopping any breakpoint.
Thanks
Aniruddha
See PyCharm documentation on Breakpoints and Debugging.

linux eclipse: run a shell command as the pre-build command

How can I have the pre-build step in eclipse/CDT (Linux) run a simple shell command, echo specifically. I think eclipse has a screwed up value for PKG_CONFIG_PATH and want to see what Linux thinks the value is.
Under the covers, Eclipse uses "make". You can simly edit the project's makefile:
help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.cdt.doc.user/concepts/cdt_c_makefile.htm
You can also create an:
"External Tool", which is up there beside the Debug and Run buttons in
the toolbar. Then I tell the external tool to run the shell with the
configure script and any of it's arguments as arguments to the tool.
http://www.eclipse.org/forums/index.php/t/61866/

gdb appears to ignore executable capabilities

I am debugging a program that makes use of libnetfilter_queue. The documentation states that a userspace queue-handling application needs the CAP_NET_ADMIN capability to function. I have done this using the setcap utility as follows:
$ sudo setcap cap_net_raw,cap_net_admin=eip ./a.out
I have verified that the capabilities are applied correctly as a) the program works and b) getcap returns the following output:
$ getcap ./a.out
./a.out = cap_net_admin,cap_net_raw+eip
However, when I attempt to debug this program using gdb (e.g. $ gdb ./a.out) from the command line, it fails on account of not having the correct permissions set. The debugging functionality of gdb works perfectly otherwise and debugs as per normal.
I have even attempted to apply these capabilities to the gdb binary itself to no avail. I did this as it seemed (as documented by the manpages that the "i" flag might allowed the debugee to inherit the capability from the debugger.
Is there something trivial I am missing or can this really not be done?
I run into same problem and at beginning I thought the same as above that maybe gdb is ignoring the executable's capability due to security reason. However, reading source code and even using eclipse debugging gdb itself when it is debugging my ext2fs-prog which opens /dev/sda1, I realize that:
gdb is no special as any other program. (Just like it is in the matrix, even the agents themselves they obey the same physical law, gravity etc, except that they are all door-keepers.)
gdb is not the parent process of debugged executable, instead it is grand father.
The true parent process of debugged executable is "shell", i.e. /bin/bash in my case.
So, the solution is very simple, apart from adding cap_net_admin,cap_net_raw+eip to gdb, you have also apply this to your shell. i.e. setcap cap_net_admin,cap_net_raw+eip /bin/bash
The reason that you have also to do this to gdb is because gdb is parent process of /bin/bash before create debugged process.
The true executable command line inside gdb is like following:
/bin/bash exec /my/executable/program/path
And this is parameter to vfork inside gdb.
For those who have the same problem, you can bypass this one by executing gdb with sudo.
A while ago I did run into the same problem. My guess is that running the debugged program with the additional capabilities is a security issue.
Your program has more privileges than the user that runs it. With a debugger a user can manipulate the execution of the program. So if the program runs under the debugger with the extra privileges then the user could use these privileges for other purposes than for which the program intended to use them. This would be a serious security hole, because the user does not have the privileges in the first place.
For those running GDB through an IDE, sudo-ing GDB (as in #Stéphane J.'s answer) may not be possible. In this case, you can run:
sudo gdbserver localhost:12345 /path/to/application
and then attach your IDE's GDB instance to that (local) GDBServer.
In the case of Eclipse CDT, this means making a new 'C/C++ Remote Application' debug configuration, then under the Debugger > Connection tab, entering TCP / localhost / 12345 (or whatever port you chose above). This lets you debug within Eclipse, whilst your application has privileged access.
I used #NickHuang's solution until, with one of system updates, it broke systemd services (too much capabilities on bash for systemd to start it or some such). Switched to leaving bash alone and instead pass a command to gdb to invoke the executable directly. The command is
set startup-with-shell off
OK, so I struggled a bit with this so I thought I'd combine answers and summarise.
The easy solution is just to sudo gdb as suggested but just be a bit careful. What you're doing here is running the debugged program as root. This may well cause it to operate differently than when you run it from the command line as a normal user. Could be a bit confusing. Not that I would EVER fall into this trap... Oopsies.
This will be fine if you're running the debugged program as root with sudo OR if the debugged program has the setuid bit set. But if the debugged program is running with POSIX capabilities (setcap / getcap) then you need to mirror these more granular permissions in bash and gdb as Nick Huang suggested rather than just brute forcing permissions with 'sudo'.
Doing anything else may lead you to a bad place of extreme learning.

Resources