Google "cs50 gdb youtube" and you will find two helpful videos explaining how to use the debugger from the command line. It's much more reliable, and has the added benefit of being a tool that will always be available to you in the future even if you do not use the Cloud9 IDE for development.
Basically, to debug
myprog with a breakpoint at
myfunc, passing arguments
arg2, do the following:
run arg1 arg2
After that, you can step forward with
n, or step into a function with
info args to view arguments,
info locals to view local variables, and
p foo to print the value of variable
To debug functions in multiple files, set your breakpoints and then as you are stepping through statements with
n, pay attention and when you get to the line that calls the externally-defined function, step into it with
EDIT: Downvoted for this advice? Really? I'm surprised.
I'm back at my desk now, and I can see your screenshot more clearly than I could on my phone. Now, I can see that you are trying to debug
count.c from Module 1.
I can remember what it was like to start Module 1. I felt over my head at first, and I'm sure you probably do too.
I apologize if I gave you advice that was more appropriate for your future self! In Module 2, you will learn about functions, arguments, and all the other jargon I used above. :)
I decided to take a crack at the graphical debugger myself just to see if I could help you better. I set a breakpoint on line 23:
int main(void). Then, I clicked the "Run" button and it looked as though everything was paused, just as you described.
That's because the program was paused. Its execution was suspended at my breakpoint. This is exactly what's supposed to happen!
Then, I clicked on the "Resume" button. It's a blue triangle that looks like a "Play" button on a CD player, and I found it at the top left corner of the right sidebar.
Clicking this caused the triangle to change into two vertical bars, like the "Pause" button on a CD player. It also caused my program's execution to Resume, and then I had to look down at the bottom to see that the program had printed a prompt and was waiting for my input. It said
Please enter a number: and
GetInt() was waiting for me to enter a number!
Hopefully this helps you to run the graphical debugger. Come back and read my initial advice when you are working on pset3 -- it will make much more sense to you then!
EDIT2: I'm back on mobile and can't test this now, but I believe that the problem the commenter below is having has to do with running the debugger without any breakpoints. You have to set a breakpoint, or the debugger won't let you inspect anything during execution! Also, I stopped using the graphical debugger by Module 3, because I found it unreliable.
My original advice stands: get to know the command-line
gdb. You'll thank yourself later. I am certain that I would have been unable to complete some of the later problem sets (especially
server.c) without it!
If it's any consolation, other people are having this problem too, and the general consensus is that the Terminal debugger is much more reliable than the graphical debugger.