This can be tricky. I'll explain how to use GDB, and then show another way.
The commands below should be entered in a terminal window.
First, compile your program using make, then run GDB and tell it to load the find program, like this:
GDB will start and load the find program. From this point on you will be 'inside' the GDB program, and ...
bfType is an unsigned 16 bit integer (ie, 2 bytes long, aka a WORD).
What you are seeing is the fact that xxd displays byte by byte, but gdb displays the word.
So why does it matter?
Intel processors use what is called "little endian" to store bytes in memory. That means that the least significant byte is stored in the first memory address in the word.
I just solved this problem. I watched a GDB short by Nate Hardison from previous lectures and I found out that we were running a different command for using GDB. For Game of Fifteen, I was using "gdb -tui fifteen" which I saw on some lectures too but Nate used "gdb ./fifteen". When I tried Nate's, my GDB doesn't stop anymore. I can now type a number when "...
$2 = "elephant\n"
Looks like you are including the new line char in your word. This will cause all of the words to be misspelled, as the word sent to check will, of course, not include the newline.
Revisit your load function and make sure you don't include the newline.
To debug "find" with gdb, enter the following command:
You need to enter the filename of the executable as a parameter following gdb on the command line. Don't use ./ or .c when you enter the command on the command line. After that, the (gdb) prompt will appear. To run your program, simply enter r followed by whatever parameters you want to send ...
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.
What does it say in the new terminal window after "Runner:"? I suspect it says "Shell Command" or "Auto". A ".c" file cannot run in the shell. Has it been a while since you tried this? There used to be a debugger option for Runner, but I don't see it anymore. Perhaps it was deprecated when debug50 was released. Make sure you are on the latest version of the ...
We have a serious problem at the very beginning.
char* method_str = "";
I guess you want to write a blank, so write it for real. The lack of white space can cause segfault, or a strange behavior of the program. For example after using GDB (it can even be used in your program) we have the following result:
(gdb) p request_str
$2 = 0x438f46 ""
(gdb) p ...
Nevermind. I figured it out by rereading the course material and an answer to a previous question. Here is how:
1) type "gdb ./server" in your terminal window.
2) type "break parse" a the (gdb) command prompt.
3) type "run ./public" at the (gdb) command prompt.
4) Open a new terminal window next to the current one.
5) type "curl -i http://localhost:8080/...
To run GDB with arguments in the terminal, use the --args parameter.
gdb --args name arg1 arg2 arg3
debug50 (the graphical debugger) is just GDB with a GUI. GDB was originally designed to be run through the terminal, and still is. It is much more flexible than any graphical debugger.
Here's a complete reference guide for GDB:
Here's what I do. Use debug50 instead of the command line gdb. If you haven't used that before:
Run update50 to be sure you are up to date (the IDE is on version 81 at the moment). Then, here's part of this year's class where Prof Malan explains how debug50 works. https://video.cs50.net/2016/fall/lectures/2?t=22m20s (if it doesn't go to that timestamp, ...
I couldn't get the hang of the ide50 debugger either.
Launch gdb like:
Then to run:
r file1.bmp file2.bmp
In case you have more gdb related questions in the future, I use this site, and just control f whatever I need: http://www.yolinux.com/TUTORIALS/GDB-Commands.html
Notice the difference between the declaration of abs_path/query in main
char abs_path[LimitRequestLine + 1];
char query[LimitRequestLine + 1];
vs. the declaration in parse.
bool parse(const char* line, char* abs_path, char* query)
In main they are char arrays. In parse they are char*. Both your sample outputs should be expected. Both variables appear ...
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 ...
For my example, "mainP.c" will be our main program, and "secondP.c" will be your secondary file. I am assuming your "mainP" calls "secondP" at some time during the execution of the program.
This is how I would do it:
break secondP.c:1 //breaking at first line in secondP
First you run gdb for your mainP, and the you set a breakpoint ...
The problem is here:
isalpha() takes a single char as input. argv is a string. When you try to stuff a string into isalpha(), it chokes and seg faults.
If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)
At the bottom of your code, there is a place where your function will not return anything. That's probably around line 93 in your program, the line that clang complained about.
Now you need to follow the logic, either on paper or with gdb, to see what conditions(s) will get you to that spot. One pair of braces in your code stands out because of their ...
If you have been using breakpoints, and you don't want to continue using the same breakpoint use the command delete and all of your breakpoints will be deleted. If you only want to delete 1 breakpoint, then use delete # where # is your breakpoint number. If you want to know about other breakpoint commands use help breakpoints.
You can put a counter in the loop and set a breakpoint based on the counter. For example, say you had this program:
#includes go here ;-)
int main(int argc, string argv)
for (int i=0; i<10000; i++)
Now, let's say that the printf() is on line 10.
You start the program in gdb and set the following:...
ok... As I see it, your outer loop should only execute once. You actually fall in a pretty annoying situation where an absolutely valid and algorithmically correct piece of code is not doing what it is expected. This is because you are using the assignment = instead of the comparison ==. Change the while ((notsorted = 0)) with while (notsorted == 0) and you ...
Have you noticed that when the fifteen program starts up, the entire screen is cleared? Compare that to the other programs before this, which just display the output directly after the command line.
The reason for this happening is shown in the greet() function:
printf("GAME OF FIFTEEN\n");
Learning how to debug your code is as important as learning to code. As your programs get larger and more complex, they'll usually contain many logical errors. Unfortunately, compilers can't detect logical errors (but rather, syntax errors) and that's where the role of the debugger comes.
An example of a syntax error
int x = 10 // missing semicolon