Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Freeze when navigating by landmarks with certain labeled article landmarks #8980
Steps to reproduce:
There are several prerequisites:
NVDA produces an error sound, then falls silent. As if it partially crashed. Braille continues to blink, but won't respond to anything.
NVDA Installed/portable/running from source:
NVDA version alpha-16298,c651588e
Windows 10 19H1 18282 build. But also happens on 1809 regular.
Name and version of other software in use when reproducing the issue:
Firefox Nightly 65.
Other information about your system:
Does the issue still occur after restarting your PC?
Have you tried any other versions of NVDA?
2018.4beta, 2018.3.2, happens with both, too.
Developer info for an article element that causes this problem:
INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (15:28:21.299):
End of nvda.log from pressing D before such a crash onwards
DEBUGWARNING - brailleDisplayDrivers.handyTech.BrailleDisplayDriver._handleInputStream (15:24:10.657):
DEBUGWARNING - brailleDisplayDrivers.handyTech.BrailleDisplayDriver._handleInputStream (15:24:35.359):
The pull request that will introduce these new names for the article elements into Pinafore is here.
I investigated the Python side of things, and it appears that the call to VBuf_findNodeByAttributes referenced at the bottom of the stack somehow causes a crash or hang in the VBufBackend, or rather VBufStorage. @jcsteh and @michaelDCurran are probably quicker at investigating this than I, since I'm on PTO even. :) Just found this yesterday while trying out the new Pinafore features.
So far I have confirmed that regex_match is throwing regex_error with a code of error_stack. Apparently there is insufficient memory to check if the expression matches for some of the article names. At very least we can catch the c++ exception and keep searching. But it does mean next/prev landmark may skip certain articles. It would be good to work out what is special about these particular strings. It is certainly not the majority of them.
To try to simplify the repro steps, I've created a static version of the page that reproduces the crash. So it should no longer be required to have a Mastodon account; you can just load this page: http://bl.ocks.org/nolanlawson/raw/07e732b654842a2fe62760c4bda179ee/
As in the original description, you should install the Enhanced Aria plugin and ensure that "Report articles" is enabled in the plugin settings. Then you can press D on the page and eventually you will repro the crash.
I have tried increasing the stack size of all rpc server threads created for NvDAHelper. However, no matter how large I made the stack the problem remains.
Although I can't reproduce this yet in the Twitter example, back on the original testcase: The freeze occurs in Mozilla Firefox 64 and 67, but not Google Chrome 72 and 74. I have verified that where the c++ regexp match freezes, both the regular expression string and the input were identical in allBrowsers. I will try and simplify the testcase down to a page with only that one article that I know causes the freeze.
match_regexp freezes if the input is 295 characters or longer. It doesn't matter what the characters are. I was able to reproduce it with an article with an aria-label made up of 295 'x' characters. I will investigate Jamie's idea about allocating the regexp object differently.
@jcsteh I logged both the regular expression, and the input string, where the regex match freezes. I doubt this is the cause, but I am finding it hard to read. Should name appear twice? and should IAccessible2::attribute_xml-roles appear twice for both region, and the other group of landmarks (search,main etc)?
Here is the regular expression:
And here is the input string: