program hanging returning from a constructor

[briforge]

I am writing a program for the Palm OS in c++. I have already posted
this to a palm development forum but I'm desperate for a fix, so I hope
this cross-post isn't offensive.

My program is hanging, like it's in an infinite loop, while returning
from constructing an object. Through the debugger, I've found that it
is hanging on the returning call to the constructor. I put a breakpoint
on the closing bracket of the constructor, and it goes past that point
fine. It hangs on the next step, on the returning line, like this

mg = MyGame();

The variable 'mg' is declared in a file of global variables (as type
MyGame) and referenced through an extern reference.

It appears to work fine the first time the mg object is constructed.
Then I re-use the mg reference when I am resuming a saved game. I don't
have a destructor for the MyGame() object, but I never have. I don't do
any memory allocation within the object.

None of this is new, it's been working fine for months. I haven't made
changes to any of this code. I've made changes to other parts of the
program, but nothing in the MyGame object.

Any ideas? Any help would be greatly appreciated. Thanks.

 

[Srini]

mg = MyGame();

A temporary is getting assigned. The temporary is destroyed immediately
after the execution of the above statement. Depending on what you have
in your class, this _may_ lead to problems. Why don't you do this
instead...

mg = new MyGame;

Regards,
Srini

 

[EventHelix.com]

This could be due to a stack corruption in the constructor function.

When the constructor returns, the return address is pulled from the
stack. If the return address has been corrupted, the function would
crash on return.

The following artciles might also give you some ideas:
http://www.eventhelix.com/RealtimeMantra/Basics/debugging_software_crashes.htm
http://www.eventhelix.com/RealtimeMantra/Basics/debugging_software_crashes_2.htm

 

[lampard]

Do you have any operator= method in MyGame class check if it is being
called and if it has any locks.

 

[Victor Bazarov]

A temporary is getting assigned. The temporary is destroyed
immediately after the execution of the above statement. Depending on
what you have in your class, this _may_ lead to problems. Why don't
you do this instead...

mg = new MyGame;

Expressions 'MyGame()' and 'new MyGame' have different types. In most
cases if the former compiles, the latter won't.

 

[Srini]

Expressions 'MyGame()' and 'new MyGame' have different types. In most

cases if the former compiles, the latter won't.

Oh yeah. new returns pointer to the object whereas MyGame() would be a
temporary object. Thanks Victor.

 

[briforge]

Thanks much for the replies. I found the problem, and it was occurring
else where. I don't know why it appeared to hang coming out of the
constructor. But when I was debugging it again, it got past that
point.

But the replies have me intrigued. Is my code :

mg = myGame();

still incorrect in some way, or have the potential for problems? It
turns out it does work after all, but if there is a better way I'd like
to know.

I tried

mg = new myGame;

and the compiler gave an error of 'illegal operand'.

 

[Old Wolf]

But the replies have me intrigued. Is my code :

mg = myGame();

still incorrect in some way, or have the potential for problems? It
turns out it does work after all, but if there is a better way I'd like
to know.

Your code will create a new myGame object, by calling the
default constructor. Then, it will assign that object to
'mg' by calling mg's operator= function. Then, the new
object will be destroyed since it is no longer needed.

If you have not written an operator= function for myGame
explicitly, the compiler will generate one for you. But if
myGame has any pointers or other resource handles, then this
compiler-generated operator may not do what you need.
If you post your definition of myGame then we can tell you
if you need to write an operator= function or not.

If you want to avoid this copy operation, you could add a
function to myGame that's designed to clear out an existing
object, eg:
void myGame::clear()
{
member1 = 0;
member2 = "";
// etc.
}

 

[tttpppggg]

If you feel pretty advanced you could just check the code on another
machine.
But that's a real longshot.
If your code has been truly stable in the past and no changes have been
made in the code where you are seeing the problem:
Try lookin at the assembly language and make some sense out of it.
For example, does the call address for MyGame() actually look
right?
If not, then some corruption occurred.
If so, does it look like the MyGame() code at that address?
The first thing that code of that sort would do, after
calling wrapper functions, is push registers onto stacks. But maybe you
know all of that.
Sometimes libraries are dynamically loaded and
unloaded. That kind of stuff could theoretically become corrupted, but
one would think only inside the OS level.
A true assembly language genious would discover the problem quickly.

As for C++ woof you could try looking for a memory leak. Copy
Constructors are good for that. Somehow your constructor may be
overwriting stack space a bit higher than it. So the return address is
screwed up(on the stack), and thus the address of the line of code will
not actually match what you or your debugger thinks it is. Uh-Oh, a
good debugger would not do this. This is probably all a bad idea.

-Tim