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

Segfault with ScaleMode::AspectRatioStretch #355

Open
commonkestrel opened this issue Jul 23, 2024 · 3 comments
Open

Segfault with ScaleMode::AspectRatioStretch #355

commonkestrel opened this issue Jul 23, 2024 · 3 comments

Comments

@commonkestrel
Copy link

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
Copy link
Owner

emoon commented Jul 24, 2024

Hey,

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

@emoon
Copy link
Owner

emoon commented Jul 24, 2024

Ok I think this was broken in b212316 @StefanoIncardone

I have commit a new fix to master here: d62b0f5 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
Copy link
Author

It looks like that worked! Thank you so much

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

No branches or pull requests

2 participants