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)
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