Ok, well I decided to install the dev environment on an extra laptop I have running Windows XP. Without any changes, I ran the program and perform just one conversion, the debugger stops me. Oddly enough, it stops me at ntdll!DbgUiConnectToDbg, with the signal "signal-received".
I tried running the program through gdb, and sure enough, after one conversion it breaks with the following:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
To copy to clipboard, switch view to plain text mode
Why is there a breakpoint in a system DLL?
[update]
Ok, well I think I finally found the problem, almost accidentally.
The problem was in my destructor. I had:
delete myPointer;
myPointer = 0;
delete myPointer;
myPointer = 0;
To copy to clipboard, switch view to plain text mode
For some reason, the delete statement was causing a crash. I switched the two lines around, and now everything works.
I think it has to do with the way I assigned the pointer. I had something like the following:
somefunc()
{
MyClass myclass;
myclass.myPointer = someOtherFunc();
}
somefunc()
{
MyClass myclass;
myclass.myPointer = someOtherFunc();
}
To copy to clipboard, switch view to plain text mode
I'm *guessing* what happened is this:
Inside someOtherFunc(), I create a new object on the heap and return it, which then gets assigned to myPointer. Then when somefunc() finishes, it tries to destroy myclass, which is on the stack. The destructor gets called, which then tries to delete the pointer, but I'm guessing at this stage the pointer is already invalid.
Does this sound right? Sometimes pointers can be a bit confusing.
Bookmarks