winit: Regression in 0.28 - NSWindow leaks on macOS

I bisected to 340f951d10c74169c258a120530b1eadf3a3e9fe, this appears to be caused by the objc2 port @madsmtm

This caused a worse issue for me downstream than just a memory leak - my windows have strong references to metal layers on them, so after opening/closing enough windows, the system runs out of IOSurface or something and metal breaks system-wide.

I reproduced the issue by modifying examples/window.rs to the following and running cargo run --example window to basically create and drop a window every iteration. With the issue, memory usage grows unbounded. In 0.27.5, memory usage fluctuated but was stable. Xcode debugger suggests the NSWindow objects are being leaked.

#![allow(clippy::single_match)]

use simple_logger::SimpleLogger;
use winit::{
    event::{Event, WindowEvent},
    event_loop::EventLoop,
    window::WindowBuilder,
};

fn main() {
    SimpleLogger::new().init().unwrap();
    let event_loop = EventLoop::new();

    let mut window: Option<winit::window::Window> = None;

    event_loop.run(move |event, window_target, control_flow| {
        control_flow.set_wait();
        println!("{:?}", event);

        match event {
            Event::MainEventsCleared => {
                window.replace(WindowBuilder::new()
                    .with_title("A fantastic window!")
                    .with_inner_size(winit::dpi::LogicalSize::new(128.0, 128.0))
                    .build(&window_target)
                    .unwrap());
            }
            _ => (),
        }
    });
}

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 16 (16 by maintainers)

Most upvoted comments

I think cherry-picking that objc2 commit fixed it for me, I’m going to go with a cargo patch on my side, IMO you should just see if you can get that commit into a hotfixed objc2 version for winit