I'm debugging the goldfish android kernel (version 3.4), with kernel sources.
Now I found that gdb sometimes jump back and forth between lines, e.g consider c source code like the following:
char *XXX;
int a;
...
if (...)
{
}
When I reached the if clause, I type in n and it will jump back to the int a part. Why is that?
If I execute that command again, it would enter the brackets in the if.
If possible, I want to avoid that part, and enter the if directly (of course, if condition matches)
When I reached the if clause, I type in n and it will jump back to the int a part. Why is that?
Because your code is compiled with optimization on, and the compiler can (and often does) re-arrange instructions of your program in such a way that instructions "belonging" to different source lines are interleaved (code motion optimizations attempt (among other things) to move load instructions to long before their results are needed; this helps to hide memory latency).
If you are using gcc-4.8 or later, build your sources with -Og. Else, see this answer.
I searched but can't find a good solution. Is that possible,why?
LLDB doesn't support breakpoint commands that can run the debugee a bit and then perform further steps. The breakpoint commands terminate when the debugee starts up again. So you can't use breakpoint commands to do this. This is a restriction that will be fixed at some point but it is not a trivial piece of work.
However, lldb also has a "scripted step" feature that allows you to craft your own custom step operations. You could use that to work around this restriction. The FinishPrintAndContinue in the examples file:
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/scripted_step.py
is almost what you want. You just need to change the continue to check the return value (using SBThread::GetStopReturnValue) and then continuing or stopping depending on the result. Then you could put a breakpoint on the function in question and adds a command that runs this fancy step.
I'm debugging some ANSI C code with gcc44 and gdb, on a 64bit Linux CentOS 5.7 server.
Around the middle of one of my functions, I have a for loop that loops 192 times (there are 2 lines of code in the loop). If I setup gdb with a breakpoint at the start of the for loop, I can step through the for loop all 192 times and it exits the for loop and continues into the next line of code after the for loop. This is all stepping through the code in gdb using "s" or "n". Everything works fine.
Now, instead of stepping through the for loop using "s" or "n" to get to the next line of code after the for loop, I start gdb and then set a breakpoint at the line just after the end of the for loop. If I then press "c" in gdb, it gives me "Program exited normally". I expected gdb to stop at this breakpoint located on the line of code just after the for loop. (!?)
As another experiment, I learned that gdb DOES successfully stop on any breakpoint set on any line after the line of code immediately following the for loop.
Maybe others have had this experience judging by questions such as this (there are 2 additional references therein):
gdb error "Program exited normally"
It's repeatable in gdb. Without digging into the code in question, anyone seen this behavior before and/or have any idea what I could check?
EDIT 1
If I include a printf("\n"); on the breakpoint line that gives problems above, moving what used to be on that line to one line below this printf code, then everything works fine (e.g. gdb stops on the printf line).
I can even set a breakpoint successfully on the previously-problematic line of code in question, which is now the next line after the printf line. Weird!
Your compiler is playing tricks on you.
Well, not really, but it's not doing exactly what you suspect.
A first principals concept of the compiler would be to sequentially turn every line of C into one or more assembly instructions, and execute the assembly in the same order as the C code.
In reality the compiler will reorganize things to optimize for speed or space. If an instruction is deemed to have no net effect on the program state it could be removed completely. Thus when you tell GDB to break on that line, well.. there is no assembly instruction with debugging information pointing to that line of C.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I had my code working earlier in the day on the unix machine, but when compiled under windows it gave me completely strange and incorrect output.
Since our code is going to be marked based on compilation on unix I thought hey that's good enough. But now I just finished refactoring my code (basically just adding comments, getting rid of variables which were never used in the program and getting rid of some functions which I wrote to test the program) and now suddenly my code seems to be giving me the proper output on windows and wrong output on unix.
Note that I have done nothing to modify the functionality of the code.
After spending so many hours working on this banging my head against Seg Fault errors through the week, this last minute bug is going to put it all to waste. What am I supposed to do when the bug is seemingly appearing at random?
Edit: The program is supposed to read a file similar to an html file and print out the tables. I'm loading the data of each individual cell onto a node in a Linked List and then printing out the info based on an algorithm. The output is working fine on windows now but not on unix. I don't even know what part of the code I need to look since I have no idea what's causing this.
Based on the amount of information you supplied (next to none), the best guess is to look for uninitialized variables. That will produce different output on different platforms, and is a common beginner mistake in C.
I suggest you use gdb to debug your code and check where the segmentation fault is arising. That will give you a good hint of were to start looking, even though you don't remember to have done any modification.
There is plenty documentation on the web.
These are the basics:
shell> gdb myprogram
gdb> backtrace #lists the steps until the segmentation fault arises
gdb> select 2 #You can select any step you want (e.g. 2)
gdb> print number #print variables to hack around
There are a lot of features for gdb. I think this will give you a hint quickly.
Don't forget to use a version control system the next time. It's a safe and nice way of having your code organized and clean, and off course!, to avoid these terrible accidents.
(SVN or GIT are cool enough)
Step 1, make a copy of everything.
Copy the entire project somewhere. Make a note of what state the project was in when you made that copy and the date:time. DO NOT edit that copy. You may even make the files unwritable if you want. You need to be able to see what you have changed as well as go back to it. Even though the program does not currently work on Unix, it does work under Windows, so you know that it does have some merit and is close to being useful to turn in. When I get upset at a program I am writing or at the compiler for not understanding it (this happens a lot less now then it did 10 years ago) I tend to lose track of what all I am changing, so changing it back becomes difficult. Using some type of version control (even just keeping extra copies around) will help you to keep track of what you have changes so when you make a mistake you can unmake that mistake pretty easily. Differencing tools, like diff are very helpful when you know how to use them. For right now you might want to try:
diff --minimal --side-by-side --ignore-all-space old_file.c new_file.c | less
Hopefully you are using a diff that supports those options because I think that they may be the most helpful for you in the short time that you have. If you find that you need to fit more on the screen and your terminal window is large you can also add in the --width= command and give it a number of characters in a line on your terminal.
Anyway, make and keep lots of copies of your code until you know that you won't need them anymore (and maybe even then).
If you have graphical access see if kdiff3 is available. It may be easier for you to use quickly. The 3 in its name refers to the ability to compare 3 versions of a file at one time (a common starting point and two edited versions of that file) and is useful, but you can learn about that later. It is perfectly able to compare just two versions of a file and produce decent output.
Step 2 Don't ignore warnings
I suggest that you compile it with the highest warning level possible with your compiler and DO NOT ignore any warnings. If you already have warnings without telling the compiler to issue more warnings then examine those first. Warnings are there for a reason, and only occasionally should you ever encounter code the produces warnings that should just be ignored (and even then I usually add a comment about the expected type of warning and why it is not an error). With gcc you can add the -Wall option to the compile command to issue all warnings.
gcc -Wall my_program.c -o my_program
Some may not make sense to you, but you can at least look at the code and see what might be unclear about it in the vicinity of the warning line.
step 3 Use simple lines of code
Something that will make warnings easier to understand is using very simple to understand lines of code. Trying to fit too much functionality into one line of code makes it so that any warning or error message about that line of code is much more difficult to understand.
step 4 Use temporary variables
Temporary variables don't necessarily mean "my program uses more memory" but they do often mean the compiler gives more meaningful warnings because the data-types of variables in expressions are much clearer.
step 5 Use functions
This is just a continuation of the philosophy from 3 and 4. Functions make things easier to understand. They also make it so that often when you find an error and fix it you don't have to worry about having copies of the erroneous code elsewhere in the program that also needs to be fixed (though you should still search for similar code just to be sure).
step 6 assert
There is a macro (like a function, but not quite) called assert that lives in #include <assert.h> and can help you find all kinds of errors by making your program fail earlier than it otherwise would. This sounds bad, but very often (especially with memory related problems like segmentation faults (SIGSEGV) ) programs are in a fatal state well before they die. Using assert helps you to move their death to an earlier place so that you can see what their fatal mistake was, rather than just seeing the result of it.
assert takes as its parameter a boolean expression -- any comparison, integer, floating point number, or pointer will do. Anything that you could use as a condition in an if or while will do. If this expression is false (0 or NULL) then your program will die right there and on many systems it will give you a helpful error message about where the assertion that killed the program was located and maybe even what the assertion was. There is another helpful thing that this causes which I'll talk about in a little bit, but for now, to use assert you just do:
assert(x < y);
and if x is not less than y the program will abort (actually call the abort function).
This is helpful for things like:
int clear_buffer(char * buffer, unsigned len)
{ /* len should be size_t but I don't want to explain that right now */
assert(buffer);
memset(buffer, 0, len);
}
Step 7, Use a debugger
If you have gdb on your Unix system then GREAT. If not, you probably have some other debugger than you can learn how to use. Many Unix C compilers take the -g option to mean "include debugging symbols", so add that to the other options you are passing to the compiler and recompile your program, and then do:
gdb ./myprogram
Which will print some stuff and then prompt you with:
(gdb)
Then you can set break points and all kinds of good stuff, but since you are in a hurry and getting crashes just do:
(gdb) r
Include any arguments after the r that you would be passing to your program when you normally ran it. gdb will then run your program until something odd happens. The something odd, in this case, should be a SIGSEGV (what UNIXes do to your program when it tries to access memory addresses that it shouldn't). gdb will then prompt you with (gdb) again. You can then do:
(gdb) bt
bt stands for back trace and gdb will print out the call stack, meaning all functions that were called to get to the current function. You should see main near the bottom. Look for the first function near the top that is a function you wrote. This is where you need to start trying to find errors. If the top function on the list is not one of yours then try issuing:
(gdb) up
Which will make it examine the previous function on the call stack. Once in one of your functions say:
(gdb) list
And it will show you some code around the area where things are wrong.
To exit gdb you do:
(gdb) quit
And answer Y if it ask you if you really want to quit.
If you were to use assert and that killed your program then you would not end up with quite as much library stuff on top of the call stack to confuse you.
Sadly 3, 4, and 5 mess up the ability to get good info from diff so I suggest trying to limit your adding of this programming style into places where you are having errors or warnings already (at least for now).
I hope that this helps
First of all, we will need your code to see what's going on. But if what you described is true then it is most likely that your code contains what's called undefined behavior. Undefined behavior can occur due to too many reasons, such as crossing array boundaries, incorrectly deleting pointers etc.etc. So, without code nothing can be said
Run it through valgrind.
I can guarantee you will find your error with valgrind.
If you've got access to a unix or linux machine, you should never release code that you haven't run through valgrind, even if the code works.
With the data you've provided, here is my solution.
Take a break and zone out of the problem domain for a while.
Use a debugger, step through the program, identify where it is segfaulting.
Print data at the point of the segfault and validate it.
That should solve the problem.
Compile your code with all warnings on.
Don't hide warnings with bogus casts, but take them seriously and resolve the real problems.
Use different compilers. On linux clang is a good alternative and gives way more indications than gcc.
How to protect c++ output file(pe file) from editing using crc(Cyclic Redundancy Check)?
**Best Regards**
You can use CRC's to effectively check to see if a file was accidentally altered, but they are not effective for copy protection, or preventing cheats on a game.
Usually, when I program has some sort of CRC check, I find the code which does the check, and change the assembly instruction from a conditional branch to an unconditional branch. This is usually quite easy to find, because normally after a CRC fail, the program displays a message and exits. I place a break point when the message occurs, and examine all the frames in the stack. I then put break points on each point in the stack, run the program again, and see which one does the CRC check.
This isn't particularly difficult, and people often bundle little programs which will apply the same changes to the software of your choice.
You need a static variable in your code. The variable needs to be initialized to a value that can easily found with an hex editor (e.g. DEADBEEF)
you need a crc-algorithm (try searching google)
The tricky part. You need to get pointer in memory to the start and to the end of your exe. You can parse the pe file header for the code location and run the crc-algorithm from start of code to end of code. Then you have the value.
Of course you have to check the calculated value with the one in the static variable.
Inserting the value - depending on how often you build, you might want to programm a tool. You can always run your program and set a breakpoint on the comparison. Then you note down the value and hex-edit it into the executable. Or you create a standalone program that parses the pe-header as well, uses the same function (this time on the file) and patches it in. This could be complicated though, because I don't know what is changed by the OS during loading.