Trouble debugging C++ using Eclipse Galileo on Mac

Question

I am trying to debug C++ code using Eclipse Galileo on my MacBook Pro running Mac OS X v10.5 (Leopard). It's my first time trying this. I have a complicated C++ program I'd like to debug, but to test things out, I just tried to debug and step through the following:

#include <iostream>
using namespace std;

int main()
{
  int x = 0;
  cout << x << endl;

  x = 54;
  cout << x << endl;

  return 0;
}

I clicked the debug icon, told it to use GDB (DSF) Create Process Launcher and started to step through the code. I wanted to be able to monitor the value of x, so I opened up the Variables window and watched. Initially, it was 4096 - presumably some garbage value. As soon as I hit the next line, where it had shown the value, it now shows the following error:

Failed to execute MI command:
-var-update 1 var1
Error message from debugger back end:
Variable object not found

I can't seem to figure this out or get around it. And a few Google searches turned up bone dry without even the hint of a lead.

---

Solution: As drhirsch pointed out below, use the Standard Create Process Launcher instead of the GDB Create Process Launcher. (This is actually a workaround and not a true solution, but it worked for at least two of us.)

Answer 1

I've had similar problems with multiple versions of Eclipse on Ubuntu. One solution that has often worked for me is to use GDB version 6.6 rather than the latest versions.

Answer 2

OK, at the moment, using /opt/local/bin/fsf-gdb which is version 7.1, seems to do the trick! I did not test it extensively, but I can use breakpoints in very different functions, and the program stops there while debugging.

Answer 3

You can follow the instructions of page GDB on OS X Mavericks and Xcode 5.

Answer 4

This appears to still be a problem without a reliably good answer, other than using an IDE other than Eclipse.

I tried both the DSF Create Process Launcher and the Standard Create Process Launcher variations, but neither results in a successful debugging experience. The GDB debugger launches either way, but breakpoints are not handled properly (unresolved in some cases) and almost no variable values can be inspected/tracked.

Here's what software I'm using:

• Eclipse 3.5.2 (Galileo), 64-bit Cocoa version
• Eclipse C/C++ development tools 6.0.2.2
• Mac OS X 10.6.3 (Snow Leopard)
• GDB 6.3.5 (Apple's version that ships with Xcode)

I've also tried building GDB 7.1 from source since as of 7.0 it is supposed to have native x86/x86_64 Darwin support. It builds fine and launches OK from the command-line, but it has various problems when I try launching it from Eclipse. These appear to be related to changes that Apple made recently to how the taskgated mechanism works for allowing debuggers to connect to processes. The following error is typical of these:

Target request failed: Unable to find Mach task port for process-id 88283:
(os/kern) failure (0x5).\n (please check gdb is codesigned - see taskgated(8)).

Various sources on the web indicate that Apple uses their own special patches in GDB 6.3.5 to support Mac OS X, however this is a really old code base (2004). Conversely, other web sources indicate that the Eclipse DSF debugger framework requires GDB commands that only appear starting in GDB 6.6 (circa 2006?).

I've been all over the Eclipse-related forums but have found no signs of a solution to this problem. It appears that almost no one on the Eclipse CDT development team uses Mac OS X, so they rarely bother to test their changes on this platform.

EDIT UPDATE: In addition to the above, I've retried all of the prior described testing (GDB versions 6.3.5 and 7.1) with a developer build, Eclipse Helios 3.6 RC3 (IDE for C/C++ developers), which includes CDT 7.0. Encountered all of the same reported problems. Eclipse CDT debugging on Mac OS X Snow Leopard is still non-functional.

Does anyone know something different and/or a reliable Eclipse-based solution to the scenario I've reported above?

Answer 5

The same problem, but I might have found a way. In Eclipse, under the project properties, in Run/Debug settings, I deleted the launch configurations and ran the debugger again.

At that point everything worked correctly, although it takes at least 10 seconds to launch the debugger if I modify. I think it has to do with a combination of both the debugging properties and the launcher configuration.

Answer 6

In the future, you could also try using Xcode (just to debug) - drag all the files in to import them into a new project, but don't compile. Instead, open the debugger window and attach to your running process.