Infrequent crash in Firefox #11169
Comments
|
Looks like NVDA froze trying to play audio. That's pretty weird and
suggestive of a bug in nvwave (NVDA's audio output code) or your systems'
audio driver. Given that I've never seen this, I'm inclined to guess it's
an audio driver bug, but I guess we'll see if others are encountering this
same freeze.
|
|
The freeze that I still see about once a week is the one that we discussed before where NVDA would appear to hang (taking away the ability to properly control the computer via keyboard) until Firefox is entirely closed before it goes back to normal. |
|
same problem. |
That's the "RPC hang" marco referred to here: @gregjozk, I suspect you're seeing the RPC hang as well, rather than this audio issue... unless you're seeing the nvwave freeze in your log file as well. |
|
yes, you are correct. in the log, there is also rpc.
as I said earlier, I will send log to you on debug warnings level.
hope, it would help to investigate.
2020-05-18 3:20 GMT+02.00, James Teh <notifications@github.com>:
…> The freeze that I still see about once a week is the one that we discussed
> before where NVDA would appear to hang (taking away the ability to
> properly control the computer via keyboard) until Firefox is entirely
> closed before it goes back to normal.
That's the "RPC hang" marco referred to here:
You can track and discuss that here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1572915
@gregjozk, I suspect you're seeing the RPC hang as well, rather than this
audio issue... unless you're seeing the nvwave freeze in your log file as
well.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#11169 (comment)
|
|
@MarcoZehe did you by chance sleep and unsleep your machine shortly before reproducing this issue? |
|
No, I had it running for at least 1 hour or so. |
|
When Firefox stops responding, NVDA always goes silent. I need to take sighted help to close Firefox or click the NVDA Desktop icon and after a few minutes of waiting and doing that and pressing Ctrl+Alt+N, I get everything back to normal. Is that the same as the crash being referred to in this ticket? Also, on an unrelated note, the Crash Hero add-on served me well in the past in gathering crash logs. It is unfortunate that it has not been updated to be Python 3 compatible. |
|
Two things:
When Firefox stops responding, NVDA always goes silent. I need to take sighted help to close Firefox or click the NVDA Desktop icon and after a few minutes
For such circumstances, I have a shortcut on one of my desktops.
It is set to run minimized, and with shortcut key control+alt+k.
The executable is:
c:\Windows\System32\taskkill.exe /f /im firefox.exe /t
Kills it every time.
an unrelated note, the Crash Hero add-on served me well in the past in gathering crash logs. It is unfortunate that it has not been updated to be Python 3
compatible.
I would have to look into this, but I seem to remember working with
@derekriemer to get it Py3 functional. Maybe it's only in the dev branch?
Or maybe I'm misremembering?
|
|
I saw this myself today. After some discussion with Mick, it occurred to me that this might be a Python gc COM release deadlock due to nvwave's use of locks. If that's the case, it's worth testing with the latest alpha of NVDA for two reasons:
(Unfortunately, I was running an old build when I hit this, so I don't have that log info.) |
|
This issue still occurs for me and has the same crippling effect in terms of locking up NVDA and needing me to somehow close Firefox. Do others still experience this; if yes, how frequently and to what severity? Have there, by any chance, been any updates in NVDA or Firefox to address these crashes? Is there any additional information from the log or otherwise that may aid developers in understanding this issue? I would love to see discussion on this ticket resume. |
|
Still happening for me from time to time. Frequency between once a day and once a week. |
|
First, you should differentiate between this complete hang of NVDA vs the RPC hang discussed above (where CPU usage goes up quite high as well). Second, assuming this isn't the RPC hang, as I wrote in my last comment #11169 (comment), if someone is still experiencing this, it'd be useful if they could provide a log. Since this issue was first reported, NVDA now logs more info that might be useful in diagnosing this. |
|
@jcsteh Thanks for your response. Could you please clarify whose CPU usage we should be looking at - NVDA, Firefox, or the entire system's? |
|
@jcsteh Also, which level would you like log output at? I just replicated this and extracted the relevant portion of the log, but realized that the log level was Input/Output which may be inadequate. |
|
to me is also still relevant. it happens approximately 2 times a week.
I'll try to provide log again.
should I also check some log options in Advanced settings of NVDA?
thanks.
2021-09-26 18:32 GMT+02.00, bhavyashah ***@***.***>:
… @jcsteh Also, which level would you like log output at? I just replicated
this and extracted the relevant portion of the log, but realized that the
log level was Input/Output which may be inadequate.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#11169 (comment)
|
I'd look at the entire system. The problematic process is actually a Windows RPC service running in side vchost.exe, but it can be tricky to pinpoint the exact service, so I think it's just easier to look for high CPU usage across the whole system.
If NVDA freezes completely (which is the issue being discussed in this particular report), watchdog should log stack information after 15 seconds, which is what I'm interested in. That gets logged at level error. So, input/output should be fine, but you can go as high as info and you'll still get errors. |
|
Apologies for returning to this after so long. I am trying to either
get to the directory c:\Windows\System32\taskkill.exe /f /im
firefox.exe /t or create a shortcut that uses it as its target
location, and am unable to do either. Inputting this directory in the
Run dialog does work and close Firefox. However, from Windows
Explorer, the farthest I get to is taskkill.exe. Since it is not a
folder, clicking it opens up something which closes immediately, not
revealing any further files. Placing this directory in the Target
Location field while creating a shortcut gives me a directory does not
exist error. Could you please clarify how to navigate these
difficulties?
…On 9/26/21, James Teh ***@***.***> wrote:
> Could you please clarify whose CPU usage we should be looking at - NVDA,
> Firefox, or the entire system's?
I'd look at the entire system. The problematic process is actually a Windows
RPC service running in side vchost.exe, but it can be tricky to pinpoint the
exact service, so I think it's just easier to look for high CPU usage across
the whole system.
> Also, which level would you like log output at?
If NVDA freezes completely (which is the issue being discussed in this
particular report), watchdog should log stack information after 15 seconds,
which is what I'm interested in. That gets logged at level error. So,
input/output should be fine, but you can go as high as info and you'll still
get errors.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#11169 (comment)
--
Best Regards,
Bhavya Shah
Stanford University | Class of 2024
LinkedIn: https://www.linkedin.com/in/bhavyashah125/
|
|
Create the shortcut to taskkill.exe, then edit it (properties) to add the
command line arguments.
|
|
I've been seeing this once every few days since I got a new machine with Windows 11. I see the freezes when trying to close the wave output from the old fileWavePlayer instance. There is no deadlock here; it happens when calling WaveOutClose. The original log in this issue is a bit different; it froze trying to acquire a lock, but I don't have the stacks from the other threads, so I don't know why it couldn't acquire the lock. It occurs to me that we perhaps shouldn't keep the fileWavePlayer open after we're done playing. We create a new one whenever we play a file anyway, so we don't benefit at all from keeping the device open. However, it can be quite some time between playing sounds, which means we might have an open WaveOut handle hanging around for quite some time. While that shouldn't matter in theory, I do wonder whether Windows doesn't handle this properly if that handle gets closed a lot later, particularly when there are intervening device switches. Changing that should be as simple as setting closeWhenIdle to True when fileWavePlayer is constructed. |
NVDA's existing audio output code (nvwave) is largely very old and uses WinMM, a very old legacy Windows audio API. It is also written in pure Python, contains quite a few threading locks necessitated by WinMM, and parts of it have become rather difficult to reason about. There are several known stability and audio glitching issues that are difficult to solve with the existing code. Description of user facing changes At the very least, this fixes audio glitches at the end of some utterances as described in #10185 and #11061. I haven't noticed a significant improvement in responsiveness on my system, but my system is also very powerful. It's hard to know whether the stability issues (e.g. #11169) are fixed or not. Time will tell as I run with this more. Description of development approach 1. The bulk of the WASAPI implementation is written in C++. The WASAPI interfaces are easy to access in C++ and difficult to access in Python. In addition, this allows for the best possible performance, given that we regularly and continually stream audio data. 2. The WinMM code fired callbacks by waiting for the previous chunk to finish playing before sending the next chunk, which could result in buffer underruns (glitches) if callbacks were close together (Python 3 versions of NVDA produce a scratch in the speech when finishing the end of a line #10185 and Texts with multiple line spacings are voiced with NVDA + down arrow and voices crack #11061). In contrast, the WASAPI code uses the audio playback clock to fire callbacks independent of data buffering, eliminating glitches caused by callbacks. 3. The WinMM WavePlayer class is renamed to WinmmWavePlayer. The WASAPI version is called WasapiWavePlayer. Rather than having a common base class, this relies on duck-typing. I figured it didn't make sense to have a base class given that WasapiWavePlayer will likely replace WinmmWavePlayer altogether at some point. 4. WavePlayer is set to one of these two classes during initialisation based on a new advanced configuration setting. WASAPI defaults to disabled. 5. WasapiWavePlayer.feed can take a ctypes pointer and size instead of a Python bytes object. This avoids the overhead of additional memory copying and Python objects in cases where we are given a direct pointer to memory anyway, which is true for most (if not all) speech synthesisers. 6. For compatibility, WinmmWavePlayer.feed supports a ctypes pointer as well, but it just converts it to a Python bytes object. 7. eSpeak and oneCore have been updated to pass a ctypes pointer to WavePlayer.feed. 8. When playWaveFile is used asynchronously, it now feeds audio on the background thread, rather than calling feed on the current thread. This is necessary because the WASAPI code blocks once the buffer (400 ms) is full, rather than having variable sized buffers. Even with the WinMM code, playWaveFile code could block for a short time (nvwave.playWaveFile not fully async #10413). This should improve that also. 9. WasapiWavePlayer supports associating a stream with a specific audio session, which allows that session to be separately configurable in the system Volume Mixer. NVDA tones and wave files have been split into a separate "NVDA sounds" session. WinmmWavePlayer has a new setSessionVolume method that can be used to set the volume of a session. This at least partially addresses Ability to adjust volume of sounds #1409.
|
@jcsteh how to proceed with this issue now that the Pull request referenced above is merged? I cannot reproduce any crash in Firefox, especially also now that cache is enabled. |
|
I haven't seen this lately either. Let's close it and reopen if the problem reappears. |
Steps to reproduce:
There are no steps to reproduce. Sometimes, when working in Firefox, NVDA just falls silent, and braille stops outputting something. This is different from the RPC hang @jcsteh and I have been chasing for two years now. This is just NVDA suddenly going away. So there are no exact steps. But this is in the old log.
Actual behavior:
Crash.
Expected behavior:
No crash.
System configuration
NVDA installed/portable/running from source:
Installed.
NVDA version:
version alpha-20206,dba33431
Windows version:
10 19H2.
Name and version of other software in use when reproducing the issue:
Firefox Nightly 78, or Beta 77.
Other information about your system:
Focus Braille Display 5th generation connected.
Other questions
Does the issue still occur after restarting your computer?
Yes.
Have you tried any other versions of NVDA? If so, please report their behaviors.
2020.1, same result after some time.
If addons are disabled, is your problem still occuring?
Yes.
Did you try to run the COM registry fixing tool in NVDA menu / tools?
Yes, but since all is working normally until the crash, nothing changed.
Info for @jcsteh , this also happened before the very last COM fix you put into Nightly this week. So it is not a side effect of that. The log suggests rather that something makes NVDA freeze.
The text was updated successfully, but these errors were encountered: