6
I've just found that if you right click on the tab for the program, the menu list includes an option 'Run this program', this opens a new terminal and runs the program using the debugger.
4
EDIT September '16
The latest version of the IDE (69-ish) has a new utility called debug50.
I can't find a way to get the button back, but you can run the GUI debugger this way:
In View uncheck Less Comfortable. That will give more options in menu bar, specifically a Run tab and the green "> Run" button. When I tried the green Run, it did in fact invoke ...
3
CS50 has now released debug50 a more stable version than its predecessor. You can also manually use gdb through the command-line with; gdb OBJECT-FILE (where OBJECT-FILE is a vigenere.o, or just vigenere). Inside of which you can type r for run, n for next, c for continue, and b followed by a line number or function, such as b 50 (breaks line 50) or b foo (...
3
Here is a CS50 short on gdb. debug50 is essentially a GUI wrapper for gdb. As Doug mentions, if you are not in a CS50 IDE environment, it would be the goto for debugging.
valgrind will basically tell you where to look for problems (memory leaks) in the code. It really shouldn't matter which debugger you use to track down such problems.
IMO it is never a ...
2
See the image below:
Note the command window. After I ran "Debug" once, I had to add the command-line argument "bacon" in order to get vigenere to run. I can simply edit the command box with any relevant command-line arguments and hit "Run" again for it to debug properly.
2
The graphical debugger seems to have problems with code that opens other files. You should use the command line gdb instead in these instances.
2
GDB should be a very useful tool for debugging server. The waiting is the hardest part. Remember server will be waiting for input from a browser/curl to process something or waiting for gdb to continue processing. If it seems to be doing nothing, it probably is waiting. BTW the way to use gdb on a program that requires arguments is something like this:
user@...
2
That's because you're trying to store the character at the 1st index of a char array (string), node, into an int variable directly, without converting it into an int first. So the 5 in your example is being treated as the character '5' and not the integer 5, and like storing any other character into an int variable, its ascii value gets stored in octave1.
2
You need to pass GDB the complete path to your program, THEN whichever arguments you need.
Correct format: pset4/bmp/copy.c smiley.bmp copy.bmp
1
It depends on who you ask you will tell you one thing or another, as far as their differences, apart from the obvious, at an elementary level they do practically the same thing. Regarding my preferences I prefer gdb from the command line. It is not wrong to learn gdb from the command line, in some debugging environments it may be the only tool available.
1
Ok, I did find out the answer to my problem, I allocated size 6 to array filename but in the sprintf() function, memory has to be allocated to the "%" operator and the null value as the copied string should have a "\0" at the end, making the total array size to be minimum 8, the program compiled and ran as expected on making the change.
1
The IDE has changed since some videos were made. debug50 is the new debugger tool that was introduced in the fall. There is also a section on debug50 in the week2 lecture at around 22 minutes.
1
The lastest version of the IDE has a new debug50 utility.
1
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 ...
1
I had the same problem. The only way I've been able to use the graphical interface is to run debug50 ./programname from the terminal.
An alternative would be to use gdb from the terminal which there's a CS50 section on: https://www.youtube.com/watch?v=y5JmQItfFck
1
I think this is a common problem, you are not the first to post this issue and I have had similar issues. I never really fixed the problem but it resolved itself after some time.
You can still use GDB in the console for debugging your code. I strongly suggest you read the man page, and watch the videos if you haven't, so you know how to use it properly.
...
1
I had the same problem. What seems to be working for me is running debug50 ./programname from the terminal.
1
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 ...
1
Here is a sure fire way to duplicate your result:
dictionary.c and speller.c open in editor
click Debug from dictionary.c
Say "Oops!" [optional]
switch to speller.c tab and click Debug
Watch CPU climb to 100%
This sequence leavse a gdb running, and the only way I have found to get rid of it is to kill it from a command line. Here's one way:
Stop and close ...
1
I don't think anyone has figured that one out. It may not be possible, but I would be happy for someone to prove me wrong.
OTOH, why do you want to work with so much input data in the debugger? Wouldn't you be better off manually entering data as you step through the program, and restricting the data input to only 3 or 4 elements in the list? Inputting 50 ...
1
If you are having problems with the graphical debugger in the CS50 IDE (as I did!) then you should learn to use GDB from the command line, as others have suggested. There are two reasons to do this: it works better, and you may not have access to the Cloud9 IDE if you find a future job as a C programmer.
Google "cs50 gdb youtube" and you should be all set ...
1
I found this happens if you launch the debugger from dictionary.c instead of speller.c. I also found a couple of remedies.
First: set your breakpoints in dictionary.c then launch Debug from speller.c
Second: If you do launch from dictionary.c, there is a Command: field in the debugger tab. Change it from pset5/dictionary.c to pset5/speller.c [arg-1] arg-2 ...
Only top voted, non community-wiki answers of a minimum length are eligible
