I am using c++/eclipse kepler on mac, and I cannot debug any project. The error is "Error while launching command: gdb --version" Besides that, I can build and run my code using other libraries.
I searched a site that is similar to my problem: Debugger for C++ eclipse gives the following error. 'Launching program name' has encountered a ... Error while launching command: gdb --version
But what should I change if I am using a mac?
You can fix this by specifying the full path to gdb. You can do this separately for each debug configuration, and you can also set the default gdb location in the preferences under C/C++ > GDB. For example, if you installed gdb via Homebrew, then it's probably located under /usr/local/bin:
And here's a screenshot of the Preferences:
I still don't know why Eclipse can't find GDB even though it is on my path. I guess it doesn't use my .bash_profile or my .bashrc? You could try symlinking gdb into /usr/bin. Maybe Eclipse will look there.
Edit: I tried the symbolic link idea and now Eclipse can debug, but it crashes inexplicably while doing so! So, I guess... don't do that?
This guide from a UC Irvine Computer Science professor's page is a very well-written, detailed, and Mac-specfic description of all the steps involved in installing GDB, creating a certificate, signing GDB using that certificate, and finally configuring Eclipse. I was found this very helpful as someone unfamiliar with each of these steps.
GDB Installation on Mac OS X
I had the same problem. I solved it by:
Install a gdb - ( I used 7.8.1) - compile and install it. It got installed in usr/local/bin
Codesigning certificate
Open eclipse executable using sudo. Otherwise I still get the error.
I am on OS X.
Hope this helps.
I had this error too now, and spent more than an hour looking for it.
In my case, the path was correct, and eclipse seemed to fail to start "any" executable as debugger. (I tested with gksudo cat, but it clearly never got to effectively running it).
The final reason was that I had put in my eclipse.ini -Xms1G and -Xmx1G. It seemed to already use the full memory for the indexer, and trying to allocate some more memory to start the debugger failed with an "unkown" error. Removing the memory limitations fixed the issue.
Hope this helps someone
I had many difficulties making GDB to work on Eclipse. I tried LLDB instead and it worked like a charm:
https://wiki.eclipse.org/CDT/User/FAQ#How_do_I_get_the_LLDB_debugger.3F
This can be a more convenient alternative for Mac users.
Mac OS Sierra 10.13.6 gdb 8.0.1
had the same error as topic-starter.
first, I set the path as Neil Traft (here in the answers) explains to usr/local/bin/gdb;
But it didn't work.
I found these instructions:
https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d
and I discovered that I already had gdbcert1 in my System. So I followed everything from 7. Works!
Related
I've got an error ".gdbinit: No such file or directory." when trying to debugging in Omnet++ 4.2.2 in Ubuntu 12.4. It seems that the debugger cannot find ".gdbinit", or the find the one not compatible. So where can I find ".gdbinit" in my PC, or where should I find the right version of it to replace? Any idea would be appreciated!
Danh
Hi all, I have alternative solution for my problem and would like to write here for those who need to refer later. Instead of using gdb we can use valgrind. As my understanding, it is pretty good tool to detect bug related to memory allocation. To use valgrind in Omnet, you must make sure to have it installed in your OS (e.g., in Ubuntu, just type sudo apt-get install valgrind). Then in Omnet IDE, simply choose Profile As.. instead of Debug As.. then choose Omnet++Simulation, then trace bugs in valgrind windows. I did find where my bug is by this way.
Thanks.
Danh
the problem is already known, that gdb doesn't work with OS X Sierra anymore.
This is really annoying, since I researched already about the solution, and there were some solutions, but they apparently don't work anymore. I tried to use the .gdbinit file solution and the disable csrutil solution, both doesn't work.
Sooo my question is: Does anyone know how to fix it in 10.12.3 ?
Thank you very much!
Looks like there still isn't a solution to this. I don't think "use LLDB instead of GDB" is the ultimate solution. So I went ahead and built a fairly basic docker container which contains the very basics (g++ and gdb).
Here is the Docker Hub container, and the the Dockerfile is on this Github repo.
This solution at least allows you to use GDB on your Mac via a couple simple commands. And since the folder you're coding on is mounted, as soon as you hit save, all your changes appear automatically.
Hope this helps someone else out there.
So thanks to Basile Starynkevitch, who just gave me the idea to update gdb
SOLUTION:
You simply have to update gdb for the latest version (which is 7.12.1 currently). Assuming you have installed Homebrew:
That's what I did:
brew update
brew remove gdb
brew install gdb
It has now updated to the latest version.
Now codesign gdb again with the cert that you used before.
sudo killall taskgated
codesign -fs gdb-certi /usr/local/bin/gdb
launchctl load /System/Library/LaunchDaemons/com.apple.taskgated.plist
Last step is still to use the workaround to create the .gdbinit file:
nano ~/.gdbinit
-> set startup-with-shell off
Debugging works for me now :) (OS X Sierra 10.12.3 - gdb 7.12.1).
UPDATE:
Apparently it will fix certain problems, but not the whole problematic itself. It will still cause errors. Honestly, my solution: When you can: Switch to LLDB and another IDE (Netbeans does not support LLDB). Or use Linux. I currently use Ubuntu with a stick on my MacBook Pro.
None GDB 7.11 or 7.12.1 will not work on Sierra 10.12.4 In short it's because of Apple security upgrade. We need to wait for re-enabling when some new version will shows up.
Easy WA is to use LLDB as a debugger for now. Sample instructions here
Another LLDB instruction here
I found that gdb 7.12.1 did not work for me either. I do not think it includes the crucial commit 82b19a4d2f9c9e8d56f to gdb made on the 9th Nov 2016.
I was able to get the gdb 8.0 development branch to work, however.
Download with, e.g.
git clone --depth 1 --branch gdb-8.0-branch git://sourceware.org/git/binutils-gdb.git
Then go into the checked-out directory
cd binutils-gdb
I have macports so (a) wanted to link to macports libraries and (b) wanted to avoid putting stuff in /usr/local so configured with
./configure prefix=$HOME LDFLAGS="-L/opt/local/lib" CPPFLAGS="-I/opt/local/include"
make -j8
make install
=> puts gdb executable into ~/bin; (static) libraries into ~/lib; documentation into ~/share
Then follow André's tip above to do the code signing; though it will now be
codesign -fs gdb-certi ~/bin/gdb
For months I've been running Eclipse Juno with CDT to debug my C++ code. Up to a couple weeks ago (when I last tried to debug) everything was working fine. Recently I upgraded my eclipse juno installation to the latest. Building and executing the code in eclipse works fine. But now when I try to launch the eclipse debugger I get the following error:
Error in final launch sequence
Failed to execute MI command:
-break-insert -t -f main
Error message from debugger back end:
Cannot access memory at address 0xfffe9900
Cannot access memory at address 0xfffe9900
I've tried searching online for this error without success. I'm wondering if anyone has any ideas about how to address this.
My environment:
I'm running on Mac OSX El Capitan 10.11.6
My xcode version is: Version 8.0 (8A218a) (with Command line tools installed)
My Eclipse info is:
Eclipse IDE for Java Developers
Version: Luna Service Release 2 (4.4.2)
Build id: 20150219-0600
CDT Version: 8.6.0.201502131403
My Eclipse CDT Tool chain Editor looks like:
Current toolchain: MacOSX GCC
Current builder: Gnu Make Builder
I'm running with GNU gdb (GDB) 7.6.2
This GDB was configured as "x86_64-apple-darwin13.0.0"
I'm guessing that there is some sort of gdb version issue. I'm using whatever gdb version that xcode dropped into /usr/local/bin/
Any ideas would be appreciated.
Thanks, Mike
.
.
.
.
.
Ok. So I ran gdb from the command line and it's behaving a little strangely. If I set a breakpoint anywhere within the main program it results in an error, such as, Cannot access memory at address 0xfffe9900. If instead I set a breakpoint in a function in an external file then run it goes to the proper breakpoint and accepts step, print, continue,.... For some reason I cannot set break points in main without getting the error, Cannot access memory at address 0x............. I'm compiling all the codes (including my main) with the -g option. BTW the error, Cannot access memory at address 0x......... is the same as what I'm getting from eclipse debugger. So it looks like it cannot access the main code memory for whatever reason. I haven't changed my make file either. The only things that changed possibly is gcc and gdb.
I've always worked around the debugger issue, but now it has gotten too annoying. I'm working on more complex programs and can't anywhere if I cant debug my programs. Has any one else been able to fix this issue in eclipse? It works for java, but not more my C++ plugin from minGW
Debbugger for C++ eclipse gives the following error. 'Launching program name' has encountered a problem. Error while launching command: gdb --version
Assuming you are using Windows and have MinGW installed, you only need to locate the gdb executable in the MinGW bin folder. This can be done on the "Main" tab in the "Debugger" configuration of Eclipse:
I am trying to use Eclipse CDT with Cygwin, but I have problems with the debugger. I have done the following:
- installed Eclipse CDT
- installed Cygwin with gcc, g++ make and gdb
- added c:\cygwin\bin to PATH
- created a new Hello World application in Eclipse
Compiling went well from Eclipse. The first problem was that I had to set the executable manually in the run configuration. Having done this, I running also worked. But when I try to debug, I get the following error:
When I switch to debug perspective, I can see the following:
I tried different debug configurations, but I always get the same result.
First, make sure gdb is located on c:\cygwin\bin. I believe executing which gdb on cygwin might help you do that.
Now, instead of adding this information to PATH and making it available to all your Windows applications, try adding it to your project settings inside Eclipse, like this guy did:
http://www.benjaminarai.com/benjamin_arai/index.php?display=/eclipsecygwingcc.php