Qt-interest Archive, July 2007
qicon related bug ?
Message 1 in thread
hi,
using qt4.2.3/4.3 on osx, 10.4.9, anytime, i try to
use a qicon, such as setting it on a button, i am
getting following qwarning:
"QObject::moveToThread: Current thread (0x2c4b7c0) is
not the object's thread (0x2c07620).
Cannot move to target thread (0x2c07620)"
any idea what may be wrong and/or how to disable the
warning?
appreciate any help/pointers..
this is the debug trace:
#0 QObject::moveToThread (this=0x1215fdb0,
targetThread=0x1210e170) at
kernel/qobject.cpp:1368
#1 0x0fec4e8c in QFactoryLoader::instance
(this=0x121d0e60,
key=@0x121aa5a4) at plugin/qfactoryloader.cpp:175
#2 0x02ac63dc in createReadHandler
(device=0x121396c0,
format=@0x121d7a90) at image/qimagereader.cpp:254
#3 0x02ac8828 in QImageReaderPrivate::initHandler
(this=0x121d7a90) at
image/qimagereader.cpp:509
#4 0x02ac8e58 in QImageReader::read (this=0xbfff903c,
image=0xbfff8fb8)
at image/qimagereader.cpp:975
#5 0x02ac9bd0 in QImageReader::read (this=0xbfff903c)
at
image/qimagereader.cpp:939
#6 0x02add328 in QPixmap::load (this=0xbfff914c,
fileName=@0x121b803c,
format=0x0, flags=@0xbfff90d8) at
image/qpixmap.cpp:616
#7 0x02add7fc in QPixmap::QPixmap (this=0xbfff914c,
fileName=@0x121b803c,
format=0x0, flags=@0xbfff9148) at
image/qpixmap.cpp:168
#8 0x02ab0368 in QPixmapIconEngine::bestMatch
(this=0x121b7fb0,
size=@0xbfffab30, mode=Normal, state=Off,
sizeOnly=false) at
image/qicon.cpp:230
#9 0x02ab0594 in QPixmapIconEngine::pixmap
(this=0x121b7fb0,
size=@0xbfffab30, mode=Normal, state=Off) at
image/qicon.cpp:241
#10 0x02aad12c in QIcon::pixmap (this=0xbfffab2c,
size=@0xbfffab30,
mode=Normal, state=Off) at image/qicon.cpp:636
#11 0x02cf8fb8 in QMacStyle::drawControl
(this=0x1210f8b0, ce=<unknown
type>, opt=0xbfffaaf8, p=0xbfffcd48, w=0x121cd9b0) at
styles/qmacstyle_mac.cpp:3239
#12 0x02cba454 in QCommonStyle::drawControl
(this=0x1210f8b0,
element=<unknown type>, opt=0xbfffcd54, p=0xbfffcd48,
widget=0x121cd9b0)
at styles/qcommonstyle.cpp:733
#13 0x02d6f8f4 in QWindowsStyle::drawControl
(this=0x1210f8b0, ce=<unknown
type>, opt=0xbfffcd54, p=0xbfffcd48,
widget=0x121cd9b0) at
styles/qwindowsstyle.cpp:2465
#14 0x02cfce20 in QMacStyle::drawControl
(this=0x1210f8b0, ce=<unknown
type>, opt=0xbfffcd54, p=0xbfffcd48, w=0x121cd9b0) at
styles/qmacstyle_mac.cpp:3832
#15 0x03139d38 in QStylePainter::drawControl
(this=0xbfffcd48, ce=<unknown
type>, opt=@0xbfffcd54) at widgets/qcheckbox.cpp:69
#16 0x02e45f08 in QPushButton::paintEvent
(this=0x121cd9b0) at
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/
--
[ signature omitted ]
Message 2 in thread
kahava find schrieb:
> hi,
>
> using qt4.2.3/4.3 on osx, 10.4.9, anytime, i try to
> use a qicon, such as setting it on a button, i am
> getting following qwarning:
>
>
> "QObject::moveToThread: Current thread (0x2c4b7c0) is
> not the object's thread (0x2c07620).
> Cannot move to target thread (0x2c07620)"
Are you using threads? If so (and it appears so): are you trying to set
the icon from within a non-GUI (aka main) thread? This would be forbidden.
Use queued connections (Qt 4) or custom events (Qt 3/4) and
QApplication::postEvent() as to synchronise your paint (GUI) events with
the Qt event loop (= the main/GUI thread).
Also search the interest archive for more details - there have been
other discussions going on about this thread issue (and actually since
ever in the past 5 years ;)
Cheers, Oliver
--
[ signature omitted ]
Message 3 in thread
Thank you for taking time to respond. inline:
--- Till Oliver Knoll <oliver.knoll@xxxxxxxxxxx>
wrote:
> kahava find schrieb:
> > hi,
> >
> > using qt4.2.3/4.3 on osx, 10.4.9, anytime, i try
> to
> > use a qicon, such as setting it on a button, i am
> > getting following qwarning:
> >
> >
> > "QObject::moveToThread: Current thread (0x2c4b7c0)
> is
> > not the object's thread (0x2c07620).
> > Cannot move to target thread (0x2c07620)"
>
> Are you using threads? If so (and it appears so):
Yes.
> are you trying to set
> the icon from within a non-GUI (aka main) thread?
> This would be forbidden.
>
No, This is being set in main GUI thread only.
In fact, I get the warning even if I try to set Icon
on any button/windget
in the main window.
> Use queued connections (Qt 4) or custom events (Qt
> 3/4) and
> QApplication::postEvent() as to synchronise your
> paint (GUI) events with
> the Qt event loop (= the main/GUI thread).
>
> Also search the interest archive for more details -
> there have been
> other discussions going on about this thread issue
> (and actually since
> ever in the past 5 years ;)
>
Ok. Thank you for the pointers. Will definately do..
> Cheers, Oliver
>
> --
> 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/
>
>
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/
--
[ signature omitted ]
Message 4 in thread
kahava find schrieb:
>> ...
>> are you trying to set
>> the icon from within a non-GUI (aka main) thread?
>> This would be forbidden.
>>
> No, This is being set in main GUI thread only.
> In fact, I get the warning even if I try to set Icon
> on any button/windget
> in the main window.
Just to get rid of a possible confusion: I was talking about threads
(and you initially as well). Later on you metioned the main /window/.
You are not confusing those two things, right?
Anyway, if you really just manipulate the GUI from within the main
/thread/ then everything should be fine - no need for queued signals or
custom events.
A note on queued signals: I have read somewhere that depending on /when/
the connect() is done Qt::AutoConnection can be a pitfall: only when the
two objects to be connected are associated with /different/ threads (see
QObject::thread()) at that time a Qt::QueuedConnection is done!
For example this is *not* the case in this scenario (doing the
connection in the c'tor of a QThread based class):
class MyWorkerThread : public QThread
{
public:
/*! c'tor */
MyWorkerThread (SomeGuiObject *someGuiObject, QObject *parent = 0) {
// this WON'T do a queued connection!!!
this->connect (this, SIGNAL (someWorkDone()),
someGuiObject, SLOT (update()));
}
...
};
Why is that? Because when you create this MyWorkerThread from within the
GUI (main) thread (where also the 'someGuiObject' lives) the c'tor is
still executed in the context of the /GUI/ thread! Hence the
Qt::AutoConnection will become a Qt::DirectConnection which is /not/
what you want here!
To make sure always set the 5th parameter in the connect() call
explicitly to Qt::QueuedConnection.
Also note again that /both/ threads need a running event queue, else
queued signals won't work. If you cannot have an event queue for some
reasons in the worker thread then use QCustomEvents. Remember to use
QApplication::postEvent and *not* QApplication::sendEvent() (another
pitfall).
Cheers, Oliver
--
[ signature omitted ]
Message 5 in thread
On 19.07.07 12:53:52, Till Oliver Knoll wrote:
> Also note again that /both/ threads need a running event queue, else queued
> signals won't work.
Why that? I'd think that I need a even loop in the non-gui thread only
if it wants to receive signals from another thread. And the API docs for
QThread state this as well, so as long as my custom thread only sends
out queued signals everything should be fine.
> If you cannot have an event queue for some reasons in the
> worker thread then use QCustomEvents. Remember to use QApplication::postEvent
> and *not* QApplication::sendEvent() (another pitfall).
Huh? How can you post an event to a thread that doesn't run an event
loop?
Andreas
--
[ signature omitted ]
Message 6 in thread
Andreas Pakulat schrieb:
> On 19.07.07 12:53:52, Till Oliver Knoll wrote:
>> Also note again that /both/ threads need a running event queue, else queued
>> signals won't work.
>
> Why that? I'd think that I need a even loop in the non-gui thread only
> if it wants to receive signals from another thread. And the API docs for
> QThread state this as well, so as long as my custom thread only sends
> out queued signals everything should be fine.
Doh... sorry, I was wrong: I thought I had read somewhere/sometimes that
/both/ threads need an event loop running for queued signals to work.
Now thinking about that for another 5 seconds this makes off course
absolutely no sense: only the receiving thread needs an event queue
running (just as for custom events with QApplication::post()).
[ In fact (without looking at the Qt sources) I believe that queued
signals are "mapped" to an "internal custom event" and ultimately
delivered with QApplication::post() to the receiving thread. ]
In other words: you can /always/ send queued signals from any thread
(other than the GUI thread) to the GUI thread which will almost always
have an event queue running (that is, QApplication::exec() has been
called somewhere in the main() function).
>> If you cannot have an event queue for some reasons in the
>> worker thread then use QCustomEvents. Remember to use QApplication::postEvent
>> and *not* QApplication::sendEvent() (another pitfall).
>
> Huh? How can you post an event to a thread that doesn't run an event
> loop?
Given my false assumption above (wrong: "both threads need an event
queue running for queued signals") I thought that you could at least
post custom events from any other (worker) thread to the GUI thread
(which has an event queue running), so whenever some work has been done
the GUI can safely be updated.
I never thought about the scenario of posting custom events from the GUI
thread to any other thread, which off course is not possible if no event
queue is running there.
Thanks, Oliver
--
[ signature omitted ]
Message 7 in thread
--- Till Oliver Knoll <oliver.knoll@xxxxxxxxxxx>
wrote:
> kahava find schrieb:
> >> ...
> >> are you trying to set
> >> the icon from within a non-GUI (aka main) thread?
> >> This would be forbidden.
> >>
> > No, This is being set in main GUI thread only.
> > In fact, I get the warning even if I try to set
> Icon
> > on any button/windget
> > in the main window.
>
> Just to get rid of a possible confusion: I was
> talking about threads
> (and you initially as well). Later on you metioned
> the main /window/.
> You are not confusing those two things, right?
>
right.
> Anyway, if you really just manipulate the GUI from
> within the main
> /thread/ then everything should be fine - no need
> for queued signals or
> custom events.
>
that is what i thought so, after much debugging, the
problem seems to be inconsistent internal threadData
variable with the thread variable within qobject right
from the very first time qapplication object is
instantiated. later on i get warning about the same
inconsistency :/
not sure what to do to avoid this --
116 qapp = new QApplication(argc, argv);
(gdb) print QThread::currentThread()
$1 = (QThread *) 0x12107550
(gdb) n
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
123
(gdb) print qapp->thread()
$2 = (QThread *) 0x12107550
(gdb) print qapp->self->d_func()->threadData
$3 = (QThreadData *) 0x121074c0
> A note on queued signals: I have read somewhere that
> depending on /when/
> the connect() is done Qt::AutoConnection can be a
> pitfall: only when the
> two objects to be connected are associated with
> /different/ threads (see
> QObject::thread()) at that time a
> Qt::QueuedConnection is done!
>
> For example this is *not* the case in this scenario
> (doing the
> connection in the c'tor of a QThread based class):
>
> class MyWorkerThread : public QThread
> {
> public:
> /*! c'tor */
> MyWorkerThread (SomeGuiObject *someGuiObject,
> QObject *parent = 0) {
> // this WON'T do a queued connection!!!
> this->connect (this, SIGNAL (someWorkDone()),
> someGuiObject, SLOT (update()));
> }
> ...
> };
>
> Why is that? Because when you create this
> MyWorkerThread from within the
> GUI (main) thread (where also the 'someGuiObject'
> lives) the c'tor is
> still executed in the context of the /GUI/ thread!
> Hence the
> Qt::AutoConnection will become a
> Qt::DirectConnection which is /not/
> what you want here!
>
> To make sure always set the 5th parameter in the
> connect() call
> explicitly to Qt::QueuedConnection.
>
> Also note again that /both/ threads need a running
> event queue, else
> queued signals won't work. If you cannot have an
> event queue for some
> reasons in the worker thread then use QCustomEvents.
> Remember to use
> QApplication::postEvent and *not*
> QApplication::sendEvent() (another
> pitfall).
>
> Cheers, Oliver
>
> --
> 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/
>
>
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting
--
[ signature omitted ]
Message 8 in thread
--- kahava find <findkahava@xxxxxxxxx> wrote:
>
> --- Till Oliver Knoll <oliver.knoll@xxxxxxxxxxx>
> wrote:
>
> > kahava find schrieb:
> > >> ...
> > >> are you trying to set
> > >> the icon from within a non-GUI (aka main)
> thread?
> > >> This would be forbidden.
> > >>
> > > No, This is being set in main GUI thread only.
> > > In fact, I get the warning even if I try to set
> > Icon
> > > on any button/windget
> > > in the main window.
> >
> > Just to get rid of a possible confusion: I was
> > talking about threads
> > (and you initially as well). Later on you metioned
> > the main /window/.
> > You are not confusing those two things, right?
> >
> right.
>
> > Anyway, if you really just manipulate the GUI from
> > within the main
> > /thread/ then everything should be fine - no need
> > for queued signals or
> > custom events.
> >
> that is what i thought so, after much debugging, the
> problem seems to be inconsistent internal threadData
> variable with the thread variable within qobject
> right
> from the very first time qapplication object is
> instantiated. later on i get warning about the same
> inconsistency :/
> not sure what to do to avoid this --
>
Sorry, I should correct myself. qapp->thread() is same
as qapp->self->d_func()->threadData->thread. I missed
the last pointer hop.
However, I was definately running into some bug within
Qt and the debug trace that I sent in very first mail.
The error message from line qobject:1388, where it
should display
"d->threadData->thread", it was displaying the same
pointer as
"qapp->self->d_func()->threadData".
I am happy to report that we have bypassed this error
by creating
QIcon from a binary image instead of a file image.
>
> 116 qapp = new QApplication(argc, argv);
> (gdb) print QThread::currentThread()
> $1 = (QThread *) 0x12107550
> (gdb) n
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> 123
> (gdb) print qapp->thread()
> $2 = (QThread *) 0x12107550
> (gdb) print qapp->self->d_func()->threadData
> $3 = (QThreadData *) 0x121074c0
>
>
> > A note on queued signals: I have read somewhere
> that
> > depending on /when/
> > the connect() is done Qt::AutoConnection can be a
> > pitfall: only when the
> > two objects to be connected are associated with
> > /different/ threads (see
> > QObject::thread()) at that time a
> > Qt::QueuedConnection is done!
> >
> > For example this is *not* the case in this
> scenario
> > (doing the
> > connection in the c'tor of a QThread based class):
> >
> > class MyWorkerThread : public QThread
> > {
> > public:
> > /*! c'tor */
> > MyWorkerThread (SomeGuiObject *someGuiObject,
> > QObject *parent = 0) {
> > // this WON'T do a queued connection!!!
> > this->connect (this, SIGNAL (someWorkDone()),
> > someGuiObject, SLOT
> (update()));
> > }
> > ...
> > };
> >
> > Why is that? Because when you create this
> > MyWorkerThread from within the
> > GUI (main) thread (where also the 'someGuiObject'
> > lives) the c'tor is
> > still executed in the context of the /GUI/ thread!
> > Hence the
> > Qt::AutoConnection will become a
> > Qt::DirectConnection which is /not/
> > what you want here!
> >
> > To make sure always set the 5th parameter in the
> > connect() call
> > explicitly to Qt::QueuedConnection.
> >
> > Also note again that /both/ threads need a running
> > event queue, else
> > queued signals won't work. If you cannot have an
> > event queue for some
> > reasons in the worker thread then use
> QCustomEvents.
> > Remember to use
> > QApplication::postEvent and *not*
> > QApplication::sendEvent() (another
> > pitfall).
> >
> > Cheers, Oliver
> >
> > --
> > 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/
> >
> >
>
>
>
>
>
____________________________________________________________________________________
> Building a website is a piece of cake. Yahoo! Small
> Business gives you all the tools to get online.
> http://smallbusiness.yahoo.com/webhosting
>
> --
> 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/
>
>
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
--
[ signature omitted ]
Message 9 in thread
kahava find schrieb:
> > ...
> I am happy to report that we have bypassed this error
> by creating
> QIcon from a binary image instead of a file image.
"Binary image"? You mean binary image as in "Binary image versus ASCII
art"? 8-)
You probably meant /embedded/ image ... ;)
Funny though that this has an influence on the thread-affinity of
QObjects... but in the end you seem to have a working solution (that's
"engineering": when it works, then it works - don't touch it! ;) )
Cheers, Oliver
--
[ signature omitted ]
