NVDA hangs up in terminal, when a large piece of text is loaded

[dawidpieper]

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

[jcsteh]

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.

[dawidpieper]

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.

[ctoth]

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.

[bhavyashah]

@dawidpieper @ctoth Do you still experience this freeze in the terminal (almost two years after the original report)?

[lukaszgo1]

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.

[lukaszgo1]

cc @michaelDCurran @feerrenrut

[lukaszgo1]

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

The program attached is of course not very useful, but it demonstrates the issue pretty well.

[lukaszgo1]

It happened again when installing a bunch of dependencies with Pip. Am I really the only one experiencing this?

[LeonarddeR]

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.

[tspivey]

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.

[LeonarddeR]

Here is a branch that is very aggressive in ignoring input if the core is frozen. And there's a try build for that

[lukaszgo1]

With this try build nVDA still freezes when executing my test program, but I am able to kill it with CTRL+ALT+D, so switching users is no longer required. Thanks @LeonarddeR Any chance for fixing the freeze issue also?

[LeonarddeR]

A, so it definitely fixes a major part, that's great. I will investigate further.

[LeonarddeR]

Giving this a p2, since it tends to hang up the entire system.

[lukaszgo1]

@LeonarddeR I understand that properly fixing this would take a while, but would it be possible to include the fix from the try build above in master in the mean time?

[LeonarddeR]

I think that makes sense, yes.

[LeonarddeR]

Ugh, it wasn't my intention to have this automatically closed, as it isn't fixed entirely. Reopening.

[codeofdusk]

Latest master includes a rewrite of NVDA's console support using UI Automation (enable it in the advanced preferences). Running the test program by @lukaszgo1 seems to yield improved results. Do you consider this issue closed when UIA is used (i.e. should we close it once UIA becomes the default)?

[lukaszgo1]

@codeofdusk First of all thanks for your work it's really amazing even though I'm using Windows 10 only occasionally. I don't believe that closing of this issue, even when UIA become the default is appropriate for a number of reasons.

1. It isn't fixed for users of versions of Windows older than Windows 10 1809. There are unfortunately no statistics of NVDA usage per Windows version this would show how many are affected.
2. It is also worth noting that even if someone is using one of Windows versions on which UIA works well enough to replace the previous implementation it is sometimes necessary to enable legacy console in cmd properties and my understanding is that the UIA support isn't available in this case.
3. Most importantly however, commends from Freezing NVDA causes keyboard to stop responding #6463 seems to suggest that this problem could be reproduced in other ways and the str given here are simple the easiest.

[codeofdusk]

Once #9771 is merged, console performance will be improved in Windows 10 version 1803 thanks to the UIA console, and vastly improved in Windows 10 version 1809 and later due to new features added in UI Automation 6. However, these performance improvements will be unavailable to users on Windows server and LTSC 2016 (Windows 10 1607), which will remain supported for many years to come. Due to the nature of the legacy console support, performance improvements of this sort are difficult or impossible. Despite this, I vote to close this issue, as these improvements are available for the three most recently released versions of Windows. You are, of course, welcome to investigate further and propose a solution if you find one!

[francipvb]

Hello,

Run this in a CMD or a PowerShell session. Note that you need to have python 3 installed with the launcher.

    py -3 -c "for x in range(100000): print(x)"

Cheers,

[akalaiva]

Hello,
I find this same issue when a large content is inserted to a HTML text area.
Is this issue tracked else where? Or should that be fixed with this issue.

[dawidpieper]

Update for NVDA 2020.3 beta:

The problem is noticeably less common, but still appears. I think that it is related to many portions of text rather to one big piece.
I observe it most often when using ssh from a Windows commandline (cmd.exe) or WSL.

I tried to investigate the source of this issue, but did not find anything. Could someone outline the full path from new text loaded to terminal to NVDA reading it? Maybe I missed something.

It seems not to be related to UIA support enabled/disabled.

This issue definitely requires indeed testing.

CC @codeofdusk @jcsteh @lukaszgo1

[codeofdusk]

There is active work in this area, see #11639.