Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVDA 2019.3Beta1 crashes when setting synthesizer to eSpeak NG if path name contains accented character #10607

Closed
Qchristensen opened this issue Dec 11, 2019 · 19 comments · Fixed by #10860
Assignees
Milestone

Comments

@Qchristensen
Copy link
Member

@Qchristensen Qchristensen commented Dec 11, 2019

Steps to reproduce:

  1. Start NVDA 2019.3 beta 1.
  2. Create a portable copy.
  3. When asked where to create the portable copy, specify a folder name which includes a character such as é, ç, ş, ğ.
  4. Start the portable version.
  5. Open NVDA's synthesizer dialog (NVDA+control+g)
  6. Press HOME or use the arrow keys to select the "eSpeak NG" synthesizer.
  7. Press ENTER.

Actual behavior:

At the last step, NVDA immediately stops running (visually, the icon stays in the system tray until you mouse over it, that's simply an artifact of Windows not cleaning up properly - NVDA is not running by this point).

The very last entry in my NVDA log at Debug level is:

IO - inputCore.InputManager.executeGesture (13:03:39.817) - winInputHook (17464):
Input: kb(desktop):enter

(Registering the ENTER key being pressed to activate the OK button, set the synthesizer and close the synthesizer dialog.)

Expected behavior:

Synthesizer should switch to eSpeak NG and NVDA should continue working normally.

System configuration

NVDA installed/portable/running from source:

Portable, and setup in a folder which includes an accented character such as é, ç, ş, ğ

NVDA version:

2019.3 beta 1 (which uses eSpeak NG 1.51-dev, commit ca65812ac6019926f2fbd7f12c92d7edd3701e0c).

Windows version:

Windows 10 Version:
18362.388

Name and version of other software in use when reproducing the issue:

Other information about your system:

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

Yes, 2019.2.1 works fine in this situation.

Issue also filed with eSpeak NG as their issue 692: espeak-ng/espeak-ng#692

@josephsl
Copy link
Collaborator

@josephsl josephsl commented Dec 11, 2019

@Qchristensen
Copy link
Member Author

@Qchristensen Qchristensen commented Dec 11, 2019

Ok I tried Alpha 19128 from early November and it crashed the same way.

I tried the oldest alpha on the snapshots page currently 18581, from Sept 10 and it crashed.

So back to there at least it crashes, and it works back in 2019.2.1

@josephsl
Copy link
Collaborator

@josephsl josephsl commented Dec 11, 2019

@leonardder
Copy link
Collaborator

@leonardder leonardder commented Dec 13, 2019

I think this might have to do with us using the wrong encoding for the path.
Does NVDA generate a crash dump?

@Qchristensen
Copy link
Member Author

@Qchristensen Qchristensen commented Dec 15, 2019

No, no crash dump.

@michaelDCurran
Copy link
Member

@michaelDCurran michaelDCurran commented Dec 16, 2019

I can reproduce this bug in NVDA 2019.2.1 also.
I created a NVDA 2019.3beta1 in a 'tést' folder in my user profile, and NVDA 2019.2.1 in a 'tést2' folder in my user profile. Running both of them, if I switch to espeak NG, NVDA just silently exits.
@Qchristensen Are you sure your NVDA 2019.2.1 does not crash? Can you try within a 'tést2' directory?
There is a place in eSpeak's code (src/libspeak-ng/espeak_api.c, espeak_initialize) where if the directory cannot be located it literally exits the process. It is probably doing this, rather than actually crashing. Either way, it is still very bad.

@Qchristensen
Copy link
Member Author

@Qchristensen Qchristensen commented Dec 16, 2019

I initially created it in a 201921é folder off downloads, and I just tried creating a portable version in c:\tést2 using NVDA 2019.2.1 both times, and I can successfully change to eSpeak NG and use that.

Ok, in my log when it loads eSpeak it has:

INFO - synthDrivers.espeak.SynthDriver.init (22:30:17.551):
Using eSpeak NG version 1.49.1 dev
DEBUG - speechDictHandler.SpeechDict.load (22:30:17.595):
Loading speech dictionary '.\userConfig\speechDicts\voiceDicts.v1\espeak\espeak-English (Great Britain).dic'...
DEBUG - speechDictHandler.SpeechDict.load (22:30:17.595):
file '.\userConfig\speechDicts\voiceDicts.v1\espeak\espeak-English (Great Britain).dic' not found.
INFO - synthDriverHandler.setSynth (22:30:17.595):
Loaded synthDriver espeak
IO - speech.speak (22:30:17.798):
Speaking [LangChangeCommand ('en_GB'), u'C:\t\xe9st2 window']

I was about to say if it's using relative paths to find eSpeak it might not notice the base directory, but then the last line is looking in C:\t\xe9st2 rather than C:\tést2 - is it eSpeak / NVDA or Windows which is converting that name - everywhere I look at it I see C:\tést2

I'm still using Windows 10 Version 1903, build 18362.388 because mine refuses to updated to 1909 (for... reasons) Not sure if that makes a difference here?

@michaelDCurran
Copy link
Member

@michaelDCurran michaelDCurran commented Dec 16, 2019

@lukaszgo1
Copy link
Contributor

@lukaszgo1 lukaszgo1 commented Dec 16, 2019

For me on Polish Windows 7 x64 both NVDA 2019.2.1 and latest Alpha crashes if placed on a folder with accented characters in its name. The try build created by @michaelDCurran also crashes. What is suspicious however is the fact that @Qchristensen log states:

Using eSpeak NG version 1.49.1 dev

Whereas my log on NVDA 2019.2.1 contains":

Using eSpeak NG version 1.49.3 dev

@lukaszgo1
Copy link
Contributor

@lukaszgo1 lukaszgo1 commented Dec 16, 2019

On my machine NVDA 2019.1.1 is able to start with eSpeak when placed in a folder containing accented characters, whereas 2019.2 and above are not.

@michaelDCurran
Copy link
Member

@michaelDCurran michaelDCurran commented Dec 16, 2019

@Qchristensen
Copy link
Member Author

@Qchristensen Qchristensen commented Dec 17, 2019

Ah I wondered where the link was, I thought I was having a senior moment :)

Ok, setup a portable copy from your test build in c:\tést2 (I deleted the whole directory from my last test there).

NVDA still crashes. The log looks similar to previous:

IO - speech.speak (13:48:08.588) - MainThread (14020):
Speaking [LangChangeCommand ('en_US'), 'eSpeak NG']
DEBUG - synthDrivers.oneCore.SynthDriver._processQueue (13:48:08.596) - MainThread (14020):
Begin processing speech
IO - inputCore.InputManager.executeGesture (13:48:09.416) - winInputHook (11248):
Input: kb(desktop):enter
DEBUG - synthDrivers.oneCore.SynthDriver.cancel (13:48:09.419) - MainThread (14020):
Cancelling
DEBUG - synthDrivers.oneCore.SynthDriver._callback (13:48:09.422) - Dummy-3 (6284):
Done pushing audio
DEBUG - synthDrivers.oneCore.SynthDriver._processQueue (13:48:09.422) - Dummy-3 (6284):
Calling idle on audio player
DEBUG - synthDrivers.oneCore.SynthDriver._processQueue (13:48:09.423) - Dummy-3 (6284):
Queue empty, done processing
DEBUG - autoSettingsUtils.autoSettings.AutoSettings._saveSpecificSettings (13:48:09.423) - MainThread (14020):
Saved settings for SynthDriver

My system locale is also set to English (United States)

@michaelDCurran
Copy link
Member

@michaelDCurran michaelDCurran commented Dec 17, 2019

@Qchristensen
Copy link
Member Author

@Qchristensen Qchristensen commented Dec 17, 2019

Ok, so a bit embarrassing, but maybe some unintentional investigation:

I was, as @michaelDCurran suspected, not running 2019.2.1, somehow it was 2018.2.1, so that's a bit embarrassing... but as noted, it was definitely crashing, so maybe a regression after all?

Trying 2019.2.1 and it too crashes.

Trying 2019.1.1 as a portable version in folder c:\tést201911\ - and I can switch to eSpeak and it works just fine.

Sorry for the confusion!

@lukaszgo1
Copy link
Contributor

@lukaszgo1 lukaszgo1 commented Dec 17, 2019

I am afraid it is at least partially Python 3 regression after all.
Tested as follows:

  1. Created a directory called d:\ąśę\
  2. In it created portable copy of nvda_snapshot_alpha-18064,e579eb02 (This is the last Alpha powered by Python 2.)
  3. Tried to start it - as I am on Windows 7 eSpeak is the default - it starts correctly.
  4. Cleaned the directory, and created a portable copy of nvda_snapshot_alpha-18178,ba6b4f6b (that is first Alpha powered by Python 3).
  5. Tried to start it - it crashes during startup.

@feerrenrut feerrenrut added this to Needs triage in 2019.3 via automation Jan 28, 2020
@feerrenrut feerrenrut moved this from Needs triage to Won't fix for 2019.3 in 2019.3 Jan 29, 2020
@feerrenrut
Copy link
Member

@feerrenrut feerrenrut commented Jan 29, 2020

According to #10607 (comment) by @michaelDCurran this is likely caused by an error in espeak. Given that, and due to the imminent release of 2019.3, we only have two options:

  • Revert espeak to a prior version and test if that works. Though note that many users wanted espeak to be updated.
  • Accept that NVDA with espeak will crash when run under paths with accented characters.

Hopefully most users (who run from an installed copy) aren't affected by this, others who run from a portable copy should have control over the file path and unfortunately will have to avoid accented characters for now. We won't aim to fix this for 2019.3.

@zstanecic
Copy link
Contributor

@zstanecic zstanecic commented Jan 29, 2020

@feerrenrut feerrenrut added this to Needs Triage in 2020.1 via automation Mar 3, 2020
@feerrenrut feerrenrut moved this from Needs Triage to High priority in 2020.1 Mar 9, 2020
@michaelDCurran
Copy link
Member

@michaelDCurran michaelDCurran commented Mar 9, 2020

Investigating further, eSpeak actually has a flag to disable the exit call: espeakINITIALIZE_DONT_EXIT=0x8000 which can be passed to the options argument of espeak_initialize.
Doing this stops NVDA from exiting if espeak fails to initialize. this means that if the user is using another synth, and then tries to switch to espeak, they will get an error and NVDA will continue using the original synth. If eSpeak is configured to start with eSpeak (or is on Win 7 with no configuration) then it will try espeak which will fail, and then switch to silence. The user could then press control+NVDA+s and choose another synth if available.
I think for 2020.1 this is a suitable enough fix.

michaelDCurran added a commit that referenced this issue Mar 10, 2020
…rors such as the espeak path being invalid.
2020.1 automation moved this from High priority to Done Mar 11, 2020
michaelDCurran added a commit that referenced this issue Mar 11, 2020
…or (#10860)

* Fix for #10607: Ensure that espeak does not exit NVDA's process on errors such as the espeak path being invalid.

* Fix linting issues.

* Include the espeak data path in the exception message if eSpeak cannot be initialized.

* Fix linting issues.
@nvaccessAuto nvaccessAuto added this to the 2020.1 milestone Mar 11, 2020
@rhdunn
Copy link

@rhdunn rhdunn commented Jul 16, 2020

@zstanecic There were several issues (crashes) after introducing emoji support due to the complexity of the espeak internals and making any changes/improvements to the codebase. Those have been fixed, and a test suite has been added to detect issues like this and regressions in the voices going forward.

I don't believe the latest espeak builds any more due to it being out of sync with wxWidgets, which is required by that version to build the voices. -- I put a lot of effort into making the voices build as part of the project without needing to use/run espeakedit, in addition to cleaning up the original codebase.

I'm both a Windows and Linux user. I created the modern Visual Studio project and WiX-based installer for espeak-ng so it did not need to be build with Visual Studio 6! If you are referring to the lack of a SAPI voice, the espeak project included the sapi files as part of the project (which are both older and have potential licensing/distribution issues), and required the ATL sources. I implemented an experimental version, but I haven't had the time to address the issues -- audio clipping at the end, and voice selection.

The language issue is a challenge, as we have requests for new languages, but don't have native speakers that are willing to work on them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
2019.3
Won't fix for 2019.3
2020.1
  
Done
Development

Successfully merging a pull request may close this issue.

9 participants