| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 4 | |
When I build in release mode and run my application, I get the following: QObject::moveToThread: Current thread (0x1d5f5b0) is not the object's thread (0x1d0b820). Cannot move to target thread (0x1d0b820) Nowhere in my code am I explicitly trying to move an object from one thread to another, and these errors don't seem to be happening in debug mode. I do create a worker thread on start-up to process some network signals, and this thread does communicate with the main thread via signals/slots. My application runs fine otherwise, but obviously somewhere under the covers an operation is failing, and this makes me nervous! Any ideas what this could be? Thanks, Bruno
On Friday 16 February 2007, Bruno Trindade wrote: > QObject::moveToThread: Current thread (0x1d5f5b0) is not the object's > thread (0x1d0b820). > Cannot move to target thread (0x1d0b820) > My application runs fine otherwise, but obviously somewhere under the > covers an operation is failing, and this makes me nervous! Any ideas > what this could be? Are you reparenting some objects? The setParent method of QObject contains these lines: if(thread()!=parent->thread()) moveToThread(parent->thread()); (actually it's a bit more cryptic, but I hope you get the point) The moveToThread call can only be called from the thread the object currently belongs to (apparently for safety reasons). The consequence is: if moveToThread fails, setParent also fails and the object is not reparented. The solution is quite easy: for all objects that (potentially) survive the worker thread make sure they live in the main thread by explicitly calling moveToThread on creation. But also be aware that queued signal-slot-connections are executed in the main thread then. Konrad
Attachment:
Attachment:
pgpATxzIUzk68.pgp
Description: PGP signature
Message 3 in thread
No, I am not calling setParent anywhere. I heard one suggestion from
someone who has run into this before - he didn't reply to the list,
so I'll reproduce his email below. I don't fully understand what he
means, but have not heard back from him yet. Here's what he wrote:
"
I get this when I've deployed/bundled the qt libs into myapp.app on a
mac. renaming your qt install dir or moving the exe to another solves
the problem.
"
I don't see how either renaming the Qt install dir or moving the
executable could solve this. I am including the frameworks within
the bundle, and ran install_name_tool as appropriate so those bundled
copies of the frameworks will be used.
Thanks,
Bruno
On Feb 17, 2007, at 4:33 AM, Konrad Rosenbaum wrote:
> On Friday 16 February 2007, Bruno Trindade wrote:
>> QObject::moveToThread: Current thread (0x1d5f5b0) is not the object's
>> thread (0x1d0b820).
>> Cannot move to target thread (0x1d0b820)
>
>> My application runs fine otherwise, but obviously somewhere under the
>> covers an operation is failing, and this makes me nervous! Any ideas
>> what this could be?
>
> Are you reparenting some objects? The setParent method of QObject
> contains
> these lines:
>
> if(thread()!=parent->thread())
> moveToThread(parent->thread());
>
> (actually it's a bit more cryptic, but I hope you get the point)
>
> The moveToThread call can only be called from the thread the object
> currently belongs to (apparently for safety reasons).
>
> The consequence is: if moveToThread fails, setParent also fails and
> the
> object is not reparented.
>
> The solution is quite easy: for all objects that (potentially)
> survive the
> worker thread make sure they live in the main thread by explicitly
> calling
> moveToThread on creation. But also be aware that queued
> signal-slot-connections are executed in the main thread then.
>
>
> Konrad
--
[ signature omitted ]
Message 4 in thread
Bruno Trindade wrote:
> No, I am not calling setParent anywhere. I heard one suggestion from
> someone who has run into this before - he didn't reply to the list, so
> I'll reproduce his email below. I don't fully understand what he
> means, but have not heard back from him yet. Here's what he wrote:
>
> "
> I get this when I've deployed/bundled the qt libs into myapp.app on a
> mac. renaming your qt install dir or moving the exe to another solves
> the problem.
> "
That was mine. I responded a few weeks later with the correct solution.
>
> I don't see how either renaming the Qt install dir or moving the
> executable could solve this. I am including the frameworks within the
> bundle, and ran install_name_tool as appropriate so those bundled
> copies of the frameworks will be used.
Did you check if your application loads plugins not included in your
bundle? My problem was Qt image plugins outside of the bundle being
loaded, and bringing with them another copy of Qt libraries specified in
their embedded path. My bundle had shared Qt libraries already. I
didn't think the Mac loader capable of that. Maybe it depends on the
system calls Qt makes to load plugins on the mac. If fixed my
particular problem by adding a qt.conf file to prevent loading external
plugins that I didn't need.
I think it boils down to two basic ways to make this happen:
Two Qt libraries in one application, or actually making the mistake in a
multi threaded application.
If it was all shared Qt libraries, and a single threaded application,
you can look at the list of libraries the debugger says are loaded.
Clint
--
[ signature omitted ]
Message 5 in thread
Hi,
i had the same problem, from my experience this arises when plugins are
loaded with different Qt .dll's
Are you statically linking? Then no plugins should be loaded, but As of
yet, they will still load and cause those messages - see issue 149912:
http://www.trolltech.com/developer/task-tracker/index_html?method=entry&;
id=149912
i guess the same problem could occur when you use release .dll's in your
app, but the plugins are using debug .dll's ...
You can easily check if the plugins are the cause of your problems by
calling QImageReader::supportedImageFormats() and see if this emits the
messages, like this:
#include <QImageReader>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QImageReader::supportedImageFormats(); // will check for plugins
}
Cheers,
Peter Prade
--
[ signature omitted ]
Message 6 in thread
yep, that's it.
If you deploy the app bundle, just plan on running it on another machine.
On 2/19/07, Peter Prade <prade@xxxxxxxxxxx> wrote:
> Hi,
>
> i had the same problem, from my experience this arises when plugins are
> loaded with different Qt .dll's
>
> Are you statically linking? Then no plugins should be loaded, but As of
> yet, they will still load and cause those messages - see issue 149912:
> http://www.trolltech.com/developer/task-tracker/index_html?method=entry&;
> id=149912
>
> i guess the same problem could occur when you use release .dll's in your
> app, but the plugins are using debug .dll's ...
>
> You can easily check if the plugins are the cause of your problems by
> calling QImageReader::supportedImageFormats() and see if this emits the
> messages, like this:
>
> #include <QImageReader>
>
> int main(int argc, char *argv[])
> {
> QApplication a(argc, argv);
> QImageReader::supportedImageFormats(); // will check for plugins
> }
>
> Cheers,
> Peter Prade
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]