Search Issue Tracker

Won't Fix



Found in


Issue ID




InvalidOperationException when using AsyncGPUReadback.RequestIntoNativeArray



How to reproduce:
1. Download and open the attached project
2. Enter Play mode
3. Observe the console window

Expected outcome: No errors appear
Actual outcome: "InvalidOperationException: The Unity.Collections.NativeArray`1[System.Single] can no longer be accessed, since its owner has been invalidated. You can simply Dispose() the container and create a new one." error appears

Reproduced with: 2020.3.46f1, 2021.3.21f1, 2022.2.11f1, 2023.1.0b8, 2023.2.0a6

  1. Resolution Note:

    This issue appears to be the result of a limitation on performing multiple readbacks to the same NativeArray within a single frame.

    The safety checks do not allow for multiple writes to occur to the same NativeArray object. In this case, the user script attempts to readback into multiple slices of a single native array.

    The collections safety checks don't allow for multiple async operations to write to the same NativeArray even if the slices don't overlap. Essentially the safety checks are conservative and operate on the object level and not the memory slice level.

    This can be addressed by modifying the user script to readback into multiple NativeArray objects (one for each call to RequestIntoNativeArray) instead of slices of a single NativeArray.

Comments (8)

  1. LudiKha

    Nov 09, 2023 10:01

    Errors are still thrown Unity 2021.3 Editor, but not in builds according to my tests. Do note that the readback is actually completed without issue, and only errors are thrown.

  2. brofessordoucette

    Oct 31, 2023 05:43

    Still broken.

    AsyncGPUReadback - NativeArray does not have read/write access

    AsyncGPUReadback - NativeArray should not be undisposable

  3. msue2

    Oct 24, 2023 13:26

    Still observed in 2021.3.31

    Claimed to have been fixed in issue #1295472 , YMMV.

  4. IIporpammep

    Oct 06, 2023 14:39

    Please fix this bug, so I can use it for occlusion culling with depth texture.

  5. thebarryman

    Sep 12, 2023 03:35

    Am I correct in my understanding that this bug means there is essentially no reason to use RequestIntoNativeArray rather than Request? Both methods seem to force you to allocate a new array every time you have a new request.

  6. Hyperg

    Sep 04, 2023 10:40

    Thanks for the quote, Gravenstein! I didn't see this issue on the tracker (looked at a couple of similar ones). There is nothing really more to reproducing it other than those steps, indeed. The only mention to be had here is that we are not getting the error in the issue but "AsyncGPUReadback - NativeArray does not have read/write access" and "AsyncGPUReadback - NativeArray should not be undisposable" respectively (both thrown for the same call).

  7. iamarugin

    Sep 02, 2023 08:39

    Please, fix it, this bug is like three years old.

  8. gravenstein

    Sep 01, 2023 14:27

    A more detailed guide to reproduce it. It was written by Hypergeanu on the forums, but we are having the exact same issue in the same way.

    - Create persistent NativeArray (only once);
    - Call AsyncGPUReadback.RequestIntoNativeArray;
    - Wait for completion;
    - Create and schedule a job that reads from the array (after that gpu request is done);
    - Run the job, call complete on the job handle (the job transfers the data from the nativearray into a different one, so the usage cycle of the nativearray used for gpu request ends here).

    The sequence above executes with no errors for the first pass, but when it is called again (the buffer stays the same, its purpose is to perform these requests and job processing repeatedly using the pre-allocated memory), the specified errors are thrown when the array is touched by the gpu async request.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.