[Solved] Release mode exception

[Glyder]

I'm currently experiencing a problem which only occurs when I run my .exe from the command line or launch it from windows explorer. It runs fine when I launch it from Qt Creator. It also runs fine in debug mode, from the command line and elsewhere. The exception I'm getting is:

@The instruction at "0x670f15f3" referenced memory at "0x09c70954". The memory could not be "read".@

It occurs when trying to execute this line on a QStateMachine:

@QList<QAbstractState*> allStates = machine->findChildren<QAbstractState*>()@

I've tried copying QtCore4.dll into the same folder (and a few other dll's) but no luck so far. I've also run DependencyWalker on it and haven't seen any clues. I'm guessing it's something obvious (since it runs fine within Qt Creator) but I seem to have missed it.

It's a console-only application, and the target is Windows XP SP2, using MSVC2008, running Qt Creator 2.3.1, on version 4.7.4.

[Glyder]

Worked it out. Just had to set the QTDIR environment variable.

[Glyder]

Actually, still not fixed... although the above does seem to get the execution slightly further before crashing. If I run it from Qt Creator using "Start Debugging" while in release mode, it runs fine.

Note that the "working directory" in "Run Settings" is set to be same as the location of the executable. Also, the "Run Environment" is set to "System Environment". I'm trying to work out what the difference is...

Any suggestions?

[tobias.hunger]

Creator does add some things to the "System Environment". Most notable is the PATH variable which is updated to pick up Qt and the compiler.

Please check with some process monitor which libraries it fails to open when running. Dependency walker is nice, but it does not catch missing plugins, and Qt has some of those (image formats, etc.).

[Glyder]

Thanks Tobias.

I've solved this one once and for all, turns out it was due to heap corruption (I was using a static_cast where I should have been using a qobject_cast). Had to set the environment variable _NO_DEBUG_HEAP to replicate the exception under the debugger, turns out this is what was masking the bug. Phew!