search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.1k stars 634 forks source link

Braille display auto-detection feature causes errors on loading large braille tables on NVDA startup #9982

Closed DrSooom closed 4 years ago

DrSooom commented 5 years ago

First of all I'm so glad that these errors aren't caused by my HUC Braille Tables alone, because other large braille tables like "zh-tw.ctb" lead to the same results I described in issue #9973 yesterday. CC: @leonardder

Steps to reproduce:

  1. Install/Create a portable copy of NVDA 2019.2 Beta-18176.
  2. Now start NVDA Portable and change the braille output table to Chinese Taiwan/Mandarin ("zh-tw.ctb") and disable the checkbox "Expand to computer braille for the word at the cursor".
  3. Restart NVDA with debug logging level via NVDA+Q.

    Actual behavior:

    This time I was able to reproduce both errors I mentioned in issue #9973 on a SSD, but I couldn't figure out if the Chinese braille table "zh-tw.ctb" (of course without the HUC Braille Tables) was completely loaded or not. Maybe you have to restart NVDA multiple times to get these errors.

Here is the first logfile with no error sound on startup. And here is the second one with an error sound and no braille output directly after startup. Always start at line 126. And please take a look at the timestamps in the second logfile, because there aren't any log entries from the beginning of the error sound until the Protocol Viewer was opened. That's so strange, therefore I repeated restarting NVDA in Debug Mode multiple times, because I thought I did something wrong. Normally NVDA should also have logged pressing ArrowRight and ArrowLeft in the Windows Explorer (Detail View) as well as the steps to open the Protocol Viewer via the NVDA menu. But that was never the case.

Expected behavior:

No errors on loading large braille tables.

LeonarddeR commented 5 years ago

@DrSooom Could you please test with this try build

If this build doesn't have the issue for you, I will make #10275 close this issue.

DrSooom commented 5 years ago

Here is the Stand-PC (win7x64, 6 GB RAM, SSD) logfile for NVDA 2019.2.1 Try-18768 Portable and here the used "nvda.ini" file (please delete the txt file extension).

And here is the logfile from my NUC (also win7x64, 8 GB RAM, SSD). The line 162 says that the include opcode isn't defined, which is really odd.

dpy013 commented 5 years ago

Here is the Stand-PC (win7x64, 6 GB RAM, SSD) logfile for NVDA 2019.2.1 Try-18768 Portable and here the used "nvda.ini" file (please delete the txt file extension).

  • Line 94 to 98: ALVA driver permission error; not new. See the section "Additional information regarding the Optelec ALVA BC680" in issue #9973. This issue also occurs on my NUC, where NVDA 2015.3 is installed without any additional braille drivers in the "brailleDisplayDrivers" folder in the NVDA configuration folder.
  • Line 167 to 178: "noback" and "context" opcode errors.
  • Line 179 to 189: No changes here in compare to NVDA 2019.2.1 Try-RC1-18694.
  • Line 197 to 200: Nice info. It explains why there isn't a braille output directly after NVDA started – the braille tables couldn't be compiled.
  • Line 201 to 213: The kind how the Unicode characters are logged for this runtime error is different to my previous logfiles.
  • Line 222 to 237: Braille tables are loaded again, but maybe just parts of them.

And here is the logfile from my NUC (also win7x64, 8 GB RAM, SSD). The line 162 says that the include opcode isn't defined, which is really odd.

hi DrSooom Can you use windows10 to do the above tests?

DrSooom commented 5 years ago

Sadly no, because there isn't any physical machine running Windows 10 yet. And I haven't set up a VM for it too.

zstanecic commented 5 years ago

Sadly, i cannot reproduce this.

Win 10 1903

From: Daniel Mayr notifications@github.com Sent: Wednesday, September 25, 2019 1:49 PM To: nvaccess/nvda nvda@noreply.github.com Cc: zstanecic zvonimirek222@yandex.com; Mention mention@noreply.github.com Subject: Re: [nvaccess/nvda] Errors on loading large (Chinese) braille tables with NVDA 2019.2 Beta-18176, 2019.2 Beta-18345 and 2019.2 RC2 (#9982)

Sadly no, because there isn't any physical machine running Windows 10 yet. And I haven't set up a VM for it too.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/9982?email_source=notifications&email_token=ACVCDEZTEWX2F7P2QXEQHPDQLNFZPA5CNFSM4IHHDP22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7RTKPI#issuecomment-534983997 , or mute the thread https://github.com/notifications/unsubscribe-auth/ACVCDE6JDBL227KGIEHNJV3QLNFZPANCNFSM4IHHDP2Q . https://github.com/notifications/beacon/ACVCDE2THS7V2JUELWAIDUDQLNFZPA5CNFSM4IHHDP22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7RTKPI.gif

LeonarddeR commented 5 years ago

@DrSooom: Are you saying that you have the Chinese table loading error on this build? That would be a regression from current alpha snapshots, right?

Note, NVDA Try-18768 is a version in the 2019.3 range, not based on 2019.2.1. For ease of understanding, it would be best to refer to the name of the try build (i.e. try-liblouis3.11withClangOnVS2019 in this case).

lukaszgo1 commented 5 years ago

@DrSooom in #8106 you've mentioned that you have Baum braille display. Would you be able to test with it? Given the fact that no one except you is able to reproduce it is must be something specific to your two pc's.

DrSooom commented 5 years ago

Are you saying that you have the Chinese table loading error on this build? That would be a regression from current alpha snapshots, right?

I never tested Py3-Alpha builds. But others said that "zh-tw.ctb" loaded correctly. I'm not sure if everybody immediately looked into the Log Viewer after starting NVDA. During a quick test, it seems that this braille table is loaded correctly with NVDA 2019.2.1 Beta 1 again. But this doesn't say anything. As the HUC Braille Tables still raise that error, I just think that the total file size level has changed again.

@lukaszgo1: Yes, I own a BAUM SuperVario2 64, which got broken by an Austrian braille dealer during cleaning. More details about the still open case can be read on my website. Personally I don't intent to touch it until this case is finally closed. I had a huge luck to find a second-hand Optelec ALVA BC680 via a C2C purchase, as there is only one company in whole Austria, which sells, repairs and cleans braille displays. But repairing this specific braille display is no longer possible because "the tree" (BAUM Retec AG, manufacture) has died in October 2017. And KSG does no longer sell SC9 braille modules. Sadly there is more broken on that BAUM braille device than only 40 of 64 braille modules due to that cleaning process by the Austrian company.

zstanecic commented 5 years ago

Hi,

I am currently running latest alpha *py3 with taiwanese Braille table

And i don’t see the problem

From: Daniel Mayr notifications@github.com Sent: Wednesday, September 25, 2019 4:50 PM To: nvaccess/nvda nvda@noreply.github.com Cc: zstanecic zvonimirek222@yandex.com; Mention mention@noreply.github.com Subject: Re: [nvaccess/nvda] Errors on loading large (Chinese) braille tables with NVDA 2019.2 Beta-18176, 2019.2 Beta-18345 and 2019.2 RC2 (#9982)

Are you saying that you have the Chinese table loading error on this build? That would be a regression from current alpha snapshots, right?

I never tested Py3-Alpha builds. But others said that "zh-tw.ctb" loaded correctly. I'm not sure if everybody immediately looked into the Log Viewer after starting NVDA. During a quick test, it seems that this braille table is loaded correctly with NVDA 2019.2.1 Beta 1 again. But this doesn't say anything. As the HUC Braille Tables still raise that error, I just think that the total file size level has changed again.

@lukaszgo1 https://github.com/lukaszgo1 : Yes, I own a BAUM SuperVario2 64, which got broken by an Austrian braille dealer during cleaning. More details about the still open case can be read on my website. Personally I don't intent to touch it until this case is finally closed. I had a huge luck to find a second-hand Optelec ALVA BC680 via a C2C purchase, as there is only one company in whole Austria, which sells, repairs and cleans braille displays. But repairing this specific braille display is no longer possible because "the tree" (BAUM Retec AG, manufacture) has died in October 2017. And KSG does no longer sell SC9 braille modules. Sadly there is more broken on that BAUM braille device than only 40 of 64 braille modules due to that cleaning process by the Austrian company.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/9982?email_source=notifications&email_token=ACVCDEZ4M6FK2KS73CWJUU3QLN3CBA5CNFSM4IHHDP22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7SF5MI#issuecomment-535060145 , or mute the thread https://github.com/notifications/unsubscribe-auth/ACVCDE5LMET6WEHXQ75CIADQLN3CBANCNFSM4IHHDP2Q . https://github.com/notifications/beacon/ACVCDE7J453IZKQHCP762G3QLN3CBA5CNFSM4IHHDP22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7SF5MI.gif

zstanecic commented 5 years ago

Note: using esis 24 braille display

From: Daniel Mayr notifications@github.com Sent: Wednesday, September 25, 2019 4:50 PM To: nvaccess/nvda nvda@noreply.github.com Cc: zstanecic zvonimirek222@yandex.com; Mention mention@noreply.github.com Subject: Re: [nvaccess/nvda] Errors on loading large (Chinese) braille tables with NVDA 2019.2 Beta-18176, 2019.2 Beta-18345 and 2019.2 RC2 (#9982)

Are you saying that you have the Chinese table loading error on this build? That would be a regression from current alpha snapshots, right?

I never tested Py3-Alpha builds. But others said that "zh-tw.ctb" loaded correctly. I'm not sure if everybody immediately looked into the Log Viewer after starting NVDA. During a quick test, it seems that this braille table is loaded correctly with NVDA 2019.2.1 Beta 1 again. But this doesn't say anything. As the HUC Braille Tables still raise that error, I just think that the total file size level has changed again.

@lukaszgo1 https://github.com/lukaszgo1 : Yes, I own a BAUM SuperVario2 64, which got broken by an Austrian braille dealer during cleaning. More details about the still open case can be read on my website. Personally I don't intent to touch it until this case is finally closed. I had a huge luck to find a second-hand Optelec ALVA BC680 via a C2C purchase, as there is only one company in whole Austria, which sells, repairs and cleans braille displays. But repairing this specific braille display is no longer possible because "the tree" (BAUM Retec AG, manufacture) has died in October 2017. And KSG does no longer sell SC9 braille modules. Sadly there is more broken on that BAUM braille device than only 40 of 64 braille modules due to that cleaning process by the Austrian company.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/9982?email_source=notifications&email_token=ACVCDEZ4M6FK2KS73CWJUU3QLN3CBA5CNFSM4IHHDP22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7SF5MI#issuecomment-535060145 , or mute the thread https://github.com/notifications/unsubscribe-auth/ACVCDE5LMET6WEHXQ75CIADQLN3CBANCNFSM4IHHDP2Q . https://github.com/notifications/beacon/ACVCDE7J453IZKQHCP762G3QLN3CBA5CNFSM4IHHDP22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7SF5MI.gif

DrSooom commented 5 years ago

File name: usb-cert-baum.zip (removed on 2019-10-26) File size: 1.54 MB (1,615,480 Bytes) SHA-256: 281947b58571f5d371a15415ae6a5afbbc002bf029adfa4fb5b9f6f38cc93e5b

I've temporarily uploaded the BAUM braille display driver (version V7 02/17/2009 2.04.16) onto my webserver, which was released in January 2010 (based on the date of the Installer). Perhaps this driver influences the NVDA-own ALVA driver and/or the braille display auto-detection feature in NVDA. This driver package is installed on both machines – Stand-PC and NUC. But as I wrote before: the broken BAUM SuperVario2 64 isn't connected to these machines.

@zstanecic: Which OS?

zstanecic commented 5 years ago

Win 10

From: Daniel Mayr notifications@github.com Sent: Wednesday, September 25, 2019 7:31 PM To: nvaccess/nvda nvda@noreply.github.com Cc: zstanecic zvonimirek222@yandex.com; Mention mention@noreply.github.com Subject: Re: [nvaccess/nvda] Errors on loading large (Chinese) braille tables with NVDA 2019.2 Beta-18176, 2019.2 Beta-18345 and 2019.2 RC2 (#9982)

File name: usb-cert-baum.zip https://danielmayr.at/files/temp/usb-cert-baum.zip File size: 1.54 MB (1,615,480 Bytes) SHA-256: 281947b58571f5d371a15415ae6a5afbbc002bf029adfa4fb5b9f6f38cc93e5b

I've temporarily uploaded the BAUM braille display driver (version V7 02/17/2009 2.04.16) onto my webserver, which was released in January 2010 (based on the date of the Installer). Perhaps this driver influences the NVDA-own ALVA driver and/or the braille display auto-detection feature in NVDA. This driver package is installed on both machines – Stand-PC and NUC. But as I wrote before: the broken BAUM SuperVario2 64 isn't connected to these machines.

@zstanecic https://github.com/zstanecic : Which OS?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/9982?email_source=notifications&email_token=ACVCDE2GUOMXC6FU2JU4WDDQLON63A5CNFSM4IHHDP22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7SWUMA#issuecomment-535128624 , or mute the thread https://github.com/notifications/unsubscribe-auth/ACVCDE6J754ZU7XBYZUEYMDQLON63ANCNFSM4IHHDP2Q . https://github.com/notifications/beacon/ACVCDE2ACH5KYZS5DY6TIX3QLON63A5CNFSM4IHHDP22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7SWUMA.gif

lukaszgo1 commented 5 years ago

@DrSooom Two more things:

  1. Could you please compress, and upload somewhere the entire folder in which portable NVDA is placed?
  2. I have a feeling that presence of older NVDA versions on your pcs might have something to do with this problem. Could you disable autostarting of whatever version is installed, reboot your machine, start the portable build either blindly or with Narrator without running installed NVDA and try to reproduce this?
DrSooom commented 5 years ago
  1. 9982_NVDA_2019.3 Try-18768.7z (22.0 MB, temp. available, removed on 2019-10-26)
  2. Do you also mean the logon screen? Or shall I set up a new Win7 VM, which I could do in the upcoming days?
lukaszgo1 commented 5 years ago

I would start with disabling from both autostart, and logon screen, and if it still would be reproducible then go to the more time consuming process of creating a VM.

school510587 commented 5 years ago

Hi all,

I'm a zh_TW user with Windows version 6.1.7601 service pack 1 (64-bit). I have tested both 2019.2 and alpha-18759,6cb40529 NVDA versions, and no problem occurred during zh_TW loading.

Also, I am the current maintainer of zh-tw.ctb, but no other Taiwanese user reported similar bug to me. I thus don't know existence of this issue.

DrSooom commented 5 years ago

EUREKA! I got it!

Now I know why nobody without an Optelec ALVA BC680 was able to reproduce this issue. No, it isn't caused by any braille tables – also not by my HUC Braille Tables. And I guess that it isn't caused by Liblouis too.

The kind how NVDA is started on the logon screen has changed between NVDA 2015.3 and 2015.4. And the ALVA driver has changed between NVDA 2017.4 and 2018.1. On my Stand-PC NVDA 2018.1 is installed and on my NUC 2015.3. But the symptoms are/were exactly the same on both machines with NVDA Try-18768 (Py3, will get to 2019.3).

And now: The braille display auto-detection feature was added to NVDA 2018.3 and didn't exist before. And exactly this feature in combination with a connected Optelec ALVA BC680 via USB1 or USB2 (this braille display has two USB ports) is responsible for the loading errors of Liblouis braille tables – and nothing else.

I tested the largest Liblouis braille table "zh-tw.ctb" and the HUC8 and the HUC6 Braille Tables (included into "de-de-comp8.ctb" and "de-g1.ctb" and stand-alone) multiple times with NVDA 2019.2.1 Beta 1 Portable (Liblouis 3.10.0) and NVDA Try-18768 Portable (Liblouis 3.11.0) on my Stand-PC. I also successfully tested the UTF32 files of the HUC Braille Tables with NVDA Try-18768. Okay, the more braille tables are included, the longer NVDA requires to start. If only "huc8-u+0000-u+ffff.tbi" and "huc8-u+10000-u+1ffff.tbi" are included, no lag on startup is recognizable. After including "huc8-u+20000-u+2ffff.tbi" as well, NVDA requires around four seconds to be fully started. Well, and the more braille tables are included, the longer it takes. But this isn't really relevant yet, because there are just 337 allocated Unicode characters in the Unicode planes 3 to 16 in the Unicode Standard 12.1 (may 2019).

In all testing scenarios I was immediately able to force this issue after I switched back from "Optelec ALVA 6-Serien/Protokoll-Konverter" ("display = alva") to "Automatisch (Optelec ALVA 6-Serien/Protokoll-Konverter)" ("display = auto" in the "nvda.ini") in the Braille NVDA Settings. If the braille display was chosen directly from the list of braille displays, these loading errors don't occur – on a SSD. Therefore I changed the issue title. If wanted, I also can test this by running NVDA Portable from an USB 3.0 flash drive as well as on my NUC (SSD).

@leonardder: Please let me know if you need a logfile with enabled HWIO logging for fixing the braille display auto-detection feature.

LeonarddeR commented 5 years ago

This is a very interesting finding. In fact, I don't see how this could be related to what display you're using. It is more likely that this is related to how multi threading works and how NVDA communicates wit liblouis. Aauto detection moved more logic to the background thread, possibly causing issues with synchronisation or multiple threads throwing requests at liblouis at the same time.

It would actually be very helpful to have some logs of most recent ALPHA, on which the log entries specify the thread that initiated the log call. We might be able to see on what thread the exceptions were caused.

DrSooom commented 5 years ago

Here are five logfiles. "p13" is from Try-18768 and the other four from Alpha-18783. The very last line in "p13" is extremely strange, as there aren't any absolute paths in the HUC Braille Tables. As this loaded process took too much time, I launched NVDA 2018.1 via the desktop shortcut – if I memorize correctly. (There were too many tests in the last 4.5 hours. 😉)

LeonarddeR commented 5 years ago

Yes, pretty sure it is as described in https://github.com/nvaccess/nvda/issues/9982#issuecomment-535516227

I will look into the code and will provide a try build shortly.

LeonarddeR commented 5 years ago

I'm pretty sure try build try-initialDisplayFix will fix the issues you're having.

DrSooom commented 5 years ago

Here are ten new logfiles. I'm confused. I'm not sure if this issue is really completely solved by Try-18797, but the braille tables seems to be fully loaded on NVDA startup – excluding the "p19" log, which I couldn't reproduce again during testing. Thus "p19" only occurred once. I tested all the same braille tables, which I tested yesterday on, a SSD again. Tests on a USB 3.0 flash drive are still pending.

DrSooom commented 5 years ago

@leonardder: Shall I test Try-18797 right now on a USB flash drive too or are you going to provide a new Try-build?

LeonarddeR commented 5 years ago

@leonardder: Shall I test Try-18797 right now on a USB flash drive too or are you going to provide a new Try-build?

Yes, please. I don't have any starting points to change anything in the current try build.

DrSooom commented 5 years ago

Done. NVDA Try-18797 Portable works exactly the same on a USB 3.0 flash drive (connected via a USB 3.0 and a 2.0 port) like on an internal SSD.

NVDA 2019.2.1 still has this issue if the HUC Braille Tables are used. But it seems that "zh-tw.ctb" is completely loaded on startup again – I got no errors in the logfiles when using the auto-detection feature. Otherwise: Not using the braille display auto-detection feature also solves the loading error with the HUC braille Tables, as I already mentioned last Thursday. Thus this finding is also valid for NVDA 2019.2.1.

DrSooom commented 4 years ago

@leonardder: Are you planning to add your fix to NVDA 2019.3?

LeonarddeR commented 4 years ago

I'm happy to do this, if you consider this issue to be fixed after merging try-initialDisplayFix.

DrSooom commented 4 years ago

@leonardder: Please read this comment and this comment.

LeonarddeR commented 4 years ago

Could you please summarize your relevant findings in around one or two sentences? This would be very helpful when filing the pr. I understand that you're pointing at several comments in order to be as complete as possible, but it makes it very difficult for a potential reviewer to filter out what's relevant. It should be possible for a reviewer to see at one glance what this will fix.

DrSooom commented 4 years ago

Summary of the issue:

If the braille display auto-detection feature is enabled and large braille table(s) (> 1 MB) are loaded on NVDA startup, the braille table(s) couldn't be completely loaded respectively compiled. Sometimes also the include opcode no longer operates and the braille output keeps blank after NVDA startup unless the braille output was updated (e.g. by opening the NVDA menu). Or only parts of the braille tables are loaded. A "Can't translate" runtime error was logged on startup. This issue was confirmed by @DrSooom with an Optelec ALVA BC680 (connected via both USB ports) on Windows 7 64-Bit. Based on @leonardder comment in issue #9982 this issue might not be limited to the Optelec ALVA BC680, but plenty other users weren't able to reproduce this issue using other braille displays.

Hmm… I guess this is still a little bit too long. Nevertheless it should help you – hopefully.

LeonarddeR commented 4 years ago

Great, thank you!