Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
On Sunday, 27 September 2020 22:08:53 PDT Rainer Wiesenfarth wrote: > I found a workaround in our code by removing a call to > QCoreApplication::processEvents() and reorganizing some code. Remove all of them. Everywhere you're using them, they're wrong. The best solution is to replace them with a "return" and move the code that existed below that point to another slot or event. If you can't do that, then at least use QEventLoop and its quit() signal. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
Hi all, thanks for your assistance and hints! I found a workaround in our code by removing a call to QCoreApplication::processEvents() and reorganizing some code. Concerning your suggestions: - I can exclude not properly registered metatypes, as all signals are of type "void signal()" - I'll tend to also exclude objects living in the wrong thread as it only happens for one subclass and it works in Qt 5.12.5. Plus, the connection is (and is intended to be) a queued connection (even with sender and receiver in the same thread) My (wild) guess: it is a race condition, maybe related to the timer for handling posted events introduced between Qt 5.12.5 and Qt 5.15.0 - however, I do not have a more detailed analysis or specific cause. I'll try 5.15.x (with x > 0) some day, but as we use custom builds of Qt, this easily requires half a day per version - that is also the main reason why I do not use git bisect or a similar approach. Thanks again, and cheers Rainer -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Rob Reeder, Jürgen Kesper ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
No. Have neither time nor willing to create one... I don't believe it's not a wide spread case. But even if not - have no willing for this for now, sorry... On 9/26/2020 6:47 PM, Giuseppe D'Angelo wrote: On 26/09/2020 16:48, Alexander Dyagilev wrote: I'm not sure what you mean exactly, but I've seen many such situations (when connection did not work because metatype was not registered) and never saw any warnings anywhere. I mean that when you do a queued connection or a queued activation and some arguments are not registered, you should get a warning from Qt. The lack of such a warning is a bug. Do you have a testcase? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
Well, let me not to use it please, i want my app to continue to work lol.
On 9/26/2020 6:43 PM, Thiago Macieira wrote:
On Saturday, 26 September 2020 07:53:23 PDT Alexander Dyagilev wrote:
template
inline void qRegisterMyMetaType(const char *name)
{
if (QMetaType::type(name) == QMetaType::UnknownType)
qRegisterMetaType(name);
}
Better implementation:
template
inline void qRegisterMyMetaType(const char *name)
{
Q_UNUSED(name);
qRegisterMetaType();
}
#define Q_REGISTER_MY_METATYPE Q_DECLARE_METATYPE
This checks that whether the type is already registered without making a
function call.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
On 26/09/2020 16:53, Alexander Dyagilev wrote:
I use this helper macro for this (register a metatype in runtime):
template
inline void qRegisterMyMetaType(const char *name)
{
if (QMetaType::type(name) == QMetaType::UnknownType)
qRegisterMetaType(name);
}
#define Q_REGISTER_MY_METATYPE(type) qRegisterMyMetaType(#type);
Usage example:
Q_REGISTER_MY_METATYPE(QCryptographicHash::Algorithm);
This machinery is not strictly needed -- it's perfectly fine to call
qRegisterMetatype multiple times (you could for instance put it in
the constructor of T itself). The point is that you have to call it
before emitting (in case of a queued activation on an autoconnection) or
even before connecting (in case you're forcing a queued connection).
Either way, if you forget, Qt should emit a warning telling you exactly
what to do.
HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
On 26/09/2020 16:48, Alexander Dyagilev wrote: I'm not sure what you mean exactly, but I've seen many such situations (when connection did not work because metatype was not registered) and never saw any warnings anywhere. I mean that when you do a queued connection or a queued activation and some arguments are not registered, you should get a warning from Qt. The lack of such a warning is a bug. Do you have a testcase? -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
On Saturday, 26 September 2020 07:53:23 PDT Alexander Dyagilev wrote:
> template
> inline void qRegisterMyMetaType(const char *name)
> {
> if (QMetaType::type(name) == QMetaType::UnknownType)
> qRegisterMetaType(name);
> }
Better implementation:
template
inline void qRegisterMyMetaType(const char *name)
{
Q_UNUSED(name);
qRegisterMetaType();
}
#define Q_REGISTER_MY_METATYPE Q_DECLARE_METATYPE
This checks that whether the type is already registered without making a
function call.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
I use this helper macro for this (register a metatype in runtime):
template
inline void qRegisterMyMetaType(const char *name)
{
if (QMetaType::type(name) == QMetaType::UnknownType)
qRegisterMetaType(name);
}
#define Q_REGISTER_MY_METATYPE(type) qRegisterMyMetaType(#type);
Usage example:
Q_REGISTER_MY_METATYPE(QCryptographicHash::Algorithm);
:)
On 9/26/2020 5:48 PM, Alexander Dyagilev wrote:
I'm not sure what you mean exactly, but I've seen many such situations
(when connection did not work because metatype was not registered) and
never saw any warnings anywhere.
On 9/26/2020 12:02 PM, Giuseppe D'Angelo via Interest wrote:
Il 26/09/20 07:55, Alexander Dyagilev ha scritto:
Yeah, it's possible that some metatype (used in signal) is
registered in
Qt 5.12 and is NOT registered in Qt 5.15, thus connection does not work
between objects in different threads.
It's required to register it manually then.
Do you know of a case where this wouldn't spit the usual "arguments
are not registered" warning? (If so, that's a bug)
Thanks,
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
I'm not sure what you mean exactly, but I've seen many such situations (when connection did not work because metatype was not registered) and never saw any warnings anywhere. On 9/26/2020 12:02 PM, Giuseppe D'Angelo via Interest wrote: Il 26/09/20 07:55, Alexander Dyagilev ha scritto: Yeah, it's possible that some metatype (used in signal) is registered in Qt 5.12 and is NOT registered in Qt 5.15, thus connection does not work between objects in different threads. It's required to register it manually then. Do you know of a case where this wouldn't spit the usual "arguments are not registered" warning? (If so, that's a bug) Thanks, ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
> On 25 Sep 2020, at 21:26, Giuseppe D'Angelo via Interest > wrote: > > Il 24/09/20 17:55, Rainer Wiesenfarth ha scritto: >> - if I take the application built and running without this issue with Qt >> 5.12.5 and replace the DLLs with those from Qt 5.15.0, the issue appears. >> That means there is a change in the event handling between 5.12.5 and 5.15.0 >> that causes the issue to appear. > > It's super hard telling what might be going wrong without a testcase. > > I'd anyway start by using 5.15.1/2 (not 0) and actually recompiling the > application, just to exclude subtle binary compatibility breaks. > > You may also want to inspect the event posting and delivery (e.g. by > overriding QCA::notify(); and/or by using ETW tracing; and/or by posting and > dispatching your custom "metacall" events instead of using a queued > invocation in the same thread). > > HTH, > > -- > Giuseppe D’Angelo If none of the previous hints help, can you share more info about the event loop of the thread in which the receiving object lives? There have been changes to the event loop implementation on Windows in Qt 5.15, such as * 81408c0e76616b127c46779dc14bbcf084a3d87b * e0d80167c18b5a71acf4dac59f3e6f37292fa397 to better the integration with foreign event loops, but you should updating to 5.15.1 which has e.g fb6f62354ff8d29152db7cfa479b2689a25ae7a9 which fixes https://bugreports.qt.io/browse/QTBUG-85981 to fix one reported regression in such a scenario. Volker ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
Il 26/09/20 07:55, Alexander Dyagilev ha scritto: Yeah, it's possible that some metatype (used in signal) is registered in Qt 5.12 and is NOT registered in Qt 5.15, thus connection does not work between objects in different threads. It's required to register it manually then. Do you know of a case where this wouldn't spit the usual "arguments are not registered" warning? (If so, that's a bug) Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
Hello, Yeah, it's possible that some metatype (used in signal) is registered in Qt 5.12 and is NOT registered in Qt 5.15, thus connection does not work between objects in different threads. It's required to register it manually then. On 9/26/2020 12:31 AM, Harri Porten wrote: Hello Rainer, On Thu, 24 Sep 2020, Rainer Wiesenfarth wrote: I have a strange problem that for a certain queued signal/slot connection the signal is emitted, but the event does not reach the connected slot. This problem is reproducible in Qt 5.15.0, but does not occur in Qt 5.12.5. Unfortunately, the simple test program (see attached file) does not show the behavior. Last time I saw something like this happening the bug was sought in Qt. But then found in the application :) One of the QObjects lived in the wrong thread. Printing and comparing of QObject::thread() pointers helped to identify and fix the problem. A missing QObject::moveToThread() call iirc. Harri. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
Hello Rainer, On Thu, 24 Sep 2020, Rainer Wiesenfarth wrote: I have a strange problem that for a certain queued signal/slot connection the signal is emitted, but the event does not reach the connected slot. This problem is reproducible in Qt 5.15.0, but does not occur in Qt 5.12.5. Unfortunately, the simple test program (see attached file) does not show the behavior. Last time I saw something like this happening the bug was sought in Qt. But then found in the application :) One of the QObjects lived in the wrong thread. Printing and comparing of QObject::thread() pointers helped to identify and fix the problem. A missing QObject::moveToThread() call iirc. Harri. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)
Il 24/09/20 17:55, Rainer Wiesenfarth ha scritto: - if I take the application built and running without this issue with Qt 5.12.5 and replace the DLLs with those from Qt 5.15.0, the issue appears. That means there is a change in the event handling between 5.12.5 and 5.15.0 that causes the issue to appear. It's super hard telling what might be going wrong without a testcase. I'd anyway start by using 5.15.1/2 (not 0) and actually recompiling the application, just to exclude subtle binary compatibility breaks. You may also want to inspect the event posting and delivery (e.g. by overriding QCA::notify(); and/or by using ETW tracing; and/or by posting and dispatching your custom "metacall" events instead of using a queued invocation in the same thread). HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
