Hi
I use visual studio c++ and am a bit confused.
I lately had a crash in my game every time when in a certain situation trying to delete a gameObject from a list containing such elements. It worked before and i didnt change anything special since last working build.
So i did what i usually do when short of ideas, clean project. Recompile. Boom. Problem solved. But why?
Thanks for clearing this up
Erik
this is a ship:
1
Why does clean and recompile remove crashes?
Started by suliman, Dec 15 2012 03:22 AM
9 replies to this topic
Ad:
#2 Members - Reputation: 1303
Posted 15 December 2012 - 03:26 AM
It might be a "misscompile" or "misslink" but, in my experience, those are pretty rare. 99% of the time, in C++, you have an uninitialized variable somewhere or some out of bound access, the new compile might just have hidden that.
Pass the code through CPPCheck and it should catch most of these problems.
Pass the code through CPPCheck and it should catch most of these problems.
#3 Members - Reputation: 820
Posted 15 December 2012 - 04:04 AM
This can happen when a header file(let's call it "hello.h")'s class/struct definition is changed, but its corresponding object file ("hello.o") is for some reason not recompiled.
Other object files ("person.o") will link with the old, not recompiled object file ("hello.o").
This "hello.o" will contain old and possibly incorrect code to manipulate the old data structure defined by the old "hello.h", and those code can be used by all sources that #include "hello.h".
Example:
Let's say the old hello.h is like this:
hello.c:
But then you decide a long is not necessary to represent a person's age, and change it to:
and then you purposefully not recompile hello.o, but recompile everything else that uses hello.h. Then you link them and hello.o together.
Because the struct definition is updated, but the set_age function isn't, when you call set_age, it will write a long (4 or 8 bytes) into a char (1 byte). That can't be correct, and the program can crash.
By cleaning every thing (every object file), you are forced to recompile every object file. Then functions and the data definitions are up to date with each other, so it "magically" fixes the error.
Other object files ("person.o") will link with the old, not recompiled object file ("hello.o").
This "hello.o" will contain old and possibly incorrect code to manipulate the old data structure defined by the old "hello.h", and those code can be used by all sources that #include "hello.h".
Example:
Let's say the old hello.h is like this:
struct hello{
long person_age;
};
void set_age(struct hello * h, long a);
hello.c:
void set_age(struct hello * h, long a)
{
h->age = a;
}
But then you decide a long is not necessary to represent a person's age, and change it to:
struct hello{
char person_age;
};
and then you purposefully not recompile hello.o, but recompile everything else that uses hello.h. Then you link them and hello.o together.
Because the struct definition is updated, but the set_age function isn't, when you call set_age, it will write a long (4 or 8 bytes) into a char (1 byte). That can't be correct, and the program can crash.
By cleaning every thing (every object file), you are forced to recompile every object file. Then functions and the data definitions are up to date with each other, so it "magically" fixes the error.
Edited by ultramailman, 15 December 2012 - 04:07 AM.
#6 Members - Reputation: 1226
Posted 15 December 2012 - 04:15 AM
@ultramailman:
This issue happens and I don't understand why.
Object files should be recompiled whenever any of the dependencies is changed. So, why the are not?
In my experience, usually because of buggy build tools... or tools that try to be too smart and cache what they shouldn't (I'm looking at you eclipse)
One way it can go wrong is if file dates are messed up, so the tools don't notice that the source file has changed.
Can easily happen if you replace files with old versions of themselfs. (reverting some change for example)
Edited by Olof Hedman, 15 December 2012 - 04:18 AM.
#7 Members - Reputation: 820
Posted 15 December 2012 - 04:36 AM
@ultramailman:
This issue happens and I don't understand why.
Object files should be recompiled whenever any of the dependencies is changed. So, why the are not?
I have no idea how that can happen with IDE's. It happens to me because I use make, and write my own makefile. I am not very good with makefiles, so I just use %.o: %.c %.h. So if a person.o depends on hello.h, my makefile wouldn't know about it.
#8 Members - Reputation: 1085
Posted 15 December 2012 - 07:17 AM
Most compilers have an option to output the dependencies of a .o as they create it. If you capture that in a file and do some simple manipulations on it, you can then include that into your makefile and you have the dependencies done for you.
If you don't want to do that, you can simply put lists of things in your makefile;
If you don't want to do that, you can simply put lists of things in your makefile;
person.o: hello.h anotherfile.h thisandthat.h
#10 Members - Reputation: 1839
Posted 15 December 2012 - 05:08 PM
IDEs scan the include files for a compilation unit recursively and work out the dependencies automatically.
If you use a makefile you have to manually add any dependencies, painful, and prone to error. The rule of thumb there is if you change a header, recompile everything... But seriously, use an IDE that does it for you...
Last time I used makefiles was in PS1 days.
If you use a makefile you have to manually add any dependencies, painful, and prone to error. The rule of thumb there is if you change a header, recompile everything... But seriously, use an IDE that does it for you...
Last time I used makefiles was in PS1 days.
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley
