Open Bug 1691928 Opened 8 months ago Updated 28 days ago

Crash in [@ VBufStorage_buffer_t::clearBuffer] (with NVDA screen reader)

Categories

(Core :: Disability Access APIs, defect)

Unspecified
Windows
defect

Tracking

()

People

(Reporter: sg, Unassigned)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/c22b3fb1-4db6-4b8e-af11-332640210209

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 nvdahelperremote.dll VBufStorage_buffer_t::clearBuffer C:\projects\nvda\build\x86_64\vbufBase\storage.cpp:812
1 nvdahelperremote.dll VBufBackend_t::renderThread_terminate C:\projects\nvda\build\x86_64\vbufBase\backend.cpp:136
2 nvdahelperremote.dll GeckoVBufBackend_t::renderThread_terminate C:\projects\nvda\build\x86_64\vbufBackends\gecko_ia2\gecko_ia2.cpp:1223
3 nvdahelperremote.dll <lambda_821ccee6a478194e60fadb2a8a0654db>::operator const C:\projects\nvda\build\x86_64\vbufBase\backend.cpp:235
4 nvdahelperremote.dll std::invoke<<lambda_821ccee6a478194e60fadb2a8a0654db>&> C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\include\type_traits:1584
5 nvdahelperremote.dll std::_Invoker_ret<void, 1>::_Call<<lambda_821ccee6a478194e60fadb2a8a0654db>&> C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\include\functional:744
6 nvdahelperremote.dll std::_Func_impl_no_alloc<<lambda_821ccee6a478194e60fadb2a8a0654db>, void>::_Do_call C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\include\functional:947
7 nvdahelperremote.dll std::_Func_class<void>::operator const C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\include\functional:995
8 nvdahelperremote.dll inProcess_getMessageHook C:\projects\nvda\build\x86_64\remote\inProcess.cpp:127
9 user32.dll DispatchHookW 

Not sure where to file this. It's happening inside NVDA code. It might be a NVDA bug or a bug in how Firefox interacts with it.

Flags: needinfo?(jteh)

Adding more signatures related to NVDA's module nvdahelperremote.dll and moving to the accessibility team for triage.

Crash Signature: [@ VBufStorage_buffer_t::clearBuffer] → [@ VBufStorage_buffer_t::clearBuffer] [@ VBufStorage_buffer_t::deleteSubtree] [@ VBufStorage_buffer_t::getLineOffsets] [@ RtlpFreeHeapInternal | RtlFreeHeap | free_base | VBufStorage_fieldNode_t::`scalar deleting destructor'] [@ vbufbackend_gecko_ia2.…
Component: Other → Disability Access APIs
Product: External Software Affecting Firefox → Core
Summary: Crash in [@ VBufStorage_buffer_t::clearBuffer] → Crash in [@ VBufStorage_buffer_t::clearBuffer] (with NVDA screen reader)
Severity: -- → S3
Flags: needinfo?(jteh)

May I ask how this has been marked as Severity 3? I don't claim to have full understanding of the ways you do triage, but when this crash occurs the entire Firefox goes down sometimes (like happened to me today) three times in a row. Can this be reprioritized or at least investigated please?

This was marked as s3 because:

  1. It's a crash in NVDA's virtual buffer code, not Firefox.
  2. It is a low volume crash; i.e. our data suggests it isn't seen often.
  3. We don't know how to reproduce it.

That said, if you can reproduce this reliably (or even semi reliably), please provide details and I'll see what I can do.

Flags: needinfo?(lukasz.golonka)

I'm afraid I don't have reliable STR. Where this happens most often is on GitHub either when refreshing the page with CTRL+_F5 or when loading GitHub fresh. I also would like to apologize for the tone of my last comment - after rereading it I should have word it better. It just so happens that even though this crash is quite rare it happens at most inconvenient times and it is always this particular one.

Flags: needinfo?(lukasz.golonka)
You need to log in before you can comment on or make changes to this bug.