-
Notifications
You must be signed in to change notification settings - Fork 12
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
Presence of garbage data when retrieving physical device memory types #35
Comments
Hi, thanks for raising the issue. The correct usage is to restrict the While the workaround is clear, it would make for less confusion to just special-case this struct/API call to have variable-size |
hi! thanks for quick reply. I kindof figured I should simply not read more items than what's specified in (Btw how is this different from other array-returning functions (such as the queries for queue families) that seem to behave just right?) |
The difference is in the API. |
As of 1.3.207, it seems that the issue with bounded arrays containing garbage concerns the following structures:
Ideally, instead of having docs about this (since there are lots of things described in the docs already) we should replace these fixed-size tuples with |
get_physical_device_memory_properties
Hi, |
That's what I think as well, as these structures look like they'll be used mostly in application setup/initialization. |
🤔 looks like the structures aren't static, at least SwiftShader is copying the data out: |
I guess that depends what the |
Ah yes I thought that the data would be laying somewhere indefinitely and we could just safely pick a view for them. Unfortunately not the case 😅 |
Closing this to avoid hanging issues, thanks! |
Hi,
I'm getting what seems to be an overflowing buffer reads when trying to enumerate the available physical device memory types.
Reduced to the simplest reproducer I know the problem looks like this:
The command lists a few valid memory types, but these are followed by garbage that looks like random data picked from uninitialized memory, such as:
The beginning of the listing checks with the
vulkaninfo
, the rest seems to be garbage.I'll try to debug what's wrong and report back. Is there any guess on whether this is a possible "premature GC" issue?
Thanks!
-mk
Relevant vulkaninfo section:
The text was updated successfully, but these errors were encountered: