linux windows thread differences

Hi *

Hi have a multithread application,
On win32 it crashes like that:

QObject::setParent: Cannot set parent, new parent is in a different thread
[27 gen 2015 - 12:43:31.857] [5332] [W] QObject: Cannot create children for a pa
rent that is in a different thread.
(Parent is QwtPolarCanvas(0x7e61f0), parent's thread is QThread(0x30a7150), curr
ent thread is QThread(0x12fd1f0)
[27 gen 2015 - 12:43:31.872] [5332] [W] QObject::installEventFilter(): Cannot fi
lter events for objects in a different thread.
[27 gen 2015 - 12:43:49.740] [5332] [W] QObject::setParent: Cannot set parent, n
ew parent is in a different thread
[27 gen 2015 - 12:43:49.751] [5332] [F] ASSERT failure in QCoreApplication::send
Event: "Cannot send events to objects owned by a different thread. Current threa
d 12fd1f0. Receiver '' (of type 'QwtPolarCanvas') was created in thread 30a7150"
, file kernel\qcoreapplication.cpp, line 539


whilst on linux it goes well.

The source code, except some slight differentiation for selective-#define, is identical, and linux uses a gcc win32 use msvc/cl
There is some strange known behaviour for threads among these OS? Maybe there is a compiler flah to correct these crashes?

The error indicates that you are passing an object as a parent that lives in a different thread then the one currently executing the target object's constructor.

Check instance of where you pass a QwtPolarCanvas pointer to a QObject constructor, probably something like "this" inside a QwtPolarCanvas subclass.

Cheers,
_

Yep
I 'd like to fix the problem following the thread's num. values, but using the debuggee (windbg) I cant; just I can only see the QT::HANDLE ThreadID whilst the error writes the QThread* Handle (slightly different): 2 u know if there is a function (meta function like)

QThread* getThreadbyID( QT::HANDLE id ) ? Or how to reproduce it?

You could put a log output in each thread's constructor, or set a break point in QObject::setParent() at the place where it warns about this.

The usual way to handle this is to check where you threads construct objects with a parent.

Cheers,
_

This is the correct way to reach the solution... but im a little bit confused: why the same program on linux goes well whilst in win32 crashes (saying about these problems)

Quote:

---

Originally Posted by marcofuics

This is the correct way to reach the solution... but im a little bit confused: why the same program on linux goes well whilst in win32 crashes (saying about these problems)

---

There could be several reasons.
Do you manipulate all threads explicitly or do you user higher-level APIs like QtConcurrent which assign computations to threads in a manner that depends on the runtime environment?
Does the existence of parent-child relationships between QObjects in distinct threads depend on the scheduling of your threads?

You should review every creation of a QObject-derived object and make sure the parent (if any) lives in the thread that creates the child.

Quote:

---

Originally Posted by marcofuics

This is the correct way to reach the solution... but im a little bit confused: why the same program on linux goes well whilst in win32 crashes (saying about these problems)

---

You should also get the warnings on Linux, but whether something crashes can depend on a lot of things, especially when threads are involved.

Cheers,
_