Print Page - Cannot start gdb debugger under Mac OS X (Can't launch console)

User forums => Help => Topic started by: dullin on December 05, 2014, 03:46:43 am

Title: Cannot start gdb debugger under Mac OS X (Can't launch console)
Post by: dullin on December 05, 2014, 03:46:43 am

I'm trying to use GDB with code blocks on Mac OS X Yosemite 10.10.1.

I have installed GDB using homebrew with the instructions described here : http://wiki.lazarus.freepascal.org/GDB_on_OS_X_Mavericks_and_Xcode_5

I have included the path of gdb (/usr/local/bin/gdb) in the Settings -> Debugger ->GDB/CDB Debugger -> Default -> Executable Path

Everything seems to be ok on the configuration end.

But, when I try to debug an application, I get the following error :

Code

Building to ensure sources are up-to-date

Selecting target: 
Debug
Adding source dir: /Users/dullin/Documents/Programs/final_A14/
Adding source dir: /Users/dullin/Documents/Programs/final_A14/
Adding file: /Users/dullin/Documents/Programs/final_A14/bin/Debug/final_A14
Changing directory to: /Users/dullin/Documents/Programs/final_A14/.
Set variable: DYLD_LIBRARY_PATH=.:
Starting debugger: /usr/local/bin/gdb -nx -fullname  -quiet  -args /Users/dullin/Documents/Programs/final_A14/bin/Debug/final_A14
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Can't launch console (osascript -e 'tell app "Terminal"' -e 'activate' -e 'do script ""' -e 'end tell' sleep 80067587)
Debugger name and version: GNU gdb (GDB) 7.8.1
No stack.

The problem seems to be invoking the Terminal window correctly with gdb attached because of the following error :
Can't launch console (osascript -e 'tell app "Terminal"' -e 'activate' -e 'do script ""' -e 'end tell' sleep 80067587)
When starting to debug, a terminal window opens but no commands are executed from it.

The same command is passed when I normally run my application (which goes fine) with the following command :

Code

Executing: osascript -e 'tell app "Terminal"' -e 'activate' -e 'do script "/Applications/CodeBlocks.app/Contents/MacOS/cb_console_runner DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:. /Users/dullin/Documents/Programs/final_A14/bin/Debug/final_A14 "' -e 'end tell'  (in /Users/dullin/Documents/Programs/final_A14/.)

I have found an old post (http://forums.codeblocks.org/index.php?topic=18068.0) that had the same problems but seems to offer no solutions.

Is it a bug within code blocks or a misconfigured system? Is it normal that the 'do script' has no argument when launching the debugger?

Title: Re: Cannot start gdb debugger under Mac OS X (Can't launch console)
Post by: oBFusCATed on December 05, 2014, 10:32:25 am

Please next time do a search about your problem.
You'll see that it is reported very often.
There is a minimal chance that this bug is fixed in the latest night builds.
Unfortunately we have no dev that runs OSX and so there are no night builds for it, you'll have to build from source.

Title: Re: Cannot start gdb debugger under Mac OS X (Can't launch console)
Post by: ridge on January 08, 2017, 03:36:28 am

70 x 50 + 30 x 50 = 100 x 50
Alaska Mileage 170 807 943

[SOLVED]
I know this is an old post but I haven't been able to use the debugger for more than 4 years !
Now, I finally have debugging working in CodeBlocks on MacOS!

I will describe what I did to get the debugger working in CB.
This is a long post but it takes some effort to get debugging working in CB.

I had lots of trouble with the latest versions of CB (on MacOS).
So, I'm using CodeBlocks v13.12.
To prevent frequent CB crashes, I used the Plugins Manager, to disable
"Code Completion" and "Keyboard Shortcuts".

I had some trouble using gdb with Terminal so, I installed iTerm2 (see below).

Assumptions:
- I assume you have installed the Xcode command line tools:
See Guide: http://osxdaily.com/2014/02/12/install-command-line-tools-mac-os-x/

- I assume that you can create and run projects successfully in CB
(without using the debugger).

- I assume you can use Terminal (or iTerm2) to execute command-line commands.

- I assume you are using bash shell and have .bash_profile in your home folder.
(If you're using another shell, modify instructions accordingly.)

Installing Homebrew, iTerm2, xQuartz and gdb
--------------------------------------------

(Note: > represents your command-line prompt)

Launch Terminal (in /Applications/Utilities)
Example: Use Finder to navigate to /Applications/Utilities and double-click on Terminal.app

Install Homebrew:
(Here is one method of installing HomeBrew, you might prefer some other method.)
> /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Install iTerm2:
> brew install --cask iterm2
(You should not see any errors and you should accept any dependency installations)

Now, launch iTerm2 for the following (very similar to Terminal, close your Terminal now)
Example: Use Finder to navigate to /Applications/Utilities and double-click on iTerm.app

Install xQuartz (so we can use xterm below)
> brew install --cask xquartz
(You should not see any errors and you should accept any dependency installations)

Install the latest version of gdb
Example: I originally installed gdb v7.12_1 (now, I'm running gdb v10.1):
> brew install gdb
(You should not see any errors and you should accept any dependency installations)

Edit your ~/.bash_profile and modify the PATH variable to include /usr/local/bin.
This is useful when launching gdb from the command line to verify gdb is working properly.
gdb will be installed in /usr/local/bin.
For example (in your .bash_profile, add/modify your PATH variable):
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
export PATH

Now, update your path in your current iTerm2 session:
> source .bash_profile
(If you get errors, carefully examine the lines you changed and try again.)

Code-sign the gdb binary and then kill taskgated:
Suggestion: Follow code-signing instructions contained in this guide:
https://sourceware.org/gdb/wiki/BuildingOnDarwin

Launch CodeBlocks v13.12
Create a simple console Hello World project to ensure CB v13.12 is installed and working properly:
I created a project called "Hello".
You should see the following in the source file:
#include <iostream>

using namespace std;

int main()
{
cout << "Hello world!" << endl;
return 0;
}

In the bar menu, go to: Settings->Environment
You will probably see the following in the box labeled "Terminal to launch console programs":
osascript -e 'tell app "Terminal"' -e 'activate' -e 'do script "$SCRIPT"' -e 'end tell'

Replace the osascript line with:
/opt/Xll/bin/xterm -e $SCRIPT

Verify your Hello project works (click GUI button "Build and Run" or use bar menu: Build->Run).
(An xterm window should pop up with Hello World in it. Press <RETURN>, window disappears.)

In the CB bar menu, go to: Settings->Debugger
Click on Default and set Executable path: /usr/local/bin/gdb
Click OK.

Note: A warning window popped up on my system:
"The compiler plugin must always be loaded for batch builds!
Automatically re-enabled."
(Just click past this.)

Now, close CB (this will save the settings).
Then, launch CB again.

Debug Session
Now, make sure your Hello World project is in Debug mode (not Release mode).
Again, build and run to verify the program is working properly in Debug mode.
(An xterm window should pop up with Hello World in it. Press <RETURN>, window disappears.)

Now, set a breakpoint on the line containing "return 0" (line 8).
Note: You should see a red stop sign appear just before line 8.
Ways to set a breakpoint:
Click in "the gutter" just before the line 8.
Click on line 8, use the bar menu Debug->Toggle Breakpoint
Click on line 8 and press F5.
Click on line 8, right click (ex. ctrl-click), menu appears, select Toggle Breakpoint

Start the debugger.
Click the Red Arrow button (GUI bar) or use the bar menu (Debug->Start/Continue).
You should see a small yellow triangle appear on the red stop sign.
Click on the Red Arrow button to continue. Press <RETURN>, windows disappears.

Note: When mine worked, I got the following messages in the CB debugger window:
--------------------------------------------------------------------------
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: /Users/ridge/Documents/workspaceCodeBlocks/Hello/
Adding source dir: /Users/ridge/Documents/workspaceCodeBlocks/Hello/
Adding file: /Users/ridge/Documents/workspaceCodeBlocks/Hello/bin/Debug/Hello
Changing directory to: /Users/ridge/Documents/workspaceCodeBlocks/Hello/.
Starting debugger: /usr/local/bin/gdb -nx -fullname -quiet -args /Users/ridge/Documents/workspaceCodeBlocks/Hello/bin/Debug/Hello
done
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 10.1
At /Users/ridge/Documents/workspaceCodeBlocks/Hello/main.cpp:8
Continuing...
[Inferior 1 (process 24958) exited normally]
Debugger finished with status 0
--------------------------------------------------------------------------

If yours works, everything's fine, congratulations, you're done, bye.

However, sometimes, there are problems (I've experienced several).

Problems:
- I don't see an xterm window.

- The xterm window appears but the following message appears:
warning: GDB: Failed to set controlling terminal: Operation not permitted

- The xterm window and warning appear but "Hello World!" does not appear.

- The xterm window, warning and "Hello World!" all appear but when I tell
gdb to "continue", nothing happens. CB doesn't seem to regain control or
CB is not responsive.

If you experience such problems, here are some possible solutions:

There may be a gdb process still running which may prevent gdb running properly.
So, you need to kill gdb as well as the child xterm window (if it exists).
In your iTerm2 window, kill any/all gdb processes:
(Note: replace "ridge" below with your username)
> killall -u ridge -9 gdb

CB may have gotten into some strange state when spawning gdb.
(So, close and re-launch CB and start above at "Debug Session")

gdb may not have gotten properly code-signed, so check it:
(Note: my certificate is named gdb-cert)
> sudo codesign -s gdb-cert /usr/local/bin/gdb
Password: ********** (root password)
(Note: No output means gdb is code-signed. Or, you may get a message
indicating whether or not gdb is code-signed. If there are problems,
repeat code-signing procedures above.)

gdb may not be working properly outside of CB.
So, let's check it.

First, make sure the Debug version of your project is freshly built
and then run your Debug project directly in the iTerm2 window:
(Note: this example is for my project, modify the path to your project)
> /Users/ridge/Documents/workspaceCodeBlocks/Hello/bin/Debug/Hello
You should see "Hello world!" in the iTerm2 window.

Second, make sure you can find gdb and you're using the correct gdb:
> which gdb
(Make sure the found path location is /usr/local/bin/gdb.
If it's not, repeat gdb installation procedures above.)

Third, run gdb with your debug version of Hello in an iTerm2 window:
(Note: this example is for my Hello project, modify the path to your project):
/usr/local/bin/gdb -nx -fullname -quiet -args /Users/ridge/Documents/workspaceCodeBlocks/Hello/bin/Debug/Hello
(gdb) list (Note: show the next few lines of code to be executed)
(gdb) b 8 (Note: set a breakpoint at line 8)
(gdb) r (Note: run to first breakpoint)
(gdb) c (Note: continue)
(gdb) q (Note: quit)

If the gdb session works properly, after entering 'r' above, you should see
Hello World! (along with other output).

If the gdb session above does not work properly, you need to solve that problem
before trying to run in CB:

taskgated may not be running or you may not have rebooted after code-signing gdb.
So, just shutdown entire system (reboot) to restart taskgated.

If gdb is code-signed and taskgated is running and you start debugging using CodeBlocks,
a popup window will appear asking for credentials (super-user password).
(Note: The popup window that asks for credentials should appear only once.)

Occasionally, I still have problems using the debugger in CB. So, I kill
any/all gdb instances using killall (see above). Then, I run the Debug executable
directly in an iTerm2 window and, finally, run gdb on the Debug executable
directly in iTerm2. After that, I can use the debugger in CB again.

I hope this posting helps others.
I hope someone else can come up with more solutions for people who have problems
that I haven't covered here.
I hope this helps a CB developer make the debugger work "out of the box" on MacOS.

Code::Blocks Forums

User forums => Help => Topic started by: dullin on December 05, 2014, 03:46:43 am