Qt, Windows 7, Dependency Walker and Deployment Problems

Good day all!

Preliminaries:

Qt Creator 2.0
Qt 4.7.0 (32 bit)
Windows 7 Professional

I believe my issues are mostly Windows related, but seeing that my application was written and runs out of Qt without problems, I hoped that someone here might be able to offer some insight.

The program runs and tested fine out of Qt Creator itself. No crashes, no bugs (yet?) and no problems. Happy Days! Now, I had to make this app deployable and went the route of Dependency Walker (v 2.2.6) + Visual Studio 2010 Pro. Profiling my app with Dependency Walker lists a number of warnings, most of which are only that, one or two that I've managed to eliminate as problems and none which stops the program from executing.

Finally we get to the meat of the matter. The program works fine, everything runs smoothly up until the point where I spawn new threads to connect to a server and I get the following:

Quote:

---

First chance exception 0xC0000094 (Integer Divide by Zero) occurred in "c:\build\path\release\APP.EXE" at address 0x004028CF.
Second chance exception 0xC0000094 (Integer Divide by Zero) occurred in "c:\build\path\release\APP.EXE" at address 0x004028CF.

---

Nowhere do I do any calculations in my program so where does the integer division by zero come from? I'm willing to post code if required, but as it all works out of Qt, I'm not so sure it's a code issue.

Any and all input will be greatly appreciated and please tell me if you'd like more of the Dependency Walker log before the crash happens.

Thanks!
Jits

Well these kind of errors get eliminated by doing some logging. put a qDebug() (or write to file ) before entering major functions of your app (such as mainwindow ctor) and this way you can reach the code which is doing the bad. BTW, i read somewhere that VS2010 has problems with some assembly and hence not recommended.

If it is a code issue, why would it run out of Qt without any problems? Surely a division by zero would be a division by zero regardless of whether I run it from the Qt Creator GUI or not? Or doesn't it necessarily work that way?

in Qt Creator, u run the debug exe or release exe? Furthurmore, are u using the correct dlls from the Qt SDK ?

I run in release. I can also run the .exe outside of Qt (running it from the \build\release folder or from a shortcut on my Desktop that points to the .exe within that folder).

Which .dll's are you referring to?

QtCore4.dll, QtGUI4.dll, etc.

I haven't deployed the app to vanilla machines yet so all the Qt dll's are available as I'm still running the app on the development box and, as I said, it runs fine there when run from Qt Creator or from the \build\release folder. However, the Dependency Walker issues appear on the same (dev) box so I'm not sure what these .dll's have to do with the issue...

...or are you referring to library includes in my project file? I'm sorry if I'm missing the obvious, but I don't think I'm on the same page as you guys.

I found the problem.

I had a typical

Code:

---

#ifndef MYTHREAD_H
#define MYTHREAD_H
 
#include <QThread>
 
class MyThread : public QThread
{
    Q_OBJECT
 
public:
    MyThread(QObject *parent = 0);
    ~MyThread();
    void run();
 
};
 
#endif // MYTHREAD_H

---

setup and, as advised in the Qt documentation, I simply re-implemented the run() function. In my main thread, I had

Code:

---

MyThread *thread = new MyThread();
        thread->start();

---

and this is where things went wrong, as I'd understood from the Qt docs that start() would automatically call run()

Quote:

---

void QThread::start ( Priority priority = InheritPriority ) [slot]
Begins execution of the thread by calling run(), which should be reimplemented in a QThread subclass to contain your code. The operating system will schedule the thread according to the priority parameter. If the thread is already running, this function does nothing.

The effect of the priority parameter is dependent on the operating system's scheduling policy. In particular, the priority will be ignored on systems that do not support thread priorities (such as on Linux, see http://linux.die.net/man/2/sched_setscheduler for more details).

See also run() and terminate().

---

I can't remember why I didn't just call run() from the beginning (I'm not sure if there even was a valid reason), but the problem went away as soon as I changed my thread execution call to

Code:

---

MyThread *thread = new MyThread();
        thread->run();

---

I'm not sure why this worked (or, for that matter, why calling start() didn't), but I now have a complete profile in Dependency Walker and no more crashes.

Fingers crossed that the deployment will go more smoothly than this did!

Seems I got too excited, too soon.

start() initiates the thread's event loop and one of my functions relied on the QThread::finished() signal to terminate a connection. This is now no longer emitted seeing that there is no event loop anymore. I've tried various combinations of exec() and quit() to "manually" start up and exit an event loop, but no luck to date. An explicit emission of finished() might be the way forward. Perhaps I'll also have to look at QThreadPool to manage all the startups...I don't know.

Will report back here if I manage to find a solution.

Dependency Walker, is that a program that just scans your program or does it actually run your program? Or do you get these errors from just running it outside Qt Creator.
The problem you mention is on one and only one pc only, the develoment pc?

These things aren't really clear at the moment.

If this is on the same pc, but the program is being run in different environments, and it works in one and not in another, then the problem is in the environment.

Dependency Walker is a simple program that just lists the dependancies for your program (eg. QtGUI4.dll), so you can easily bundle the right libraries with your program for distribution.

It can be found here: http://www.dependencywalker.com/

If you profile your program with Dependency Walker, it actually runs the application as it would normally, picking up all the run time dependencies as it does so (all your program's functionality is enabled and accessible during the profiling).

Running the app on the development machine (outside Qt Creator) gives me no errors, running it from within Qt Creator (on the development machine) gives me no errors, profiling it in Dependency Walker (on the dev box) causes it to crash with the error messages I mention in the original post. I've tried deploying the program to vanilla machines but it crashes at the same point as the program does when profiled with Dependency Walker, deploying the app to machines with Qt Creator installed causes no problems. The crashing from within Dependency Walker and also when running on the vanilla machines ceases once I make the changes as listed in post #8 above, but introduces new problems as I mention in #9.

I hope this is clearer (?)

Having said all of this, it seems as if the Qt documentation on QThread is actually wrong and that it should be used completely different from what the documentation suggests. I haven't yet had time to delve into it, but here's why I make this bold statement:

You're Doing It Wrong

Threading Without The Headache

So perhaps the problem lies with my subclassing of QThread and re-implementation of the run() function. I don't know yet.

If there is anything else you'd like to know, please ask as I don't know what information may or may not be of use in solving this problem.

Thanks for taking the time out to get involved!