Program runs on Windows 7, crashes on Windows XP

[JovianGhost]

Here's a strange one.

I've got a conversion application I've written in Qt. User enters some values, clicks a button, and it calculates some new values.

It was compiled on my Windows 7 x64 system, and works perfectly. When I copy the executable and supporting DLLs to any other Windows 7 computer, be it 32- or 64-bit, it runs perfectly. When I run it on any Windows XP machine (I've tried 3 so far) the program will run, but will crash after a few conversions (usually on the 5th one.) When running on Windows 7, I can perform as many conversions as I want, and I can't get it to crash.

This doesn't make any sense to me. Why would the program run fine in one OS and not another? I've got the same executable and same DLLs. I've even tried it on one system which dual boots XP and 7, and sure enough, it works in 7 but not XP.
I have a lot of pointer allocation and deallocation going on, so it might be a null pointer reference, but then why would it magically work in 7?

Anyone have any ideas what it might be? I really don't want to have to resort to installing a debugger/development environment on the XP machine.

I can't post code because
1) The program is very large and complex
2) Some of it is proprietary

[Zlatomir]

What is the error?

I don't think it's a null pointer reference, that should happen on 7 too.
Just my guess: it crashes on XP 32bit? if so looks like a memory leak, on 64 bit OS a process can "leak" more memory before crash (or not leak, but just don't delete as soon as it should) so check memory allocations/deallocations.

[JovianGhost]

The error is just a general Windows GPF, nothing very helpful.

It crashes on XP, both 32- and 64-bit. It's fine on 7, both 32- and 64-bit.

[john_god]

Perhaps you have a memory leak caused by some bad pointer wich randomly can point to some invalid memory position. Than it can crash or not. Try point your pointers to NULL when dealocating them, and check wath happens. Also try using some program like Valgrin to check memory leaks.

[JovianGhost]

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.

[squidge]

You switched the two lines around? So you now have something like the following?

myPointer = 0;
      delete myPointer;

myPointer = 0;
      delete myPointer;

To copy to clipboard, switch view to plain text mode 

To me, that seems a little pointless.

[JovianGhost]

You switched the two lines around? So you now have something like the following?

myPointer = 0;
      delete myPointer;

myPointer = 0;
      delete myPointer;

To copy to clipboard, switch view to plain text mode 

To me, that seems a little pointless.

Hm, now that I look at it, you're right. What was I thinking?

I guess the root cause of all this is that something is wrong with my pointers. But I'm still confused as to why this is only a problem on XP and not 7.

Looks like I'll have to rework things a bit...

[squidge]

The memory map will be different on XP and 7, but that should be invisible to the application, unless it does undefined things like trash memory or double free some pointers. On 7, you might be causing the same fault but because different code lives there, the same fault doesn't happen.

[JovianGhost]

Ok, I found the problem.
After spending DAYS troubleshooting this, and having the program crash in multiple locations, I finally traced it down to the root cause.

At some points in the program, I would create a new pointer by static_cast'ing an existing pointer. The problem is I would then deallocate that new pointer, not realizing when I did so, I was also deallocating the ORIGINAL pointer. For some reason I thought that when I used static_cast I created a copy of the existing pointer.

I went through my code and removed all relevant delete statements, and now all is well.