Exception from moveToThread

[Phlucious]

I have a QObject subclass that does some heavy processing—let's call it Processor. It reads in data from a file (or two), does stuff to the data, then writes a new file. I would like to move Processor to another thread so that my main application can continue operation while it processes. To me this sounds like a classic use of QThread.

However, when I try QObject::moveToThread(), the program throws an exception and I can't figure out what I'm doing wrong. I'm trying to follow the concepts set forth here: http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/

Here's a version of my code. Processor* "proc" and QThread* processingThread are private class members of MainWindow.



processingThread = new QThread;
proc = new Processor(/*send stuff to the constructor*/); //nothing is passed to the QObject constructor, so it should have no parent
proc->moveToThread(processingThread); //exception here at QCoreApplication::notifyInternal(QObject*,QEvent*)
//connect signals and slots between the processor and a QProgressDialog "pdia"

/* start processing */
processingThreadstart();
QTimer::singleShot(0, proc, SLOT(beginProcessing()));
pdia->exec();

[wysota]

Exception as in C++ exception or as in Windows Exception?

[Phlucious]

It compiles fine, so Windows error? I'm not sure about the distinction. While running from Qt Creator in debug mode it reads:

The inferior stopped because it triggered an exception.
Stopped in thread 0 by: Exception at 0x0, code: 0xc00000005: write access violation at: 0x8, flags=0x0.


and sends me to line 876 of qcoreapplication.cpp.

Added after 6 minutes:

To tell you more about Processor, it has class members that are also QObjects and a QFlags typedef. Most of the members are initialized in its constructor. Perhaps I'm violating this rule from the docs?

The child of a QObject must always be created in the thread where the parent was created. This implies, among other things, that you should never pass the QThread object (this) as the parent of an object created in the thread (since the QThread object itself was created in another thread).

Added after 26 minutes:

Strangely, if I comment out all of the threading particulars, I get the same exception on the next line,


this->setEnabled(true);

"this" refers to the MainWindow. Now I'm completely stumped.

[wysota]

It compiles fine, so Windows error?
Khem... I meant C++ exceptions (http://www.cplusplus.com/doc/tutorial/exceptions/) and not compiler errors. But I take it that you really meant that your app crashes.


The inferior stopped because it triggered an exception.
Stopped in thread 0 by: Exception at 0x0, code: 0xc00000005: write access violation at: 0x8, flags=0x0.

Rebuild your project from scratch and it might go away. If not then somewhere in your code you are corrupting your own stack or you have a null pointer.

[Phlucious]

You were right about needing to rebuild from scratch. For some reason I've been having that problem quite often with this particular project. What might cause that issue?

[wysota]

Windows :)

[Phlucious]

lol, awesome. Windows + custom 64bit build of Qt 4.8 + MSVC2010, perhaps? ;)

[d_stranz]

This often happens in VC2008, especially if there have been lots of code changes in multiple compilation units. I especially notice that when a class is completely implemented within a header file (all inline methods, for example), or a header is being dragged in from an external project that has changed, all of that header's dependencies aren't necessarily rebuilt when required. Not using precompiled headers, either.

Sometimes you just have to do a clean rebuild. Another problem I have with VC2008 is that the executable will be relinked every time I start the debugger, even if I've just finished rebuilding and linking it. Just can't trust VS to get the dependencies right somehow.

Glad to know they've carried the problems over into VS2010.

[wysota]

Just to be fair. It also happens on Other Operating Systems and Compilers but it's a much more rare situation.

[d_stranz]

Just to be fair. It also happens on Other Operating Systems and Compilers but it's a much more rare situation.

True, but you don't have to pay thousands of USD per year for updates to those Other Operating Systems and Compilers like you do if you want to stay current with all the bug fixes and updates for Visual Studio... I guess maybe I am just naive to think that I should get the same quality as you have in those OOS&C when I have to pay for it.

[Phlucious]

I guess maybe I am just naive to think that I should get the same quality as you have in those OOS&C when I have to pay for it.

Alas, though, I cannot find a 64bit compiler that can compete with VC2010 in terms of reliability and stability... despite the rebuild issues.

[wysota]

Alas, though, I cannot find a 64bit compiler that can compete with VC2010 in terms of reliability and stability... despite the rebuild issues.

You mean stability of the compiler or the applications compiled with it? I use a 64b GCC and I don't have any stability issues in applications related to the use of this or that compiler. There is also LLVM which is said to be very good in terms of generated code.

When it comes to comparing compilers, have a look at what MSVC implements regarding C++11 standard and how it compares to GCC.

[Phlucious]

You mean stability of the compiler or the applications compiled with it?
Reliability of the compiler and stability of the applications built with it. It probably has as much to do with my lack of training (I'm about 80% self-taught... I'm a Civil Engineer by degree) as anything else, but I simply couldn't manage to build Qt using any of the 64bit compilers I looked at other than MSVC2010.

I use a 64b GCC and I don't have any stability issues in applications related to the use of this or that compiler.
Link? It'd be nice to use a compiler that plays nicely with Qt Creator's debugging system. It's been a while since I looked at http://mingw-w64.sourceforge.net/ but I didn't have much luck there. Again, though, that may have been my poor execution.

Your point regarding C++11 is a valid one. It'd be interesting to see if there's much of a performance boost.