Debugging strategies needed for crash on exit.

babazaroni

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
@

mohsen

do you have a pointer which is deleting while it's not created?

koahnig

Is the problem also occuring when you run the application in the debugger?
If yes, you can try to locate closer, if it is a routine of Qt causing the crash.
Could it be that you are accessing a pointer of an object whose ownership has been handed over to a Qt object?

goetz

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

babazaroni

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'
@

koahnig

You mean even a "Hello world" application is crashing?

You need to prvide some details.
The IDE you are using Qt creator or msvc2008?
The compiler seem to be the one of msvc2008, or could it be that you are using mingw?
What windows are you using?

babazaroni

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.

koahnig

[quote author="babazaroni" date="1323618600"]
I just did an experiment and removed all the delete statements from my code, but still get the crash on quit.
[/quote]
That is the reason for asking if even a "Hello world" application is failing. All sounds a bit strange. So, maybe you should try a hello world program as a starter.

babazaroni

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?

goetz

You can try to set breakpoints at various spots in your source code and start executing the remaining code step by step.

babazaroni

There is no source code to set breakpoints. All my destructors have been called and are fine. It seems that there is something Qt is doing in cleanup that is crashing. Most likely it's something I've done to set up the situation, but I don't have a clue.

babazaroni

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();

QObject::connect(&a,SIGNAL(aboutToQuit()),w,SLOT(slotAboutToQuit()));

w->show();

int rval = a.exec&#40;&#41;;

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)@

babazaroni

Hum, found this on the web relating to this assert

bq. 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.