Jump to content

  • Log In with Google      Sign In   
  • Create Account

Why does clean and recompile remove crashes?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 suliman   Members   -  Reputation: 563

Like
0Likes
Like

Posted 15 December 2012 - 03:22 AM

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:

Sponsor:

#2 kunos   Crossbones+   -  Reputation: 2207

Like
5Likes
Like

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.
Stefano Casillo
Lead Programmer
TWITTER: @KunosStefano
AssettoCorsa - netKar PRO - Kunos Simulazioni

#3 ultramailman   Prime Members   -  Reputation: 1570

Like
3Likes
Like

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:
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.


#4 suliman   Members   -  Reputation: 563

Like
0Likes
Like

Posted 15 December 2012 - 04:08 AM

ok thanks guys

#5 J. Evola's Apprentice   Members   -  Reputation: 307

Like
0Likes
Like

Posted 15 December 2012 - 04:08 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?

Edited by J. Evola's Apprentice, 15 December 2012 - 04:09 AM.


#6 Olof Hedman   Crossbones+   -  Reputation: 2822

Like
0Likes
Like

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 ultramailman   Prime Members   -  Reputation: 1570

Like
0Likes
Like

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 Katie   Members   -  Reputation: 1330

Like
0Likes
Like

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;

person.o:     hello.h anotherfile.h thisandthat.h



#9 MarkS   Prime Members   -  Reputation: 882

Like
0Likes
Like

Posted 15 December 2012 - 03:52 PM

Pass the code through CPPCheck and it should catch most of these problems.


Thanks for the reference to CPPCheck! That is most useful.Posted Image

http://cppcheck.sourceforge.net/

Edited by MarkS, 15 December 2012 - 03:52 PM.


#10 Paradigm Shifter   Crossbones+   -  Reputation: 5369

Like
0Likes
Like

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.
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS