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
No item names for some listviews (64-bit) #8175
Comments
I am also very uncomfortable with this problem. This issue can be reproduced in both 2018.1 and master, next versions. |
BackgroundThe list in question is defined in:
The problematic class is:
and the method involved:
General Code Flow:
Debug ResultNote that this is made with NVDA in source mode and two helper functions:
The command (after selecting an item in the list view) is:
1. The structure written to VM:
2. the arguments passed to "ReadProcessMemory":
3. The returned structure
4. The arguments for reading the buffer:
5. The resulting error:
Conclusion:
Note that all other functions in this class that use the similar procedure work fine. There is nothing mentioned on MSDN with regard to the LVM_GETITEMTEXTW message. However, this can be found under the similar LVM_GETITEMW "Remarks" section:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb774953(v=vs.85).aspx |
I just closed #7874 in favour of this issue. @Robert-J-H: Thanks for providing a technical background. |
Hi, Because we did have issues with this particular structure, and since we now have more detailed information, I recommend keeping this one in favor of others. Thanks. CC @jcsteh, @michaelDCurran |
Thanks @leonardder I should have investigated a bit deeper and commented on the open issue.
For the buffer creation "item.cchTextMax" should be used instead. |
LVM_GETITEMTEXT is documented to return the length of the text, which is why we do (and it's appropriate for us to) use it as the length of the buffer. The issue with 64 bit apps is that NVDA, as a 32 bit app, can't accept remote 64 bit memory addresses. There's another issue open somewhere to deal with this using our own in-process memory reading/writing helpers.
|
@jcsteh
|
Item text in a list view can't be retrieved if the returned pointer is 64 bits long. Therefore, return the displayText within the column boundaries instead.
I've created pull request #8190 that addresses this issue, although not at a IPC level. |
I'm using NVDA version alpha-15693,b46b83ea and now the reading of the log list in TortoiseSVN is broken again. Was this commit one of the ones lost during the change of the testing/release process a few weeks ago? |
Hi, yes. Thanks.
|
If I read the two above comments correctly, shouldn't the patch for PR #8190 be merged again or am I missing the point? |
I don't understand why it was lost and never merged again... |
Sure, it could have been merged some two years ago.
Seems that NV Access wants another way but I'm not sure if it will
work so easily within the C++ code.
…On 13/05/2020, ruifontes ***@***.***> wrote:
I don't understand why it was lost and never merged again...
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#8175 (comment)
|
Bumping this because it's also been identified as a show-stopper issue for Sibiac (an NVDA addon that provides access to DAW plugins in context of music production). Any news on that merge? |
In which way does it tangle Sibiac?
I use Azlo's addon daily, although be it with Python 2.
For now, the author could just overwrite the SysListView32 class with
this version and work from there.
|
Hey @Robert-J-H , my admittedly layman understanding of how this relates to Sibiac is that with some 64-bit plugins, this issue affects NVDA's handling of the FX chain list view, which is where Sibiac recognizes the plugin that's loaded and determines which overlay to use. CC-ing @AZSlow3, he's better placed to explain what's going on. |
Hm, I see some problems in the FX Chain list box. It often stops to
read the actual VST Plug-in (Same in the browser) and NVDA reports
some out of memory error.
Which is hardly the case with 32 GB.
Anyway, Reapi has a function to return the current dll associated with
the focused plug-in. This makes sense as plug-in instances can have
any name if the user wishes so.
Apart from the memory leak that I've mentioned above, the lists work
nicely in Reaper, including name and number of entries. In contrast,
the lack of those would mark the issue addressed in this thread.
The MRO for a list item is (ignore the column review part, it's
created by an addon):
Python class mro: (<class
'NVDAObjects.Dynamic_ColumnsReview32ListItemIAccessible'>, <class
'globalPlugins.columnsReview.ColumnsReview32'>, <class
'globalPlugins.columnsReview.ColumnsReview'>, <class
'NVDAObjects.IAccessible.sysListView32.ListItem'>, <class
'NVDAObjects.behaviors.RowWithFakeNavigation'>, <class
'NVDAObjects.behaviors.RowWithoutCellObjects'>, <class
'NVDAObjects.IAccessible.sysListView32.ListItemWithoutColumnSupport'>,
<class 'NVDAObjects.IAccessible.IAccessible'>, <class
'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class
'documentBase.TextContainerObject'>, <class
'baseObject.ScriptableObject'>, <class
'baseObject.AutoPropertyObject'>, <type 'object'>)
|
I'm confused. The FX Chain list reads just fine for me in 64 bit REAPER with NVDA...?
|
There is no strait way to reproduce the problem in REAPER. So far I cood hit it with Toontrack EZ Drummer and XLN Addictive Drums VSTi only, in relatively busy project. These plug-ins fill all lower 32bit address space during GUI loading. Can be somehow JUCE related, so probably affect many plug-ins. Synthetic test is in http://www.azslow.com/index.php?action=downloads;sa=downfile&id=77 If I understand that right, IAccessible works using the same approach. So many things can break once 32bit addresses are reserved in the target. That is not a bug on 64bit application side, modern programs grow in size, VirtualAlloc is not unusual call inside applications and consumes lower address space by default. Not good for 32bit accessibility applications. |
Here is a try build that hopefully fixes this issue. |
Good job! Thanks! It is working on my end. |
Hey @leonardder, just tested the try build above in Reaper X64, and I'm still getting broken list views in the FX window once memory usage of the project exceeds 4GB. Is there anything I can provide to help diagnose? NVDA log etc? |
@scott, yes do so. Is the error the same as in the normal built?
|
@ScottChesworth A log would be pretty helpful. However, I'm pretty sure this error has a different background and requires more porting to C++. |
Hi @ScottChesworth could you please provide an NVDA log for this issue, or advise if it still occurs? |
@feerrenrut, yep, still present in the public release of NVDA 2020.4. In the software I use most often (Reaper X64), any plug-in included in the "List1" control of Reaper's FX window in a project that uses over 4GB of RAM seems to be susceptible on my machine. It doesn't happen every time those conditions are met here, but it does happen often. I seem to be having a lucky day today, will pop a log in here next time I experience it. Thanks for the nudge, I should've done that ages ago. |
Confirmed here. The list in the FX Browser is affected as well.
|
I've been seeing this in REAPER in all ListViews (FX chain list, FX add list, Actions list) with large projects too. I didn't grab a log when it was happening, though. :( |
It's primarily in large projects when it happens here. Annoyingly it always seems to crop up when I'm against the clock. Will try harder to remember that I need to grab a log next time it occurs. |
@AZSlow3's synthetic test case in #8175 (comment) makes it ridiculously easy to reproduce this. Thanks. Log:
Fixing this will require moving
|
To further clarify, the difference between this issue and the earlier one is that with the earlier (now fixed) one, we can successfully allocate 32 bit memory in the remote process, but the control decides to give us back memory beyond 32 bit and we fail to read it. In this case, we can't allocate any 32 bit memory in the remote process at all because it's been exhausted. |
I can confirm that my current workaround (own 64bit proxy) overwrites columnOrderArray for the List and getColumnLocationRaw for ListItem. That way FX List in REAPER works correctly (that list has no Header). |
The following try build works with @AZSlow3's test case: |
…ired (PR #13271) Fixes #8175 Follow up of #11745 Fixes regression from #11469, #9873 Summary: Getting list item content on 64 bit systems sometimes failed. Description of change: Based on #11745, fetching text content in-process fixed some but not all issues. The change adds: - Location fetching - Column header text fetching - Column order array fetching In short, everything that required allocating memory within a process using VirtualAlloc
We've just merged new code affecting this issue to alpha and beta. Based on this issue history, can anyone confirm that the latest alpha works as expected when using:
|
@leonardder can you confirm #11468 is still fixed on alpha? |
I installed Alpha and tested it with SVN, and the list items can be report fine. |
Thanks @cary-rowen |
I've tested the FX browser and the FX chain list in Reaper X64. List box controls seem solid here in projects that were using enough memory to consistently break before. Thanks much for the effort that went into this! |
Thanks @ScottChesworth for the testing |
Steps to reproduce:
Example app: Tortoise SVN
Expected behavior:
The name of the focused item should be announced.
Actual behavior:
Only the state (e.g. selected) is announced
System configuration:
NVDA version next-15028,2754a2c8
Installed/Source/portable
Windows 10 (x64), Version 1803 (OS Build 17133.73)
Name and version of other software in use when reproducing the issue:
Tortoise SVN 1.9.7.27907 x64
Other questions:
Does the issue still occur after restarting your PC?
Yes
Have you tried any other versions of NVDA?
Not relevant
The text was updated successfully, but these errors were encountered: