This one is WTF city.
The below program is crashing after a few thousand loops.
unsigned long int nTurn = 1;
bool quit = false;
int main(){
while(!quit){
doTurn();
++nTurn;
}
}
That's, of course, simplified from my game, but nTurn is at the moment used nowhere but the incrementing of it, and when I comment out the ++nTurn line, the program will reliably loop forever. Shouldn't it run into the millions?
WTF, stackoverflow?
Your problem is elsewhere.
Some other part of the program is reading from a wild pointer that ends up pointing to nTurn, and when this loop changes the value the other code acts different. Or there's a race condition, and the increment makes this loop take just a tiny bit longer so the race-y thing doesn't cause trouble. There are an infinite number of things you could have wrong elsewhere.
Can you run your program under valgrind? Some errors it won't find, but a lot it will.
may sound silly, but, if I were looking at this, I'd perhaps output the nTurn var and see if it were always crashing out on the value. then, perhaps initialize nTurn to that & see if that also causes it. you could always put this into debug and see what is happening with various registers and so forth. did you try different compilers ?
I'd use a debugger to catch the fault and see the value of nTurn. Or if you have core dump from the crash load it into the debugger to see the var values at the crash time.
One more point, could the problem be when nTurn wraps round and goes to zero?
++nTurn can't be the source of the crash directly. You may have some sort of buffer overflow causing the memory for the nTurn variable to be accessed by pointer arithmetic when it shouldn't be. That would cause weird behavior when combined with the incrementing.
Related
I'm doing an intensive course in C++ and I am the kind of person that likes and wants to understand everything under the sun otherwise I can't continue with my homework.
char anything[5]{};
cin >> anything;
cout << anything << endl;
I can write 'Hello' in the console and it's all good. Writing 'H' is good too, and 'Hel' is good too. But what shouldn't be right is writing 'Helloo' or 'Hellooo', and it works! The moment I write 'Helloooooooooooooooooooooooooooooooo' program crashes, which is ok. This does the same when using numbers.
Why is this happening? I'm using CodeLite.
To my understanding, if I write over 5 characters the program shouldn't allow it, but it does.
What's the explanation behind this?
[trigger warning: car crashes, amputations, cats]
if I write over 5 characters the program shouldn't allow it, but it does.
That's an overstatement.
The language doesn't allow it, but the compiler and runtime don't enforce that. That's because it would deduct from performance to perform bounds checking all the time just to look out for programmer errors, penalising those who didn't make any.
So, you broke a contract and what happens next is undefined. You could fall foul of some "optimisation" in the compiler that assumes you wrote a correct program; you could overwrite some memory at runtime, getting a crash; you could overwrite some memory at runtime, getting an apparently "valid" string up to the next NULL that happens to be there; or, you could open a wormhole to the local cattery. You just don't know.
This is called undefined behaviour.
An analogy would be driving over the speed limit. Your car won't stop you from speeding, but the law says not to, and if you do it anyway you may get arrested, or run someone over, or lose control then crash into a tree and lose all your limbs. Generally it's best not to take the chance.
I'm debugging a large, ancient, piece of code that we just upgraded the OS/driver for, the entire thing is running 32 bit. The original developers of the code are long gone and much of it is still a black box to me.
I'm running it on the debugger. I narrowed down on a particular if statement within a larger loop, I need the 'else' part of the for loop to run to update some variables, but it was never running; implying that the variable that is being checked in the 'if' statement is always true.
Eventually I stepped into the method call (a simple getter on a private boolean) and printed the content of the variable. When I print the variable it is false, and the 'else' method will be entered when I return.
To experiment I've tried allowing the loop to run for 10 minutes, the 'else' method is never entered (as indicated by a breakpoint not being hit). Then when I print the variable being checked it's false and the variable is entered. It doesn't matter how long I let it run, or how many times I break and continue before printing the variable, the same pattern holds, I enter the 'else' method IFF I print the content of the variable that is being checked first.
To rule out some sort of datarace I've tried sitting at the breakpoint in question for the length of time it takes to do a print statement, a delay without a print doesn't result in entering the 'else' method.
What could cause such an odd behavior? Since we had issues with different architectures, running a 32 bit program on a 64 bit OS and, more importantly, the driver that it uses was not tested for 32 bit for years until they recompiled the driver for me under a 32 bit architecture, which would make me suspect the driver except that particular line of code that is misbehaving isn't touching the driver in any way. Still I suspect some sort of overflow or underflow may be happening due to a confusion caused by trying to force an old 32 bit program to run.
However, even assuming this could cause such an odd behavior, I don't know how to confirm if that is happening or otherwise debug a program where the act of looking at it changes it's behavior. I'd love any tip on what could cause such a problem or how I could move forward with debugging it.
Dammit Jim I'm a programmer, not a Quantum Mechanic!
It works when, in the loop, I set every element to 0 or to entry_count-1.
It works when I set it up so that entry_count is small, and I write it by hand instead of by loop (sorted_order[0] = 0; sorted_order[1] = 1; ... etc).
Please do not tell me what to do to fix my code. I will not be using smart pointers or vectors for very specific reasons. Instead focus on the question:
What sort of conditions can cause this segfault?
Thank you.
---- OLD -----
I am trying to debug code that isn't working on a unix machine. The gist of the code is:
int *sorted_array = (int*)memory;
// I know that this block is large enough
// It is allocated by malloc earlier
for (int i = 0; i < entry_count; ++i){
sorted_array[i] = i;
}
There appears to be a segfault somewhere in the loop. Switching to debug mode, unfortunately, makes the segfault stop. Using cout debugging I found that it must be in the loop.
Next I wanted to know how far into the loop the segfault happend so I added:
std::cout << i << '\n';
It showed the entire range it was suppose to be looping over and there was no segfault.
With a little more experimentation I eventually created a string stream before the loop and write an empty string into it for each iteration of the loop and there is no segfault.
I tried some other assorted operations trying to figure out what is going on. I tried setting a variable j = i; and stuff like that, but I haven't found anything that works.
Running valgrind the only information I got on the segfault was that it was a "General Protection Fault" and something about default response to 11. It also mentions that there's a Conditional jump or move depends on uninitialized value(s), but looking at the code I can't figure out how that's possible.
What can this be? I am out of ideas to explore.
This is clearly a symptoms of invalid memory uses within your program.This would be bit difficult to find by looking out your code snippet as it is most likely be the side effect of something else bad which has already happened.
However as you have mentioned in your question that you are able to attach your program using Valgrind. as it is reproducible. So you may want to attach your program(a.out).
$ valgrind --tool=memcheck --db-attach=yes ./a.out
This way Valgrind would attach your program in the debugger when your first memory error is detected so that you can do live debugging(GDB). This should be the best possible way to understand and resolve your problem.
Once you are able to figure it out your first error, fix it and rerun it and see what are other errors you are getting.This steps should be done till no error is getting reported by Valgrind.
However you should avoid using the raw pointers in modern C++ programs and start using std::vector std::unique_ptr as suggested by others as well.
Valgrind and GDB are very useful.
The most previous one that I used was GDB- I like it because it showed me the exact line number that the Segmentation Fault was on.
Here are some resources that can guide you on using GDB:
GDB Tutorial 1
GDB Tutorial 2
If you still cannot figure out how to use GDB with these tutorials, there are tons on Google! Just search debugging Segmentation Faults with GDB!
Good luck :)
That is hard, I used valgrind tools to debug seg-faults and it usually pointed to violations.
Likely your problem is freed memory that you are writing to i.e. sorted_array gets out of scope or gets freed.
Adding more code hides this problem as data allocation shifts around.
After a few days of experimentation, I figured out what was really going on.
For some reason the machine segfaults on unaligned access. That is, the integers I was writing were not being written to memory boundaries that were multiples of four bytes. Before the loop I computed the offset and shifted the array up that much:
int offset = (4 - (uintptr_t)(memory) % 4) % 4;
memory += offset;
After doing this everything behaved as expected again.
I have a program that behaves weirdly and probably has undefined behaviour. Sometimes, the return address of a function seems to be changed, and I don't know what's causing it.
The return address is always changed to the same address, an assertion inside a function the control shouldn't be able to reach. I've been able to stop the program with a debugger to see that when it's supposed to execute a return statement, it jumps straight to the line with the assertion instead.
This code approximates how my function works.
int foo(Vector t)
double sum = 0;
for(unsgined int i=0; i<t.size();++i){
sum += t[i];
}
double limit = bar(); // bar returns a value between 0 and 1
double a=0;
for(double i=0; i<10; i++){
a += f(i)/sum; // f(1)/sum + ... + f(10)/sum = 1.0f
if(a>3)return a;
}
//shoudn'get here
assert(false); // ... then this line is executed
}
This is what I've tried so far:
Switching all std::vector [] operators with .at to prevent accidentily writing into memory
Made sure all return-by-value values are const.
Switched on -Wall and -Werror and -pedantic-errors in gcc
Ran the program with valgrind
I get a couple of invalid read of size 8, but they seem to originate from qt, so I'm not sure what to make of it. Could this be the problem?
The error happens only occasionally when I have run the program for a while and give it certain input values, and more often in a release build than in a debug build.
EDIT:
So I managed to reproduce the problem in a console application (no qt loaded) I then manages to simulate events that caused the problem.
Like some of you suggested, it turns out I misjudged what was actually causing it to reach the assertion, probably due to my lack of experience with qt's debugger. The actual problem was a floating point error in the double i used as a loop condition.
I was implementing softmax, but exp(x) got rounded to zero with particular inputs.
Now, as I have solved the problem, I might rephrase it. Is there a method for checking problems like rounding errors automatically. I.e breaking on 0/0 for instance?
The short answer is:
The most portable way of determining if a floating-point exceptional condition has occurred is to use the floating-point exception facilities provided by C in fenv.h.
although, unfortunately, this is far from being perfect.
I suggest you to read both
https://www.securecoding.cert.org/confluence/display/seccode/FLP04-C.+Check+floating-point+inputs+for+exceptional+values
and
https://www.securecoding.cert.org/confluence/display/seccode/FLP03-C.+Detect+and+handle+floating-point+errors
which concisely address the exact question you are posing:
Is there a method for checking problems like rounding errors automatically.
For the actual question, jump to question part. For an interesting real-world example of undefined behavior, keep reading :)
There was this enumeration:
struct EnumStruct
{
enum Enum
{
val0 = 0,
val1,
val2,
val3,
val4
};
};
and in some function we had this:
const int arrayCount = 6;
int arr[] = {
EnumStruct::val0,
EnumStruct::val1,
EnumStruct::val2,
EnumStruct::val3,
EnumStruct::val4
InvalidValue
};
Then there was a loop that put arrayCount elements of the arr into a file. This was the Prepare() routine for the unit tests. And the unit test was supposed to check for the presence of the InvalidValue in the file. I was assigned a defect stating that the unit test fails. It worked perfect on my machine though. After a couple of hours of debugging I noticed that InvalidValue is actually #defined as -1, and there is a missing comma after val4. You can only imagine the swearwords that came out of my mouth in the address of whoever wrote that code (which worked perfectly for more than 3 years, actually).
Now, as you can see, the array is actually comprised of 5 values - 0, 1, 2, 3, 3 but the loop writes to the file the 6th element as well, which is of course Undefined Behavior. Now, while technically it is undefined, on Windows with MSVC no crashes happen - it just writes the garbage that is at that memory location. The thing is that if the garbage happens to be anything but 0, 1, 2, 3, or 4, the unit tests will succeed.
Question: It appears that the .vcproj file of the UT's is somehow patched before the UT's are built. I don't know how they do it, but with their build out-of-bounds array elements are always 0. It seems to me that the whole virtual memory is set to 0 before program execution. What project setting is that? Or am I imagining things?
I mean, if it was just luck that there was a 0 sitting out-of-bound of an array, then upon multiple executions my luck would fail, wouldn't it? But it is always 0... I am confused.
By the way, when I build the same project the out-of-bounds element always has different values on each execution. Can you please explain this? Thanks.
To the actual question of is memory always 0 at the start? Well, it might depend. In general, when the OS provides you with a page of memory it will be cleared (as a security measure, so that you cannot read the values that any other process had in their memory), so in many cases you will find that uninitialized can look like 0, until memory is being reused in your own process, where you will get whatever you wrote before.
There are also some compiler flags that can affect it. To detect uninitialized memory issues, sometimes debug builds will write patterns to memory after allocation from the OS and before handling it to the program, and a different pattern after releasing the memory in the program before reallocating (to detect access to freed memory), so that it is simpler to identify what happened (if you see in a debugger that the value is 0xDEADBEEF, you will know that the memory has already been released by the program. You will have to read the compiler/IDE documentation for more precise information.
As you say, it's undefined, so the implementor is free to do whatever they like. I can't speak for Visual C++ at all, but I am aware of other products that do things like zero out memory when running debug builds so that things like invalid pointer dereferences will fail at the site of the fault. It's possible that Microsoft is doing something similar I guess.