nvda
nvda copied to clipboard
nvaccess
The `nvda.exe` process does not exit in time after Exit NVDA in some cases.
Related: #15920, #16072
Steps to reproduce:
In the context of the relevant issue:
NVDA+q, Exits NVDA
Actual behavior:
The nvda.exe process did not exit in time, but the log marked NVDA Exit. starting a new instance of NVDA in this case would not destroy the remaining nvda.exe either. It is also possible to experience a slow or frozen NVDA.
Expected behavior:
nvda.exe exits in a timely manner
NVDA logs, crash dumps and other attachments:
See related issues
System configuration
NVDA installed/portable/running from source:
maybe all
NVDA version:
See related issues
It's possible that most versions
Windows version:
See related issues
Name and version of other software in use when reproducing the issue:
See related issues
Other information about your system:
See related issues
Other questions
Does the issue still occur after restarting your computer?
yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
See related issues
If NVDA add-ons are disabled, is your problem still occurring?
yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
yes
This has been going on for a few nvda versions, but its not always, Its as if something else is using it. Could this be an add on? Brian
--
@.***
Sent via blueyonder.(Virgin media)
Please address personal E-mail to:-
@.***, putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: WangFeng Huang
To: nvaccess/nvda
Cc: Subscribed
Sent: Thursday, February 01, 2024 5:37 PM
Subject: [nvaccess/nvda] The nvda.exe process does not exit in time after Exit NVDA in some cases. (Issue #16123)
Related: #15920, #16072
Steps to reproduce: In the context of the relevant issue:
NVDA+q, Exits NVDA
Actual behavior: The nvda.exe process did not exit in time, but the log marked NVDA Exit. starting a new instance of NVDA in this case would not destroy the remaining nvda.exe either. It is also possible to experience a slow or frozen NVDA.
Expected behavior: nvda.exe exits in a timely manner
NVDA logs, crash dumps and other attachments: See related issues
System configuration NVDA installed/portable/running from source: maybe all
NVDA version: See related issues
It's possible that most versions
Windows version: See related issues
Name and version of other software in use when reproducing the issue: See related issues
Other information about your system: See related issues
Other questions Does the issue still occur after restarting your computer? yes
Have you tried any other versions of NVDA? If so, please report their behaviors. See related issues
If NVDA add-ons are disabled, is your problem still occurring? yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu? yes
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
The few Issue's I've seen so far don't seem to be caused by add-ons.
But add-ons may have the potential to cause this as well, maybe it's the use of external resources, or maybe it's the use of threads.
In any case, NVDA's failure to destroy the nvda.exe process that cannot be closed is something that needs to be improved.
While I cannot reproduce this on any of my machines, looking at the available data we can gather the following:
- Most of affected users seems to be from China
- As explained in #14974 NV Access web sites (mostly Add-ons Store) either cannot be accessed from there in some cases, or network connectivity to these servers is extremely slow
- For the moment lets assume that this issue is a duplicate of #15920 which explicitly states that before 2023.2 i.e. introduction of Add-on Store this was not a problem
- Add-on Store introduced two additional threads fetching the available data, though one of them is running only when user actually interacts with the store's GUI, and therefore may not be relevant here
W What seems to be important is that none of these new threads is daemonic i.e. NVDA's process will be active for as long as they're running. If the network connectivity to NV Access servers is slow they will also be slow to finish potentially blocking the entire process from exiting properly. While this theory is mostly a guess, I'd say that it is an educated one. @michaelDCurran @seanbudd I assume you have done some investigation into this issue. Is what I've written above sane and aligns with your conclusions? If it is I'd suggest to submit a Pr against RC making add-on Store threads daemonic and adding additional logging to the code which gets executed in these threads, just to make sure we can establish if it finishes and how long it takes to execute. This obviously assumes there was no good technical reason not to make these threads daemons in the first place.
Yes, all threads should be daemonic, though with some pretty serious error logging at the end of NVDA exit noting which threads are still alive and thus will be killed off.
However, there are also some c++ threads (particularly the nvdaHelperRemote inProcMgrThread) which does not correctly get stopped on NVDA exit either if it is inside NVDA itself.
And then #16072: It looks like somehow the UIA event limiter thread stays around also.
Thanks for connecting the dots with China and add-on store being inaccessible and thus may be causing a different thread state.
Message ID: @.***>
Thanks to @lukaszgo1 and @michaelDCurran
A series of investigations by @hwf1324 in #15920 appear to further support @lukaszgo1’s speculation.
I believe this can be closed now, fixed by the following PRs: #16174 #16183 #16205 #16198 #16222
