Repository: nvaccess/nvda

Issue:
NVDA hangs up in terminal, when a large piece of text is loaded
I know that normal user doesn't have this problem.
But developers, mainly developers working in terminal, could have.

When large piece of text is loaded to the terminal at the same time, for example, 10000 characters of more, NVDA is hanging up. Also, after a moment, the system hangs up.
The only way is to wait.
NVDA is not reading the text, it's reading pieces of text, then a moment of silence, different piece, silence...

For example, I can call this in ruby by writing

for i in 1..100000
print("A fragment number #{i.to_s} ")
end

Also, we can find this error, when we'll using in terminal app, which writes big pieces of text.
In console commands, like tree, we won't observe this eror, because it isn't loading of text at the same time, there's a while between printing new files.

What is interesting...
The problem is hanging up the all system, you can not open task manager or other apps.

Thank you for help
Greetings,
Dawid Pieper



Discussion:
What version and build of Windows are you using? We noticed severe performance problems with consoles in earlier builds of Windows 10, but this appears to be fixed in the anniversary update at least.

Thank you for you reply.
i'm using Windows 7 SP1 6.1.7601, but I had this problem on Windows 8.1 too, with all updates on May.
Regards,
DP
  ----- Original Message ----- 
  From: James Teh 
  To: nvaccess/nvda 
  Cc: Dawid Pieper ; Author 
  Sent: Tuesday, August 23, 2016 12:19 AM
  Subject: Re: [nvaccess/nvda] NVDA hangs up in terminal, when a large piece of text is loaded (#6291)

  What version and build of Windows are you using? We noticed severe performance problems with consoles in earlier builds of Windows 10, but this appears to be fixed in the anniversary update at least.

  —
  You are receiving this because you authored the thread.
  Reply to this email directly, view it on GitHub, or mute the thread.

I have also observed this behavior.
Specifically when NVDA is set to speak typed characters, but I still also get it sometimes when this is not true. I often have to restart NVDA with the hotkey to get my system back.

@dawidpieper @ctoth Do you still experience this freeze in the terminal (almost two years after the original report)?
I can confirm, that this issue is still present on Windows 7 ad least. The only way to restore NVDA to it's working condition is to switch user with CTRL+Alt+Delete and kill NVDA process from the second account. Any chance of prioritizing this? To be honest when i have to work in terminal and I am suspecting, that big amount of text would be displayed I am  switching to JAWS, because fighting with frozen NVDA is the last thing, which I want to do in the middle of my programming classes.
cc @michaelDCurran @feerrenrut 
I am able to reproduce it 100% of the time with the c program attached. In the rare situations in which NVDA crashes softly enough to log anything the  log contains
WARNING - watchdog._watcher (23:30:46.661):
Core frozen in stack:
  File "nvda.pyw", line 227, in <module>
  File "core.pyc", line 516, in main
  File "wx\core.pyc", line 2134, in MainLoop
  File "gui\__init__.pyc", line 985, in Notify
  File "core.pyc", line 487, in run
  File "queueHandler.pyc", line 86, in pumpAll
  File "queueHandler.pyc", line 50, in flushQueue
  File "comtypesMonkeyPatches.pyc", line 54, in newCpbDel
  File "comtypes\__init__.pyc", line 919, in __del__
  File "comtypes\__init__.pyc", line 1174, in Release
  File "winConsoleHandler.pyc", line 142, in consoleWinEventHook
  File "wincon.pyc", line 69, in GetConsoleScreenBufferInfo
[6291.zip](https://github.com/nvaccess/nvda/files/2678004/6291.zip)

The program attached is of course not very useful, but it demonstrates the issue pretty well.
It happened again when installing a bunch of dependencies with Pip. Am I really the only one experiencing this?
I recall I've seen this issue as well, and I have an idea to improve this, at least in such a way that you no longer have to fiddle with signing out and back in again.
You're not the only one. I'm used to it by now, and just alt tab out as fast as I can.
I don't think I've had to sign out in a while. Running your test program, NVDA freezes, but I can still press windows+m to go to the desktop and ALT+CTRL+n works to restart NVDA.

Resolving patch:
diff --git a/source/winInputHook.py b/source/winInputHook.py
--- a/source/winInputHook.py
+++ b/source/winInputHook.py
@@ -10,6 +10,7 @@
 from ctypes import *
 from ctypes.wintypes import *
 from win32con import WM_QUIT, HC_ACTION, WH_KEYBOARD_LL, LLKHF_UP, LLKHF_EXTENDED, LLKHF_INJECTED, WH_MOUSE_LL, LLMHF_INJECTED
+import watchdog
 
 class KBDLLHOOKSTRUCT(Structure):
 	_fields_=[
@@ -35,7 +36,7 @@ class MSLLHOOKSTRUCT(Structure):
 
 @WINFUNCTYPE(c_long,c_int,WPARAM,LPARAM)
 def keyboardHook(code,wParam,lParam):
-	if code!=HC_ACTION:
+	if watchdog.isAttemptingRecovery or code!=HC_ACTION:
 		return windll.user32.CallNextHookEx(0,code,wParam,lParam)
 	kbd=KBDLLHOOKSTRUCT.from_address(lParam)
 	if keyUpCallback and kbd.flags&LLKHF_UP:
@@ -48,7 +49,7 @@ def keyboardHook(code,wParam,lParam):
 
 @WINFUNCTYPE(c_long,c_int,WPARAM,LPARAM)
 def mouseHook(code,wParam,lParam):
-	if code!=HC_ACTION:
+	if watchdog.isAttemptingRecovery or code!=HC_ACTION:
 		return windll.user32.CallNextHookEx(0,code,wParam,lParam)
 	msll=MSLLHOOKSTRUCT.from_address(lParam)
 	if mouseCallback:


Test patch: