Description
When attempting to map buffers in LifetimeTracker::handle_mapping there is a panic if the buffer is not in the Waiting state.
let mapping = match std::mem::replace(
&mut buffer.map_state,
resource::BufferMapState::Idle,
) {
resource::BufferMapState::Waiting(pending_mapping) => pending_mapping,
_ => panic!("No pending mapping."),
};However, calling buffer_unmap ignores this state and replaces it with the Idle state without any type of cancellation mechanism being invoked.
resource::BufferMapState::Waiting(_) => {}This leads to a panic the next time handle_mapping is called.
Repro steps
In the wgpu-rs capture example apply this diff and run:
diff --git a/examples/capture/main.rs b/examples/capture/main.rs
index 71157c2..522989f 100644
--- a/examples/capture/main.rs
+++ b/examples/capture/main.rs
@@ -126,6 +126,7 @@ async fn create_png(
// Note that we're not calling `.await` here.
let buffer_slice = output_buffer.slice(..);
let buffer_future = buffer_slice.map_async(wgpu::MapMode::Read);
+ output_buffer.unmap();
// Poll the device in a blocking manner so that our future resolves.
// In an actual application, `device.poll(...)` shouldExpected vs observed behavior
The spec states
Thus, I expect the Future resolves to a mapping aborted error rather than a panic when polling the device
Description
When attempting to map buffers in
LifetimeTracker::handle_mappingthere is a panic if the buffer is not in theWaitingstate.However, calling
buffer_unmapignores this state and replaces it with theIdlestate without any type of cancellation mechanism being invoked.This leads to a panic the next time
handle_mappingis called.Repro steps
In the
wgpu-rscapture example apply this diff and run:Expected vs observed behavior
The spec states
Thus, I expect the
Futureresolves to a mapping aborted error rather than a panic when polling the device