From Jan-Arve.Saether at qt.io  Tue Jan  5 13:39:05 2021
From: Jan-Arve.Saether at qt.io (=?utf-8?B?SmFuLUFydmUgU8OmdGhlcg==?=)
Date: Tue, 5 Jan 2021 12:39:05 +0000
Subject: [Accessibility] Race condition with other UIAutomation
	instances?
In-Reply-To: <CAMr-Pg2HsjVHEL7Hj0tRBrPbmD+qrq-ja=ChZHgf4T10KuFvtQ@mail.gmail.com>
References: <CAMr-Pg3XQk7H7kZjo=fM8ZEuXML3C0Y66t-=P6dkvaAqR2op2w@mail.gmail.com>
 <CAMr-Pg1efDTJOaiQ9zYp_oPBFnTe-C53AtSWSHO7Sdg0JQHYqw@mail.gmail.com>
 <AM6PR0202MB3320364E64AE0CEB9B44AD0FCDCA0@AM6PR0202MB3320.eurprd02.prod.outlook.com>
 <CAMr-Pg2HsjVHEL7Hj0tRBrPbmD+qrq-ja=ChZHgf4T10KuFvtQ@mail.gmail.com>
Message-ID: <AM6PR0202MB33201BCCD70111FEFEA58707CDD10@AM6PR0202MB3320.eurprd02.prod.outlook.com>

Thanks. That stack trace is not worth much without debug information unfortunately.
AFAIK, UI automation handlers are added on initialization, (and released on termination I guess). I don’t think they are added/removed dynamically.

If its easy for you to create a stub to reproduce it, I can create a bug report for it. Unfortunately with the current information its not easy to see what the actual problem could be.

Jan Arve

From: Stefan Krause <stepkraus1 at gmail.com>
Sent: tirsdag 15. desember 2020 11:53
To: Jan-Arve Sæther <Jan-Arve.Saether at qt.io>; accessibility at qt-project.org
Subject: Re: [Accessibility] Race condition with other UIAutomation instances?

Thanks for getting back.
Last month I compiled Qt 5.15.2 with  -no-feature-accessibility. Since then those random crashes are gone.
However, I still have a screenshot of the stack trace.

Are UI Automation event handlers added/removed within the Qt code? I think it says somewhere in the UI Automation docs that this must not happen in multiple threads. If that's the case, it looks like a developer might cluelessly step into this race condition "trap" when working with UI Automation on their own.

Am Fr., 11. Dez. 2020 um 17:52 Uhr schrieb Jan-Arve Sæther <Jan-Arve.Saether at qt.io<mailto:Jan-Arve.Saether at qt.io>>:
You can most likely avoid it with configuring with -no-feature-accessibility.
Does the stack trace provide any valuable info for us do you think? If so, can we see it?

Race conditions can be many things, but I noticed that we don’t seem to do atomic increment/decrement (on AddRef()/Release() in the QWindowsUiaMainProvider in the platform plugin. That could be the cause.

It would also be valuable to know if it happens with any widget, or if its limited to a specific widget type.

Jan Arve

From: Accessibility <accessibility-bounces at qt-project.org<mailto:accessibility-bounces at qt-project.org>> On Behalf Of Stefan Krause
Sent: onsdag 25. november 2020 13:35
To: accessibility at qt-project.org<mailto:accessibility at qt-project.org>
Subject: Re: [Accessibility] Race condition with other UIAutomation instances?

Maybe someone can give me a hint whether this problem could be avoided by building Qt with configuration -no-feature-accessibility.

Thanks in advance!

Am Mi., 25. Nov. 2020 um 00:19 Uhr schrieb Stefan Krause <stepkraus1 at gmail.com<mailto:stepkraus1 at gmail.com>>:
Hi there,

I have a somewhat general question regarding the usage of Microsoft's UIAutomation framework in Qt apps.

The story is, I have developed a QWidget-based desktop application that relies on an own instance of UIAutomation (the app analyzes user interfaces of other applications running on Windows). This has worked great so far while I did not update Qt and instead used Qt 5.6 for years (a version long before UIAutomation got introduced to Qt). I have recently updated Qt to 5.15.0. Since then my app unfortunately crashes occasionally with an access violation in QtCore.dll. Further below in the call stack I can see that UIAutomation is involved. It could be a race condition.

My question is, could it be that one is not allowed anymore to work with an own instance of UIAutomation since Qt 5.11 and higher? I'm suspecting this because I saw the identical crash/call stack when I accidentally worked with separate instances of UIAutomation in separate threads within my application.

Is there maybe a way to turn off QAccessibility entirely?

Any clarification (or at least a hint) would be greatly appreciated!

Also, please let me know in case this is the place for this kind of question.

Best
Stefan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/accessibility/attachments/20210105/4749eec7/attachment.html>