Run-Time Check Failure #2 - Corrupted Stack error

[Tweezy]

SFML 2.0
VS2012

Bug - Run-Time Check Failure #2 - Stack around the variable 'defaultFont' was corrupted.

Code in question:

void game::gui()
{
        //Lives string
        //Time string
       
        sf::Font defaultFont;
        if(!defaultFont.loadFromFile("arial.ttf"));
        sf::Text playerScore;
        playerScore.setFont(defaultFont);
        //Display them
}

I'm making a simple gui for my platformer game, but i'm having a really strange bug whenever I use the SFML2.0 sf::Text function.
I would also like to point out that I do not have this error when I comment out all of  the sf text and font.

I've double checked my references and double checked it against the build type. I'm building in debug mode, and the references have -d.

I've done a little bit of research, and from what i've collected I come to the conclusion that either:
- Using Memory that isn't there.
- Too much data being put on the stack

If these are the issue, i've never been taught memory management so not too sure how to rectify it.

Really confused about this and I need to develop my GUI.

Thanks guys

[Nexus]

Did you recompile SFML for your compiler? And you are really sure you don't mix Release/Debug?

[Tweezy]

How would I go about recompiling SFML? I've never mixed the Release/Debug.

[Jesper Juhl]

well, your "defaultFont" is a stack (automatic) variable in the game::gui() function, so as soon as that function exits it is going to be destroyed and any reference to it past that point is going to go bad. Could that be your problem?

If not, then perhaps try running your code under a tool like Valgrind (http://www.valgrind.org/) or do a build with gcc (4.8+) or clang (3.4+) with -fsanitize=address enabled (read more here: http://clang.llvm.org/docs/AddressSanitizer.html) and see what that finds. Both those tools are rather excellent in tracking down memory corruption bugs.

Ohh and before you do that, bump you compilers warning level to the max and check/fix all the warnings - most compilers are pretty good at spotting silly mistakes as long as you let them (by upping their warning level).

[Tweezy]

well, your "defaultFont" is a stack (automatic) variable in the game::gui() function, so as soon as that function exits it is going to be destroyed and any reference to it past that point is going to go bad. Could that be your problem?

If not, then perhaps try running your code under a tool like Valgrind (http://www.valgrind.org/) or do a build with gcc (4.8+) or clang (3.4+) with -fsanitize=address enabled (read more here: http://clang.llvm.org/docs/AddressSanitizer.html) and see what that finds. Both those tools are rather excellent in tracking down memory corruption bugs.

Ohh and before you do that, bump you compilers warning level to the max and check/fix all the warnings - most compilers are pretty good at spotting silly mistakes as long as you let them (by upping their warning level).

Thanks for the in-depth response. That function is being put into an update() function which is constantly updated while the window is open, so that shouldn't be an issue. It will only be destroyed when the window is closed.

Thanks for the link and increasing my warning levels, will try them and report back.

[Jesper Juhl]

Thanks for the in-depth response.

You are welcome.

That function is being put into an update() function which is constantly updated while the window is open, so that shouldn't be an issue. It will only be destroyed when the window is closed.

I think you misunderstand.
What I mean is

void func() {
 int a = 42;
 // pass a pointer or reference to "a" to someone else
} // At this point "a" is destroyed, so that pointer or reference you passed to some other function is now invalid.
 

Variables declared on the stack only live until they go out of scope (in this case the scope being the function). It doesn't matter if you call the function from somewhere else continuously.
For example:

void f(int a) {
  int b = 5;
  int c = a * b;
  std::cout << "c is " << c << std::endl;
}

int main() {
  for (int i = 0; i < 10; ++i) {
    f(i);
  }
}
 

In the above program, the variables "b" and "c" are going to be created and destroyed 10 times each - once every time the function is called. It doesn't matter that "f()" is called inside the loop until the program exits - the variables inside the function are not kept alive from one invocation to the next.
This is fairly basic C++ knowledge btw.

Ohh and one other thing; concerning what Nexus said:
You want to make sure that you are not building your application in debug mode but linking to the release mode libraries or building in release mode but linking to the debug libraries. That's what's meant by "mixing debug and release".

Thanks for the link and increasing my warning levels, will try them and report back.

Looking forward to hear what you find :-)

[Tweezy]

Thanks for the in-depth response.

You are welcome.

That function is being put into an update() function which is constantly updated while the window is open, so that shouldn't be an issue. It will only be destroyed when the window is closed.

I think you misunderstand.
What I mean is

void func() {
 int a = 42;
 // pass a pointer or reference to "a" to someone else
} // At this point "a" is destroyed, so that pointer or reference you passed to some other function is now invalid.
 

Variables declared on the stack only live until they go out of scope (in this case the scope being the function). It doesn't matter if you call the function from somewhere else continuously.
For example:

void f(int a) {
  int b = 5;
  int c = a * b;
  std::cout << "c is " << c << std::endl;
}

int main() {
  for (int i = 0; i < 10; ++i) {
    f(i);
  }
}
 

In the above program, the variables "b" and "c" are going to be created and destroyed 10 times each - once every time the function is called. It doesn't matter that "f()" is called inside the loop until the program exits - the variables inside the function are not kept alive from one invocation to the next.
This is fairly basic C++ knowledge btw.

Ohh and one other thing; concerning what Nexus said:
You want to make sure that you are not building your application in debug mode but linking to the release mode libraries or building in release mode but linking to the debug libraries. That's what's meant by "mixing debug and release".

Thanks for the link and increasing my warning levels, will try them and report back.

Looking forward to hear what you find :-)

Yes I did misunderstand haha sorry, been programming for like 12-14 hours each day for the past week (Uni assignment) so I'm a tad mind dead! Basically declaring things locally, once you move from the class they are destroyed - can't believe I missed that! Moved my sf::font and sf::text to my header file, issue fixed! I'm such a numpty haha :') Thanks!