Bugzilla

There's no reliable way to reproduce this that I've found. It happens rarely, but when it does, you have to kill the browser. While I'm not ruling out a bug in NVDA, I haven't heard any reports of this without CTW or in Chromium browsers (which use the same NVDA vbuf code), so it seems to be related to CTW somehow.

Sometimes, Firefox will freeze without warning and report "not responding". If I attach with a debugger, I see a stack like this:

```
00 000000fa`927fe350 00007ffc`c3d59c52     nvdaHelperRemote!VBufStorage_buffer_t::insertNode(class VBufStorage_controlFieldNode_t * parent = 0x000002ac`9853a160, class VBufStorage_fieldNode_t * previous = 0x00000000`00000000, class VBufStorage_fieldNode_t * node = 0x000002ac`98a88210)+0xc53 [C:\projects\nvda\build\x86_64\vbufBase\storage.cpp @ 494] 
01 000000fa`927fe3f0 00007ffc`c3d69afe     nvdaHelperRemote!VBufStorage_buffer_t::replaceSubtrees(class std::map<VBufStorage_fieldNode_t *,VBufStorage_buffer_t *,std::less<VBufStorage_fieldNode_t *>,std::allocator<std::pair<VBufStorage_fieldNode_t * const,VBufStorage_buffer_t *> > > * m = 0x000000fa`927fe570 { size=0x2 })+0xa82 [C:\projects\nvda\build\x86_64\vbufBase\storage.cpp @ 690] 
02 000000fa`927fe540 00007ffc`c3d6928c     nvdaHelperRemote!VBufBackend_t::update(void)+0x24e [C:\projects\nvda\build\x86_64\vbufBase\backend.cpp @ 214] 
03 000000fa`927fe600 00007ffd`1489121c     nvdaHelperRemote!VBufBackend_t::renderThread_timerProc(struct HWND__ * hwnd = 0x00000000`00000000, unsigned int msg = 0, unsigned int64 timerID = 0x3f4b, unsigned long time = 0x80000022)+0xbc [C:\projects\nvda\build\x86_64\vbufBase\backend.cpp @ 120] 
04 000000fa`927fe630 00007ffd`14890cf8     user32!UserCallWinProc+0x2cc
05 000000fa`927fe790 00007ffc`75309b7d     user32!DispatchMessageWorker+0xf8
06 000000fa`927fe810 00007ffc`7519f2ed     xul!nsAppShell::ProcessNextNativeEvent(bool mayWait = <Value unavailable error>)+0x1ed [/builds/worker/checkouts/gecko/widget/windows/nsAppShell.cpp @ 738] 
...
```

[Here is the code at the top of the stack](https://github.com/nvaccess/nvda/blob/release-2021.3/nvdaHelper/vbufBase/storage.cpp#L494):

```
		for(VBufStorage_fieldNode_t* ancestor=node->parent;ancestor!=NULL;ancestor=ancestor->parent) {
			ancestor->length+=node->length
...
```

This suggests that somehow, NVDA's vbuf got into a state where there was a loop in the tree such that walking the ancestors is an infinite loop. This could mean that the Gecko a11y tre contained a loop at some point. Alternatively, it could mean that Gecko a11y isn't firing some event that it should, so NVDA isn't getting the correct info it needs to update the buffer correctly.

I had hoped that bug 1782146 would fix this, but I saw it happen after that fix. :(

There's no reliable way to reproduce this that I've found. It happens rarely, but when it does, you have to kill the browser. While I'm not ruling out a bug in NVDA, I haven't heard any reports of this without CTW or in Chromium browsers (which use the same NVDA vbuf code), so it seems to be related to CTW somehow.

Sometimes, Firefox will freeze without warning and report "not responding". If I attach with a debugger, I see a stack like this:

```
00 000000fa`927fe350 00007ffc`c3d59c52     nvdaHelperRemote!VBufStorage_buffer_t::insertNode(class VBufStorage_controlFieldNode_t * parent = 0x000002ac`9853a160, class VBufStorage_fieldNode_t * previous = 0x00000000`00000000, class VBufStorage_fieldNode_t * node = 0x000002ac`98a88210)+0xc53 [C:\projects\nvda\build\x86_64\vbufBase\storage.cpp @ 494] 
01 000000fa`927fe3f0 00007ffc`c3d69afe     nvdaHelperRemote!VBufStorage_buffer_t::replaceSubtrees(class std::map<VBufStorage_fieldNode_t *,VBufStorage_buffer_t *,std::less<VBufStorage_fieldNode_t *>,std::allocator<std::pair<VBufStorage_fieldNode_t * const,VBufStorage_buffer_t *> > > * m = 0x000000fa`927fe570 { size=0x2 })+0xa82 [C:\projects\nvda\build\x86_64\vbufBase\storage.cpp @ 690] 
02 000000fa`927fe540 00007ffc`c3d6928c     nvdaHelperRemote!VBufBackend_t::update(void)+0x24e [C:\projects\nvda\build\x86_64\vbufBase\backend.cpp @ 214] 
03 000000fa`927fe600 00007ffd`1489121c     nvdaHelperRemote!VBufBackend_t::renderThread_timerProc(struct HWND__ * hwnd = 0x00000000`00000000, unsigned int msg = 0, unsigned int64 timerID = 0x3f4b, unsigned long time = 0x80000022)+0xbc [C:\projects\nvda\build\x86_64\vbufBase\backend.cpp @ 120] 
04 000000fa`927fe630 00007ffd`14890cf8     user32!UserCallWinProc+0x2cc
05 000000fa`927fe790 00007ffc`75309b7d     user32!DispatchMessageWorker+0xf8
06 000000fa`927fe810 00007ffc`7519f2ed     xul!nsAppShell::ProcessNextNativeEvent(bool mayWait = <Value unavailable error>)+0x1ed [/builds/worker/checkouts/gecko/widget/windows/nsAppShell.cpp @ 738] 
...
```

[Here is the code at the top of the stack](https://github.com/nvaccess/nvda/blob/release-2021.3/nvdaHelper/vbufBase/storage.cpp#L494):

```
		for(VBufStorage_fieldNode_t* ancestor=node->parent;ancestor!=NULL;ancestor=ancestor->parent) {
			ancestor->length+=node->length;
...
```

This suggests that somehow, NVDA's vbuf got into a state where there was a loop in the tree such that walking the ancestors is an infinite loop. This happens during an update to the buffer, not during the initial build. This could mean that the Gecko a11y tre contained a loop at some point. Alternatively, it could mean that Gecko a11y isn't firing some event that it should, so NVDA isn't getting the correct info it needs to update the buffer correctly.

I had hoped that bug 1782146 would fix this, but I saw it happen after that fix. :(