Skip to content
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

[linux+wayland] loop_mode.rs example panic!s when switching from previous loop mode to Wait loop mode #354

Closed
mitchmindtree opened this issue Jun 19, 2019 · 2 comments · Fixed by #452

Comments

@mitchmindtree
Copy link
Member

I noticed this when testing out #353, but then double-checked and noticed that it's happening on master too! Not sure how this one slipped by or when it was introduced. It could very well be unique to wayland but I'm not sure yet.

To produce the bug, I:

  • Ran the loop_mode.rs example.
  • Press the spacebar 3 times to switch through each of the loop modes to get back to the Wait loop mode (note to future testers: might have to press the spacebar 4 times as a new loop mode is being added in Proposal for NTimes #353).
  • Move the mouse around to generate some more events and in turn more update and view calls until the following panic! occurs:
thread 'main' panicked at 'failed to execute future: AccessError { error: SwapchainImageAcquireOnly, command_name: "vkCmdBeginRenderPass", command_param: "attachment 1", command_offset: 1 }', src/libcore/result.rs:999:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/garden.eu.org-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/garden.eu.org-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:212
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:475
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:382
   8: rust_begin_unwind
             at src/libstd/panicking.rs:309
   9: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  10: core::result::unwrap_failed
             at /rustc/02564de47b40e953b5144dfd37450c16a84672f1/src/libcore/macros.rs:18
  11: core::result::Result<T,E>::expect
             at /rustc/02564de47b40e953b5144dfd37450c16a84672f1/src/libcore/result.rs:827
  12: nannou::app::view_frame
             at ./src/app.rs:2167
  13: nannou::app::acquire_image_and_view_frame
             at ./src/app.rs:2250
  14: nannou::app::run_loop_mode_wait
             at ./src/app.rs:1411
  15: nannou::app::run_loop
             at ./src/app.rs:1240
  16: nannou::app::Builder<M,E>::run
             at ./src/app.rs:636
  17: loop_mode::main
             at examples/loop_mode.rs:13
  18: std::rt::lang_start::{{closure}}
             at /rustc/02564de47b40e953b5144dfd37450c16a84672f1/src/libstd/rt.rs:64
  19: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:49
  20: std::panicking::try::do_call
             at src/libstd/panicking.rs:294
  21: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:85
  22: std::panicking::try
             at src/libstd/panicking.rs:273
  23: std::panic::catch_unwind
             at src/libstd/panic.rs:388
  24: std::rt::lang_start_internal
             at src/libstd/rt.rs:48
  25: std::rt::lang_start
             at /rustc/02564de47b40e953b5144dfd37450c16a84672f1/src/libstd/rt.rs:64
  26: main
  27: __libc_start_main
  28: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
@freesig
Copy link
Collaborator

freesig commented Jun 20, 2019

Looks like something is trying to access the swapchain image after it is sent to the gpu

@freesig
Copy link
Collaborator

freesig commented Jun 20, 2019

Or maybe the lock isn't released yet before the image is sent. I'd guess that another drawing has started before the first has been sent to the gpu

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants