`MapCallback`, `BufferUnmap`, `ReadbackPresentCallback` and
`ReadbackSnapshotCallback` all read a buffer's mapped range while
assuming it is still mapped. `MapCallback` is not invoked by wgpu-core
directly but from a task, so content can destroy or unmap the buffer, or
its device, before it runs. And once a device is lost or destroyed
wgpu-core destroys all of its buffers in `release_gpu_resources`, at the
end of whichever poll drains the device's queue; that poll is driven by
the GPU process, with no content involvement and no ordering against
content's messages.
Return a null ptr for `DestroyedResource` and `NotMapped` rather
than panicking, and handle that at each call site: send a map error to
content, skip the write-back flush, or skip the readback. `MapCallback`
also has to tolerate the parent's `mapData` for the buffer being gone,
which can be caused by content destroying or dropping the buffer.
Related fixes:
- moved `MapCallback`'s `get_mapped_range` call out of the read-only
branch so every map is checked.
- `Buffer::Unmap` previously cancelled a pending map without telling the
GPU process, so content saw the buffer as unmapped while wgpu-core
still
had it mapped. Forwarding that unmap is what makes the `NotMapped`
race
above reachable.
Differential Revision: https://phabricator.services.mozilla.com/D324946
Teodor Tanasoaia
30e739ff4f