Segfault with `ScaleMode::AspectRatioStretch`

[commonkestrel]

I am experiencing a segfault when drawing to a window with scale_mode: ScaleMode::AspectRatioStretch. It seems to work perfectly fine with ScaleMode::TopLeft, but it hits a segfault when calling update_with_buffer if the window is configured with ScaleMode::AspectRatioStretch.

I am running NixOS 24.05 on x86_64 with KDE Plasma for my GUI with wayland. I'm running Cargo version 1.77.1.

The minimum reproducible example I could find is the noise.rs example in the examples folder, with the scale-mode replaced with AspectRatioStretch.

Running valgrind (with wayland enabled) gives me the following result:

==180838== Memcheck, a memory error detector
==180838== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==180838== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==180838== Command: ./minifb-test
==180838== 
==180838== Invalid write of size 4
==180838==    at 0x16AD24: image_resize_linear_stride (scalar.c:54)
==180838==    by 0x16AD24: image_resize_linear_aspect_fill (scalar.c:91)
==180838==    by 0x133BB6: minifb::os::posix::wayland::Window::scale_buffer (wayland.rs:1218)
==180838==    by 0x1337B3: minifb::os::posix::wayland::Window::update_with_buffer_stride (wayland.rs:1185)
==180838==    by 0x133EB7: minifb::os::posix::Window::update_with_buffer_stride (mod.rs:102)
==180838==    by 0x129CEF: minifb::Window::update_with_buffer (lib.rs:385)
==180838==    by 0x1298D0: minifb_test::main (main.rs:49)
==180838==    by 0x12A99A: core::ops::function::FnOnce::call_once (function.rs:250)
==180838==    by 0x129FFD: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:155)
==180838==    by 0x12A070: std::rt::lang_start::{{closure}} (rt.rs:166)
==180838==    by 0x251F73: std::panicking::try (in /home/kestrel/Documents/Scripts/minifb-test/target/debug/minifb-test)
==180838==    by 0x246CDA: std::rt::lang_start_internal (in /home/kestrel/Documents/Scripts/minifb-test/target/debug/minifb-test)
==180838==    by 0x12A049: std::rt::lang_start (rt.rs:165)
==180838==  Address 0x5745040 is 0 bytes after a block of size 3,686,400 alloc'd
==180838==    at 0x484476B: malloc (in /nix/store/0h05z4gg0xcwb73m6in4j552gh1yqkb1-valgrind-3.22.0/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==180838==    by 0x219F32: alloc (alloc.rs:98)
==180838==    by 0x219F32: alloc::alloc::Global::alloc_impl (alloc.rs:181)
==180838==    by 0x21A268: <alloc::alloc::Global as core::alloc::Allocator>::allocate (alloc.rs:241)
==180838==    by 0x218E26: alloc::raw_vec::RawVec<T,A>::allocate_in (raw_vec.rs:199)
==180838==    by 0x1354F5: with_capacity_in<u32, alloc::alloc::Global> (raw_vec.rs:145)
==180838==    by 0x1354F5: with_capacity_in<u32, alloc::alloc::Global> (mod.rs:672)
==180838==    by 0x1354F5: alloc::vec::Vec<T>::with_capacity (mod.rs:481)
==180838==    by 0x1308D1: minifb::os::posix::wayland::Window::new (wayland.rs:560)
==180838==    by 0x133DAD: minifb::os::posix::Window::new (mod.rs:58)
==180838==    by 0x134040: minifb::Window::new (lib.rs:290)
==180838==    by 0x1295D4: minifb_test::main (main.rs:13)
==180838==    by 0x12A99A: core::ops::function::FnOnce::call_once (function.rs:250)
==180838==    by 0x129FFD: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:155)
==180838==    by 0x12A070: std::rt::lang_start::{{closure}} (rt.rs:166)
==180838== 
==180838== 
==180838== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==180838==  Access not within mapped region at address 0x57C1000
==180838==    at 0x16AD24: image_resize_linear_stride (scalar.c:54)
==180838==    by 0x16AD24: image_resize_linear_aspect_fill (scalar.c:91)
==180838==    by 0x133BB6: minifb::os::posix::wayland::Window::scale_buffer (wayland.rs:1218)
==180838==    by 0x1337B3: minifb::os::posix::wayland::Window::update_with_buffer_stride (wayland.rs:1185)
==180838==    by 0x133EB7: minifb::os::posix::Window::update_with_buffer_stride (mod.rs:102)
==180838==    by 0x129CEF: minifb::Window::update_with_buffer (lib.rs:385)
==180838==    by 0x1298D0: minifb_test::main (main.rs:49)
==180838==    by 0x12A99A: core::ops::function::FnOnce::call_once (function.rs:250)
==180838==    by 0x129FFD: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:155)
==180838==    by 0x12A070: std::rt::lang_start::{{closure}} (rt.rs:166)
==180838==    by 0x251F73: std::panicking::try (in /home/kestrel/Documents/Scripts/minifb-test/target/debug/minifb-test)
==180838==    by 0x246CDA: std::rt::lang_start_internal (in /home/kestrel/Documents/Scripts/minifb-test/target/debug/minifb-test)
==180838==    by 0x12A049: std::rt::lang_start (rt.rs:165)
==180838==  If you believe this happened as a result of a stack
==180838==  overflow in your program's main thread (unlikely but
==180838==  possible), you can try to increase the size of the
==180838==  main thread stack using the --main-stacksize= flag.
==180838==  The main thread stack size used in this run was 8388608.
==180838== 
==180838== HEAP SUMMARY:
==180838==     in use at exit: 7,567,215 bytes in 165 blocks
==180838==   total heap usage: 352 allocs, 187 frees, 11,283,395 bytes allocated
==180838== 
==180838== LEAK SUMMARY:
==180838==    definitely lost: 0 bytes in 0 blocks
==180838==    indirectly lost: 0 bytes in 0 blocks
==180838==      possibly lost: 2,304 bytes in 1 blocks
==180838==    still reachable: 7,564,911 bytes in 164 blocks
==180838==         suppressed: 0 bytes in 0 blocks
==180838== Rerun with --leak-check=full to see details of leaked memory
==180838== 
==180838== For lists of detected and suppressed errors, rerun with: -s
==180838== ERROR SUMMARY: 71522 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

[emoon]

Hey,

Thanks for the report. I will take a look at it today.

[emoon]

Ok I think this was broken in https://github.com/emoon/rust_minifb/commit/b212316ae658619961e25e7f82305ee8126204ad @StefanoIncardone

I have commit a new fix to master here: https://github.com/emoon/rust_minifb/commit/d62b0f506191539b1baed0f658d8fa324e9efb67 please give it a spin and see if it fixes the crash for you. I'm not sure it fully working correct yet tho.

[commonkestrel]

It looks like that worked! Thank you so much