linux windows thread differences

[marcofuics]

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?

[anda_skoa]

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,
_

[marcofuics]

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?

[anda_skoa]

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,
_

[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)

[yeye_olive]

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.

[anda_skoa]

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,
_