[Accessibility] Race condition with other UIAutomation instances?

[Stefan Krause]

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>:

> 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> *On Behalf
> Of *Stefan Krause
> *Sent:* onsdag 25. november 2020 13:35
> *To:* 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>:
>
> 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/20201215/67ac2f6a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stack.png
Type: image/png
Size: 34650 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/accessibility/attachments/20201215/67ac2f6a/attachment-0001.png>