Debugging strategies needed for crash on exit.
Hello,
I have ported my app from Mac to Windows and it works fine, except there is a crash on exit.
It appears all the constructors for the objects in mainWindow are being called and are not the problem.
Should I now be trying to debug some dll Qt is using?
Do I need a debug version of the libraries?
Any thoughts welcome.
I am compiling against the QtSDK, using msvc2008 toolchain.
Here is the not very helpful crash report:
- (84c.244): Access violation - code c0000005 (first chance)
- s
- sException at 0x5327f803, code: 0xc0000005: read access violation at: 0x0, flags=0x0
- First chance exceptions are reported before any exception handling.
- This exception may be expected and handled.
- eax=00000000 ebx=7ffdf000 ecx=966433a0 edx=014077b8 esi=00000000 edi=00000000
- eip=5327f803 esp=0012feb4 ebp=9873e801 iopl=0 nv up ei pl zr na pe nc
- cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
- 5327f803 ?? ???
- s
- sException at 0x5327f803, code: 0xc0000005: read access violation at: 0x0, flags=0x0
12 replies
In much more than 99% of such crashes it is not Qt’s fault. So no, do not start to debug Qt. Start debugging your own code:
- build in debug mode
- run in a debugger
- look where the crash occurs
Most times such a crash happens is caused by
- deleting an object more than once
- accessing a dangling pointer (i.e. a pointer to an already deleted object)
- accessing a null pointer
OK, thanks for the tips.
Yes, the crash is happening in the debugger. All the destructors for my objects are being called and no crashes there.
Normally, when my code is causing a crash, there is a nice call stack display which points right to my code with all the call history leading up to it. With this crash, there is only one line in the call stack, and it does not point to my code.
Again, no problems with identical code on the Mac.
I just did an experiment and removed all the delete statements from my code, but still get the crash on quit.
Here is the call stack:
- 0x6c27f700 ???
- ^ Memory access error in 'u 0x6c27f700 0x6c27f900'
Not “Hello world”. It’s an app we developed on Mac, and ported to Windows. All works well, except for the crash on quit.
I’m using Qt-Creator. The Qt version is “Qt 4.7.4 for Desktop – MSVC2008 (Qt SDK).
Tool chain is “Microsoft Visual C++ Compiler 9.0 (x86i)”
I’m on Windows 7. I’ve removed mingw from my PATH.
I just built and run one of the examples in the SDK, and it works and quits without crash.
I’ve tried an elimination search where I will start deleting and simplifying the program. At some point it doesn’t crash so I think I’ve found the problem, being the last thing I eliminated but that was just false hope. If I start eliminating from a different area, I’ll wind up eliminating something new that was different from the first process. If there was some way I could step through the exit code and see what it’s choking on. Is the QtSDK built in debug mode?
OK, I’ve changed things around a little bit, and I’m getting some more info on the problem.
In main(), I changed MainWindow to a pointer like this:
- MainWindow *w;
- w = new MainWindow();
- w->show();
- int rval = a.exec();
- delete w;
- return rval;
After delete w, I’m getting a pop-up msg:
- Debug Assertion Failed!
- Program:
- ...rs\Qdministrator\12step\12step-build\debug\12step.exe
- File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c
- line 1317
- Expression:_CrtlsValidHeapPointer(pUserData)
- For information on how your program can cause an assertion
- failure, see the Visual C++ documentation on asserts.
- (Press Retry to debug the application)
Hum, found this on the web relating to this assert
You are probably linking against the debug and the release versions of
msvcrt. More specific, you link against the debug version and some lib
you use is linked against the release version and you are
deleting/freeing some object/pointer with the debug version of
delete/free that was allocated with the release version of
new/[m]alloc.
You must log in to post a reply. Not a member yet? Register here!