crash when resizing window

[ghost]

crate version: 0.13.0

Sometimes when I resize, the application crashes, reporting that the buffer size does not match the window size. I tried to test various starting sizes and also various magnitudes, directions, and speeds of resizing and perhaps the speed of resizing matters but I can’t be sure.

This is reproducible in Linux, macOS and Windows using the menu example:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: UpdateFailed("Update failed because input buffer is too small. Required size for 1088 x 998 window (2x scale) is 1085824 bytes but the size of the input buffer has the size 921600 bytes")', src\libcore\result.rs:1084:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: process didn't exit successfully: `target\release\examples\menu.exe` (exit code: 101)

Interestingly, I also tried this on Linux in a VM and while I can reproduce the crash with a VM having a display size of 1280x1024, I cannot reproduce this when resizing the window within the confines of a display of 1024x768.

[emoon]

Hi. Yeah so I will start looking at these issues soon. I just been busy at doing other things so I haven't come around to do it. The reason why I haven't started yet is that I'm going to do some upfront work to prepare the windows backend for GPU support also. This comes in line with #93 as this has been requested in various places and requires work on all backends.

So right now I just haven't figured out exactly how I want to do all of that work yet.

[ghost]

Absolutely no worries at all. I appreciate the library. I just wanted a simple bitmap to screen library and behold there it was.

…

________________________________ From: Daniel Collin <notifications@github.com> Sent: Friday, October 18, 2019 2:01:21 PM To: emoon/rust_minifb <rust_minifb@noreply.github.com> Cc: Alexander Nye <alexnye@outlook.com>; Author <author@noreply.github.com> Subject: Re: [emoon/rust_minifb] crash on macOS on window resizing (#94) Hi. Yeah so I will start looking at these issues soon. I just been busy at doing other things so I haven't come around to do it. The reason why I haven't started yet is that I'm going to do some upfront work to prepare the windows backend for GPU support also. This comes in line with #93<#93> as this has been requested in various places and requires work on all backends. So right now I just haven't figured out exactly how I want to do all of that work yet. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#94?email_source=notifications&email_token=AKAQSR3XJWE4OZAPY6LVD7LQPIP2DA5CNFSM4JCMAW7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBV634Q#issuecomment-543944178>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKAQSR6ZN7XH75OGXXDW7IDQPIP2DANCNFSM4JCMAW7A>.

[emoon]

Yeah that was always my goal with it. It has grown a bit since the initial release for sure :) I will have some time off work in a few weeks and then I will work on a few things and set up some goal to take it to 1.0

[ghost]

Alright, I've tested on Windows now too and see the same thing, so I edited the issue.

Also, I took a look at the code. It's pretty straightforward and the bug appears to be just that the window has changed size, which the library detects successfully, but the library intentionally crashes at this point by unwrapping the error.

That seems like a hard problem. Your day job is game dev? I do web dev mainly so I don't know what you could really do about this. It seems like the OS would have to either lock the window frame size while we're writing to the buffer and before we blit it to screen, or the OS would have to handle buffers larger or smaller than the expected size.

[ghost]

Alright I checked on Linux as well. And I saw some notes from developers in C# at least that the way this is usually handled is an OS-provided callback wherein one can resize and repaint the buffer, discarding the one which doesn't fit.

I don't mind preventing resizing in my window options either. Given that macOS is the only environment which allows resizing the window even when the options try to prevent it, this isn't much of an issue.

[emoon]

Sorry I missed the updates on this. I think this is fixable and I will give it some testing soon.

[emoon]

I'm starting to look at this now. Do you still have the code that causes this? Or is it possible to make it happen with some of the examples? (for example the noise example supports resizing)

[ghost]

I used cargo run --example menu when testing on macOS. I also saw this with my own application code.

I just did some more testing with the latest master at a2633f78ad5da6cfb2fd68c66df85fc47ff35056.

I tried cargo run --example noise and when the window opened I couldn't reproduce this even after fiddling with the window for a few minutes. However, the application segfaults instead of opening a window more often than not with this example. When the window does open, it seems to handle resizing well.

The menu example consistently opens without segfaulting. Resizing the window to less than its original size works fine. Resizing the window to less than its original size, then resizing it larger (but no larger than its original size) works fine. If and only if the window is resized to greater than its original size, I still see:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: UpdateFailed("Update failed because input buffer is too small. Required size for 1371 x 806 window (2x scale) is 1104220 bytes but the size of the input buffer has the size 921600 bytes")', src/libcore/result.rs:1165:5

[emoon]

I see. Thanks for the info

However, the application segfaults instead of opening a window more often than not with this example. When the window does open, it seems to handle resizing well.

Does it mean that the example will just crash without showing anything and I assume this is random then if that is the case?

[emoon]

Details in this #113 and how it will be fixed

[emoon]

@Axelderan hey, if you have the possibility of grabbing the latest minifb, switch over to dev branch and try this again that would be awesome. I hope it should all be fixed now (on Linux only, I'm going to start on macOS after that)

[ghost]

Yes I’ll try to do that in the next few days

[ghost]

I think that fix worked!

[emoon]

Cool. Thanks for checking.

[ghost]

I’ve tested still more on another Linux install and I think this is safe to mark as resolved.

[emoon]

Great! I will include this in the 0.15 release (I need to fix up the other platforms also)