Code breaking when trying to set member variable in constructor

Question

I have a class like this:

class Player
{
public:
    Player(Board * someBoard);

    void setSide(char newSide);

protected:
    Board * board;
    char side;
};

and its implementation is as such:

Player::Player(Board * someBoard)
{
    board = someBoard;
    side = '0';
}

void Player::setSide(char newSide)
{
    side = newSide;
}

Now I have another class inheriting from it:

class HumanPlayer : public Player
{
public:
    HumanPlayer(Board * someBoard);
};

And its short implementation is this:

HumanPlayer::HumanPlayer(Board * someBoard) : Player(someBoard)
{
}

Now the problem is the side = '0'; line makes the program freeze (the window turns white in Windows 7, not sure if that means it froze or crashed). Commenting it out make the program run fine (and it's okay to comment it out because the variable isn't used anywhere yet).

What is causing the error and how can I fix it?

EDIT!

After printing out some stuff to an fstream, all of a sudden the program worked. I tried commenting the printing out. It still worked. I tried deleting the debugging code I added in. It still worked. So now my code is exactly the same as listed above, but it magically works now.

So what do I do now? Ignore the anomaly? Could it have been a compiler mistake?

A `char` variable assignment is not going to freeze up a program. Something else is wrong, probably at the message loop or a window procedure somewhere (perhaps you can post that). But the problem can't possibly be in the code in your question. — In silico, Dec 11 '10 at 10:27
@insilico argh do I hate heisenbugs. But how to I get the message loop? I'm new to GUI programming — wrongusername, Dec 11 '10 at 10:39
I assume this is a native Windows program, no? Are you using a framework, a library, etc? [Do you have anything in your code that looks something like the code on this webpage?](http://www.winprog.org/tutorial/simple_window.html) Can you reduce your program down to the barebones that reproduces the problem? — In silico, Dec 11 '10 at 10:41
@insilico I'm using qt, but the problem has been resolved... now I have a new problem. I'll update the question — wrongusername, Dec 11 '10 at 10:52
Are you sure all your objects have been allocated (especially the HumanPlayer class) ? — small_duck, Dec 11 '10 at 10:52
@wrongusername: If you have solved the problem, you should post what went wrong and how you fixed it as a solution to your own question, in case someone else find themselves into the same situation (and it forces you to really understand your problem). If there's a different problem, ask it as a new, different question. — In silico, Dec 11 '10 at 10:54
@insilico please see my update. I have no idea what went wrong, and in the end I didn't fix anything. The problem just resolved itself. I guess it was having a horrible life, so it committed suicide or something... — wrongusername, Dec 11 '10 at 10:55
@wrongusername: Okay, you apparently can't reproduce your problem reliably. Again, have you tried reducing your program down to the very barebones? It is very, very, very rarely the compiler's fault. Start out with a "Hello World" program of some kind in Qt, then build up from there. — In silico, Dec 11 '10 at 10:57
@insilico no... what do you mean by "down to the very barebones"? btw, the problem was reproduced reliably 100% of the time when it wasn't working. After I recompiled, it is now working 100% of the time when I run the executable. — wrongusername, Dec 11 '10 at 10:59
@wrongusername: What I mean is create a "blank" Qt program that does nothing but show a window. If you can get that to work, then you can try adding back code and see where it starts to fail. — In silico, Dec 11 '10 at 11:01
@wrongusername: Did you say that you recompiled? As in "Rebuild Solution" in Visual Studio or something of the like? That's probably why the problem went away. Perhaps it reupdated all the binaries after recompiling the code. — In silico, Dec 11 '10 at 11:02
@insilico I doubt I would actually get the code to fail. It is working just fine now (it was crashing before any user input, now it is working fine). What I really meant was changing another file, which then got recompiled (?) and thus fixed the problem somehow — wrongusername, Dec 11 '10 at 11:08

score 2 · Answer 1 · edited May 23 '17 at 12:26

I suspect the problem isn't what you think it is.

It sounds like a memory corruption issue of some sort, but it's really impossible to tell based on the information provided. I have two suggestions for you:

Either post the smallest complete program that demonstrates the problem, or
Try a valgrind-type tool to see if it helps you figure out what's going on.

Or, better yet, start by looking at the state of the program in the debugger (once it's hung.)

score 1 · Accepted Answer · answered Dec 11 '10 at 11:00

Is it possible that you are using two incompatible definitions of your Player class, defined in different header files? If the definitions have different sizes, then the 'size' member might lie outside the memory block allocated for the class instance.

Edit I see that your problem has disappeared. So it was probably a module that didn't get re-compiled after a change in the class definition; but now that you've re-compiled everything, the problem has fixed itself.

Nope, just one player class with one definition. – wrongusername Dec 11 '10 at 11:00 — wrongusername, Dec 11 '10 at 11:00

Code breaking when trying to set member variable in constructor

2 Answers2