memory leak and crash

[s0hey1]

Describe the bug when i activate cursor vfx the "railgun" or "torpedo" , memory usage is constantly growing and eventually crash neovide, i think skia drawOval has memory leak and cause heap fragmentation. the drawRect has not this problem.

To Reproduce scroll up and down a large file while the cursor vfx is active

Desktop (please complete the following information):

• Neovide Version 0.7.0 main branch
• Neovim Version 0.5.0

Additional context stack backtrace:

(lldb) bt
* thread #1, name = 'neovide', stop reason = signal SIGABRT
  * frame #0: 0x00007ffff7939d22 libc.so.6`raise + 322
    frame #1: 0x00007ffff7923862 libc.so.6`abort + 278
    frame #2: 0x00005555558c74e7 neovide`std::sys::unix::abort_internal::hba19dccca7c1e209 at mod.rs:206:14
    frame #3: 0x00005555555fb756 neovide`std::process::abort::ha624dd3301924e69 at process.rs:1814:5
    frame #4: 0x00005555558f08fd neovide`rust_oom at alloc.rs:332:5
    frame #5: 0x000055555562c5f6 neovide`__rg_oom at alloc.rs:397:18
    frame #6: 0x000055555561d1c6 neovide`__rust_alloc_error_handler + 6
    frame #7: 0x00005555555e6026 neovide`alloc::alloc::handle_alloc_error::hc93896c0bb99c404 at alloc.rs:366:9
    frame #8: 0x000055555575790d neovide`neovide::renderer::fonts::font_loader::FontPair::new::h0cd287bced57cd41 at raw_vec.rs:200:27
    frame #9: 0x00005555557578e5 neovide`neovide::renderer::fonts::font_loader::FontPair::new::h0cd287bced57cd41 [inlined] alloc::raw_vec::RawVec$LT$T$C$A$GT$::with_capacity_zeroed_in::h50b2a0cae49d3417(capacity=1741792) at raw_vec.rs:143
    frame #10: 0x00005555557578e5 neovide`neovide::renderer::fonts::font_loader::FontPair::new::h0cd287bced57cd41 [inlined] _$LT$u8$u20$as$u20$alloc..vec..spec_from_elem..SpecFromElem$GT$::from_elem::hcc3ee8c42f5147d3(elem='\0', n=1741792) at spec_from_elem.rs:39
    frame #11: 0x00005555557578e5 neovide`neovide::renderer::fonts::font_loader::FontPair::new::h0cd287bced57cd41 [inlined] alloc::vec::from_elem::heeb3f047dc7b7428(elem='\0', n=1741792) at mod.rs:2250
    frame #12: 0x00005555557578e5 neovide`neovide::renderer::fonts::font_loader::FontPair::new::h0cd287bced57cd41 at typeface.rs:259
    frame #13: 0x00005555557578d9 neovide`neovide::renderer::fonts::font_loader::FontPair::new::h0cd287bced57cd41 at option.rs:694
    frame #14: 0x00005555557578d9 neovide`neovide::renderer::fonts::font_loader::FontPair::new::h0cd287bced57cd41 at typeface.rs:256
    frame #15: 0x00005555557578a9 neovide`neovide::renderer::fonts::font_loader::FontPair::new::h0cd287bced57cd41(skia_font=<unavailable>) at font_loader.rs:27
    frame #16: 0x000055555575637d neovide`neovide::renderer::fonts::font_loader::FontLoader::get_or_load::h465e793d50c5a128 at font_loader.rs:141:17
    frame #17: 0x0000555555755c4b neovide`neovide::renderer::fonts::font_loader::FontLoader::get_or_load::h465e793d50c5a128(self=0x00007fffffff8fc8, font_key=0x00007fffd40e4860) at font_loader.rs:163
    frame #18: 0x000055555581abef neovide`neovide::renderer::fonts::caching_shaper::CachingShaper::shape_cached::h3f1f1ed4703ed7fc at caching_shaper.rs:178:42
    frame #19: 0x00005555558162b7 neovide`neovide::renderer::fonts::caching_shaper::CachingShaper::shape_cached::h3f1f1ed4703ed7fc at caching_shaper.rs:233
    frame #20: 0x0000555555815b53 neovide`neovide::renderer::fonts::caching_shaper::CachingShaper::shape_cached::h3f1f1ed4703ed7fc(self=0x00007fffffff8fa8, cells=size=0, bold=false, italic=false) at caching_shaper.rs:278
    frame #21: 0x00005555557b25f0 neovide`neovide::window::window_wrapper::GlutinWindowWrapper::draw_frame::h46b1043dd65fc2b2 at mod.rs:194:21
    frame #22: 0x00005555557b20d9 neovide`neovide::window::window_wrapper::GlutinWindowWrapper::draw_frame::h46b1043dd65fc2b2 at rendered_window.rs:361
    frame #23: 0x00005555557b17d6 neovide`neovide::window::window_wrapper::GlutinWindowWrapper::draw_frame::h46b1043dd65fc2b2 at mod.rs:226
    frame #24: 0x00005555557ae76c neovide`neovide::window::window_wrapper::GlutinWindowWrapper::draw_frame::h46b1043dd65fc2b2 at mod.rs:278
    frame #25: 0x00005555557ae028 neovide`neovide::window::window_wrapper::GlutinWindowWrapper::draw_frame::h46b1043dd65fc2b2(self=0x00007fffffff8cd0, dt=2.66246708E-44) at mod.rs:183
    frame #26: 0x00005555557c78da neovide`neovide::window::window_wrapper::start_loop::_$u7b$$u7b$closure$u7d$$u7d$::h5e629bdb493485fb(e=<unavailable>, _window_target=<unavailable>, control_flow=0x00007fffffff8a58) at mod.rs:292:13
    frame #27: 0x000055555560ed2d neovide`winit::platform_impl::platform::wayland::event_loop::EventLoop$LT$T$GT$::run::h891ecfb027add525 at mod.rs:760:5
    frame #28: 0x000055555560ece0 neovide`winit::platform_impl::platform::wayland::event_loop::EventLoop$LT$T$GT$::run::h891ecfb027add525 at mod.rs:388
    frame #29: 0x000055555560dbcc neovide`winit::platform_impl::platform::wayland::event_loop::EventLoop$LT$T$GT$::run::h891ecfb027add525(self=EventLoop<()> @ 0x00007fffffff9450, callback=<unavailable>) at mod.rs:191
    frame #30: 0x00005555557c7558 neovide`winit::platform_impl::platform::EventLoop$LT$T$GT$::run::h9e03b7e6da455ff8(self=<unavailable>, callback=closure-0 @ 0x00007fffffffa0a8) at mod.rs:676:56
    frame #31: 0x00005555557be62c neovide`winit::event_loop::EventLoop$LT$T$GT$::run::hf796eba8c1e5cb74(self=<unavailable>, event_handler=<unavailable>) at event_loop.rs:154:9
    frame #32: 0x00005555557bd588 neovide`neovide::window::window_wrapper::start_loop::h6a221b2ffa95330c(batched_draw_command_receiver=Receiver<alloc::vec::Vec<neovide::editor::DrawCommand, alloc::alloc::Global>> @ 0x00007fffffffa978, window_command_receiver=Receiver<neovide::editor::WindowCommand> @ 0x00007fffffffa988, ui_command_sender=LoggingTx<neovide::bridge::ui_commands::UiCommand> @ 0x00007fffffffd2e0, running=<unavailable>) at mod.rs:275:5
    frame #33: 0x00005555557f1cec neovide`neovide::main::hf6004e134216c6f2 [inlined] neovide::window::create_window::h94e3928045b04ba1(batched_draw_command_receiver=<unavailable>, window_command_receiver=<unavailable>, running=strong=3, weak=0) at mod.rs:50:5
    frame #34: 0x00005555557f1caa neovide`neovide::main::hf6004e134216c6f2 at main.rs:198
    frame #35: 0x00005555557c2223 neovide`std::sys_common::backtrace::__rust_begin_short_backtrace::h08200308916b41c7 [inlined] core::ops::function::FnOnce::call_once::h32472cc38e97eb5d((null)=<unavailable>) at function.rs:227:5
    frame #36: 0x00005555557c2221 neovide`std::sys_common::backtrace::__rust_begin_short_backtrace::h08200308916b41c7(f=<unavailable>) at backtrace.rs:125
    frame #37: 0x00005555557ee161 neovide`main + 641
    frame #38: 0x00007ffff7924b25 libc.so.6`__libc_start_main + 213
    frame #39: 0x000055555560237e neovide`_start + 46

or

(lldb) bt
* thread #1, name = 'neovide', stop reason = signal SIGABRT
  * frame #0: 0x00007ffff7939d22 libc.so.6`raise + 322
    frame #1: 0x00007ffff7923862 libc.so.6`abort + 278
    frame #2: 0x000055555693fa37 neovide`std::sys::unix::abort_internal::hba19dccca7c1e209 + 7
    frame #3: 0x0000555556937df5 neovide`std::sys_common::util::abort::hdb6a53068e4d2b07 + 85
    frame #4: 0x00005555569381b1 neovide`__rust_foreign_exception + 65
    frame #5: 0x000055555694aa75 neovide`__rust_panic_cleanup + 69
    frame #6: 0x000055555570862d neovide`std::panicking::try::cleanup::h7034096a336683e6 + 13
    frame #7: 0x0000555556939658 neovide`std::rt::lang_start_internal::h4461fc58637f04f8 + 1128
    frame #8: 0x000055555576b240 neovide`std::rt::lang_start::hdf94a43163798a50(main=(neovide`neovide::main::h839e9e1586d46ccc at main.rs:48), argc=1, argv=0x00007fffffffd998) at rt.rs:48:5
    frame #9: 0x000055555578bb0c neovide`main + 28
    frame #10: 0x00007ffff7924b25 libc.so.6`__libc_start_main + 213
    frame #11: 0x0000555555709bfe neovide`_start + 46

(lldb) bt
* thread #10, name = 'neovide'
  * frame #0: 0x0000555555a79037 neovide`alloc::raw_vec::RawVec$LT$T$C$A$GT$::current_memory::h67f17ae05a29db8e(self=0x00007fffd40e00e0) at raw_vec.rs:0:23
    frame #1: 0x0000555555a79bab neovide`_$LT$alloc..raw_vec..RawVec$LT$T$C$A$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::h4fb6165240971428(self=0x00007fffd40e00e0) at raw_vec.rs:508:38
    frame #2: 0x0000555555a7a71b neovide`core::ptr::drop_in_place$LT$alloc..raw_vec..RawVec$LT$u8$GT$$GT$::h0dd4c97b70c1a1ba((null)=0x00007fffd40e00e0) at mod.rs:192:1
    frame #3: 0x0000555555a7a642 neovide`core::ptr::drop_in_place$LT$alloc..vec..Vec$LT$u8$GT$$GT$::h8c937fc114b2ea6f((null)=0x00007fffd40e00e0) at mod.rs:192:1
    frame #4: 0x0000555555a7a53b neovide`core::ptr::drop_in_place$LT$alloc..string..String$GT$::hfb094f9b48db56de((null)=0x00007fffd40e00e0) at mod.rs:192:1
    frame #5: 0x0000555555865837 neovide`core::ptr::drop_in_place$LT$$LP$alloc..string..String$C$core..option..Option$LT$alloc..sync..Arc$LT$neovide..editor..style..Style$GT$$GT$$RP$$GT$::h481b75071b966db5((null)=0x00007fffd40e00e0) at mod.rs:192:1
    frame #6: 0x0000555555866180 neovide`core::ptr::drop_in_place$LT$$u5b$$LP$alloc..string..String$C$core..option..Option$LT$alloc..sync..Arc$LT$neovide..editor..style..Style$GT$$GT$$RP$$u5d$$GT$::h1617de9ee81eb789((null)=*mut [(alloc::string::String, core::option::Option<alloc::sync::Arc<neovide::editor::style::Style>>)] @ 0x00007ffff65b0ed8) at mod.rs:192:1
    frame #7: 0x0000555555906072 neovide`_$LT$alloc..vec..Vec$LT$T$C$A$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::h02a80ec194b8d9e1(self=0x00007fffd4050ba0) at mod.rs:2667:13
    frame #8: 0x0000555555867313 neovide`core::ptr::drop_in_place$LT$alloc..vec..Vec$LT$$LP$alloc..string..String$C$core..option..Option$LT$alloc..sync..Arc$LT$neovide..editor..style..Style$GT$$GT$$RP$$GT$$GT$::h01ce64df7e920d31((null)=0x00007fffd4050ba0) at mod.rs:192:1
    frame #9: 0x00005555558705fe neovide`core::ptr::drop_in_place$LT$neovide..editor..grid..CharacterGrid$GT$::h0ca0385dd1ec8be8((null)=0x00007fffd4050b90) at mod.rs:192:1
    frame #10: 0x000055555586f1f7 neovide`core::ptr::drop_in_place$LT$neovide..editor..window..Window$GT$::h7f48955e4f1f3dad((null)=0x00007fffd4050b88) at mod.rs:192:1
    frame #11: 0x00005555558714ee neovide`core::ptr::drop_in_place$LT$$LP$u64$C$neovide..editor..window..Window$RP$$GT$::h9fff84150b0f7f4a((null)=0x00007fffd4050b80) at mod.rs:192:1
    frame #12: 0x000055555577081a neovide`core::ptr::mut_ptr::_$LT$impl$u20$$BP$mut$u20$T$GT$::drop_in_place::h8efcf45d4931a3c8(self=0x00007fffd4050b80) at mut_ptr.rs:995:18
    frame #13: 0x00005555559253dd neovide`hashbrown::raw::Bucket$LT$T$GT$::drop::h0d5461bbf00be821 + 29
    frame #14: 0x00005555559278ee neovide`hashbrown::raw::RawTable$LT$T$C$A$GT$::drop_elements::h4558c7a29e1af4a4 + 238
    frame #15: 0x000055555592309e neovide`_$LT$hashbrown..raw..RawTable$LT$T$C$A$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::h177b314864a42715 + 46
    frame #16: 0x000055555587630a neovide`core::ptr::drop_in_place$LT$hashbrown..raw..RawTable$LT$$LP$u64$C$neovide..editor..window..Window$RP$$GT$$GT$::hafa30dd3fe40038c((null)=0x00007ffff65b1160) at mod.rs:192:1
    frame #17: 0x000055555586575e neovide`core::ptr::drop_in_place$LT$hashbrown..map..HashMap$LT$u64$C$neovide..editor..window..Window$C$std..collections..hash..map..RandomState$GT$$GT$::h90943c12a8b42f8c((null)=0x00007ffff65b1150) at mod.rs:192:1
    frame #18: 0x0000555555862c7a neovide`core::ptr::drop_in_place$LT$std..collections..hash..map..HashMap$LT$u64$C$neovide..editor..window..Window$GT$$GT$::h5a48ef9b604fe5b5((null)=0x00007ffff65b1150) at mod.rs:192:1
    frame #19: 0x000055555586df33 neovide`core::ptr::drop_in_place$LT$neovide..editor..Editor$GT$::h9ab338d4cfcc13ea((null)=0x00007ffff65b1150) at mod.rs:192:1
    frame #20: 0x000055555572e30d neovide`neovide::editor::start_editor::_$u7b$$u7b$closure$u7d$$u7d$::h50122407489ca798 at mod.rs:454:5
    frame #21: 0x0000555555827f83 neovide`std::sys_common::backtrace::__rust_begin_short_backtrace::ha5b5b970243cecab(f=<unavailable>) at backtrace.rs:125:18
    frame #22: 0x000055555582947c neovide`std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::hb2298ae6df8a320f at mod.rs:481:17
    frame #23: 0x00005555558216a0 neovide`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::hb8c51ecd91996d7d(self=<unavailable>, _args=<unavailable>) at panic.rs:344:9
    frame #24: 0x000055555589db7a neovide`std::panicking::try::do_call::h46fdfdf433bde4f5(data="") at panicking.rs:379:40
    frame #25: 0x00005555558b852d neovide`__rust_try + 45
    frame #26: 0x000055555589be57 neovide`std::panicking::try::h5b64119d5bc5fbc3(f=<unavailable>) at panicking.rs:343:19
    frame #27: 0x0000555555828590 neovide`std::panic::catch_unwind::hdd55d4f080e892e6(f=<unavailable>) at panic.rs:431:14
    frame #28: 0x0000555555829279 neovide`std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::ha9319d9d53e61499 at mod.rs:480:30
    frame #29: 0x000055555586020e neovide`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hdc63cac8f2291501((null)=0x0000555559596d80, (null)=<unavailable>) at function.rs:227:5
    frame #30: 0x000055555693f47a neovide`std::sys::unix::thread::Thread::new::thread_start::hc238bac7748b195d + 42
    frame #31: 0x00007ffff7c16259 libpthread.so.0`start_thread + 233
    frame #32: 0x00007ffff79fb5e3 libc.so.6`__clone + 67

[dineshKumar777]

We don't even need a large file to reproduce this. Just gg and Shift+g increases memory usage.

https://user-images.githubusercontent.com/21097695/142765095-aebf758c-57f1-4f83-bee7-df9fdd6dff67.mp4

[fredizzimo]

Is anyone else still able to reproduce this? I tried it on my Windows 11 machine, and there does not seem to be a memory leak for me. Perhaps the issue has been resolved upstream?

[dineshKumar777]

@fredizzimo I can still reproduce this issue with latest build from source as mentioned above.

Memory leak is very specific to these cursor vfx "railgun" or "torpedo". I tested with railgun alone.

We don't even need a large file to reproduce this. Just gg and Shift+g increases memory usage.

cht1KMwkEl.mp4

[fredizzimo]

I was able to repeat it now, or at least almost.

But it's quite strange. I tried it manually, the memory actually went slightly down, when repeating around 10 times.

Then I recorded a macro, and repeated 100 times, the memory jumped around a bit, growing and then getting down again, but eventually it ended up at around 200MB, from 60MB when I started.

I tried manually again, after that, but the memory usage remained stable.

Then I tried repeating the macro 1000 times, for a long time it stayed stable at around 300, then jumped up, stayed reasonably stable, jumped up and so on. But I closed it at around 700MB, after it had been running for quite a while. It seems to get exponentially slower, since 100 times did not take long, but 1000 seems to take quite a while. So I guess there's some data structure that grows and makes things slower in addition to leaking memory

From these tests, my conclusion is that the problem is related to timing, perhaps a threading race condition.

[dineshKumar777]

@fredizzimo I am not sure but i can reproduce simply within ten steps just with gg and shift+g actions. NOTE: I use g.neovide_cursor_vfx_particle_density=25, which is higher than default.

Screen recording for reference.

https://user-images.githubusercontent.com/21097695/148085987-3f1ff2f9-d646-416b-baa6-9a6818239538.mp4

[fredizzimo]

Yes, I'm definitely not able to reproduce it that easily. I may be able to get to to increase very slightly in debug mode and spamming the keys, but that's just by a few megabytes at most.

I don't think it's an operating system issue, since you are on Windows, the original @s0hey1 seems to be on linux, judging from the callstack, and I'm on Windows 11. I also tried it through WSLg, and wasn't able to repeat it there either. And I tried both the release and debug version.

[fredizzimo]

I do notice something strange in the original call stack though. It seems to load a font, and I don't think that should happen unless you actually change the font, or when you encounter a new character so that the fallback font is used.

I don't have time to test it right now, but perhaps you could add some logging around that to verify?

[fredizzimo]

I managed to find time to do a quick test with the fonts.

Calling :set guifont= causes a memory leak of similar size per call. I don't know why the cursor effect would load any font though

[fredizzimo]

I tested some more with the fonts, and the :set guifont only seem to leak memory when specifying a non-nerd font based font, or very likely more specifically a font that's lacking some glyphs on the screen. Manually adding a fallback font is enough to make it not leak memory.

Anyway, that sounds like it should be a quite easy fix. But I still haven't managed to properly reproduce the cursor effect memory leak. @dineshKumar777 or someone else, could you provide the log file too? Maybe there's something in there that gives a clue of what's happening.

[dineshKumar777]

@fredizzimo neovide_rCURRENT.log

[fredizzimo]

I checked the log, and it does not seem to load any fonts, so that might be a different memory leak.

And comparing them to mine, I didn't see anything obvious, but there might be a clue TRACE [neovide::editor] viewport event received before window initialized. There's one of those for each of the G and gg. My log file also has some of the same messages, but not during scrolling.

[dineshKumar777]

@Kethku any idea or suggestions!!!

[Kethku]

Not sure! I'll have to look into it tomorrow. It's very late here.

[fredizzimo]

@dineshKumar777, since that's a multigrid event, could you try without multigrid, to see if it still leaks memory? But it's not as simple as multi-grid causing it, since I also have it enabled. Also more likely than not, the log message is not releated to the memory leak, but it's probably worth a shot.

[dineshKumar777]

@fredizzimo actually till now I didn't use multigrid.

[fredizzimo]

Yes, sorry for the confusion, it seems like neovim sends that event even if you don't have multi-grid enabled although the documentation says it's multigrid specific here https://neovim.io/doc/user/ui.html.

I tested without multigrid myself, and I get the same errors, but no memory leaks, so the error is unrelated like I suspected.

[fredizzimo]

It seems no matter what I do, I can't reproduce it here on my end. But after looking at the code I agree with @s0hey1, it looks like it's a bug inside skia and draw_oval. It should be easy enough to verify by changing this https://github.com/neovide/neovide/blob/main/src/renderer/cursor_renderer/cursor_vfx.rs#L355 to draw_rect instead of draw_oval. Can you test that @dineshKumar777?

Can you also verify that you have the same version of skia as I have in the Cargo.lock file

name = "skia-bindings"
version = "0.42.1"

[dineshKumar777]

@fredizzimo having same skiabinding version which you mentioned.

It seems draw_oval is the issue. Changing to draw_rect doesnt cause memory leak.

[unrooot]

This is also something that I experience (Windows 11). I can't seem to reproduce it consistently, but I did manage to get neovide to crash shortly after starting while running --log. Also, fwiw, use pixiedust with a density of 25.0.

neovide_rCURRENT.txt

[fredizzimo]

Ok, good.

There are a few newer versions of skia, which you could try by editing the Cargo.toml file. https://github.com/rust-skia/rust-skia/releases. Also you could check 'target\release\build\skia-bindings-2a29641b9acc3126\output', to see that the exact same version of the native skia is used Mine shows

**cargo:rerun-if-env-changed=SKIA_DEBUG
cargo:rerun-if-env-changed=SKIA_SOURCE_DIR
cargo:rerun-if-env-changed=FORCE_SKIA_BUILD
cargo:rerun-if-env-changed=FORCE_SKIA_BINARIES_DOWNLOAD
TRYING TO DOWNLOAD AND INSTALL SKIA BINARIES: 0.42.1/8b53a6e3e746b7456997-x86_64-pc-windows-msvc-gl
cargo:rerun-if-env-changed=SKIA_BINARIES_URL
  FROM: https://github.com/rust-skia/skia-binaries/releases/download/0.42.1/skia-binaries-8b53a6e3e746b7456997-x86_64-pc-windows-msvc-gl.tar.gz
UNPACKING ARCHIVE INTO: C:\proj\neovide\target\debug\build\skia-bindings-ce6a25a6ec4782eb\out\skia
INSTALLING BINDINGS
DOWNLOAD AND INSTALL SUCCEEDED
cargo:rustc-link-search=C:\proj\neovide\target\debug\build\skia-bindings-ce6a25a6ec4782eb\out\skia
cargo:rustc-link-lib=skia
cargo:rustc-link-lib=skia-bindings
cargo:rustc-link-lib=usp10
cargo:rustc-link-lib=ole32
cargo:rustc-link-lib=user32
cargo:rustc-link-lib=gdi32
cargo:rustc-link-lib=fontsub
cargo:rustc-link-lib=opengl32**

[dineshKumar777]

@fredizzimo my output is same as yours. Issue is reproducible in latest 0.45.1 skia too.

[fredizzimo]

That's bad news :(

What graphics card do you have? I saw that skia takes slightly different code paths depending on the graphics card. I have an RTX 3060 here.

[dineshKumar777]

@fredizzimo I am using in laptop which have intel integrated graphics

---

Display Devices

       Card name: Intel(R) UHD Graphics
    Manufacturer: Intel Corporation
       Chip type: Intel(R) UHD Graphics Family
        DAC type: Internal
     Device Type: Full Device (POST)
      Device Key: Enum\PCI\VEN_8086&DEV_9B41&SUBSYS_507A17AA&REV_02
   Device Status: 0180200A [DN_DRIVER_LOADED|DN_STARTED|DN_DISABLEABLE|DN_NT_ENUMERATOR|DN_NT_DRIVER] 

Device Problem Code: No Problem Driver Problem Code: Unknown Display Memory: 8224 MB Dedicated Memory: 128 MB Shared Memory: 8096 MB Current Mode: 1920 x 1080 (32 bit) (59Hz)

[fredizzimo]

That could be the difference then. But I guess we need more testers with different hardware.

[fredizzimo]

After some thought, I think the best way forward with this, is to make a minimal example program, which doesn't do anything else than drawing ovals using skia, to see if the issue occurs with that as well. I won't do that myself, since I rather concentrate on other things, but someone with good Rust knowledge can probably do it in an hour or so.

If that example has problems it could be sent upstream, and hopefully fixed there.

[Kethku]

I can throw something like this together pretty quickly sometime soon. Thanks for the in depth investigation

[Borwe]

Yeah experiencing same problem on latest master still. I noted it mostly has to do with the cursor movement. EG in normal mode: Shitft-G // to go to top : //to enter command mode Esc //to exit command mode

Repeat and memory keeps growing. Windows 10

[fredizzimo]

We still need an example program if someone is interested in doing that. Perhaps it even happens here https://fiddle.skia.org/?

After that we should determine which hardware it occurs on, and send a bug report to https://issues.skia.org/issues?q=status:open

[fredizzimo]

It looks like the issue is restricted to the integrated intel GPUs. So, I suggest that anyone with the problem try to update their drivers and see if that fixes the issue.

[MOldtime]

Updating the graphics card currently cannot solve the problem. It seems that we can only wait until later.

[MOldtime]

Intel ARC A770 also has this problem. It seems that as long as it is Intel, there is a problem

[fredizzimo]

@MOldtime, can you try to create a fiddle in https://fiddle.skia.org that does some animation using a lot of draw_oval? And see if you see a memory leak there too? If that's the case we have something to report to skia.

If not then we might have to create an example using the raw c++ version of skia.

But I think we have tracked it down to draw_oval at this point already.

[fredizzimo]

It's possible that it does not happen though, since the browser version of skia is using Angle, which wraps opengl inside Direct3D, and the bug might be in just the Windows opengl implementation.

But we might move to Direct3D on Windows for Neovide, so that might also fix it.

[MOldtime]

@MOldtime, can you try to create a fiddle in https://fiddle.skia.org that does some animation using a lot of draw_oval? And see if you see a memory leak there too? If that's the case we have something to report to skia.

If not then we might have to create an example using the raw c++ version of skia.

But I think we have tracked it down to draw_oval at this point already.

I am not familiar with SKIA, I don’t know if it is effective. It seems that the memory has not changed much Firefox browser used

void draw(SkCanvas* canvas) {

    for (int i = 0; i < 100000; i++) {
        SkPaint p;
        p.setColor(SK_ColorRED);
        p.setAntiAlias(true);
        p.setStyle(SkPaint::kStroke_Style);
        p.setStrokeWidth(10);
        canvas->drawLine(20, 20, 100, 100, p);
    }
}

[fredizzimo]

I think it needs some kind of animation, which can be enabled in the options, with a canvas clear for each frame.

But I don't know exactly how that should be done, and how you wait for the new frame. I can try it later at some point if you don't figure out how.

[MOldtime]

I tried it and made animations. I needed to introduce head files, but I don’t know the path of the file. I can’t find the file

[MOldtime]

Thanks for the repair, this branch solved the problem Test equipment: intel Arc a770 https://github.com/neovide/neovide/pull/2215

[Arakade]

Came here as a new Neovide user investigating memory leaks. Currently looking at 6.1GB on a Nvidia 3080 Ti Laptop 😢 Open help, ctrl-F and B to scroll up and down a few times, now 7.1GB 😱 (the spike on right in this image)

I must admit I'm mainly using Neovide cuz I fell in love with Railgun effect 😊 (so cool) Using Railgun (default settings). Disabling stops the leak. Nvidia driver 551.61. External monitor (where Neovide running) 2560x1600. Win 11. Intel 12'th gen CPU. Asus laptop.

Will @fredizzimo 's #2215 PR likely help? If so, any update on when it might land? (wondering if I should invest in trying to build locally?) If not, LMK other info I can provide to help diagnose! Thx

[fredizzimo]

@Arakade, I don't think there should be a memory leak with your graphics card, so it likely won't help, although I might be wrong. But for older graphics card it should.

But are you checking the memory usage of just Neovide or the whole process tree of Neovide? Because Neovim, well actually the language servers can easily use several GB of memory.

[Arakade]

@Arakade, I don't think there should be a memory leak with your graphics card, so it likely won't help, although I might be wrong. But for older graphics card it should.

Oh. boo.

Because Neovim, well actually the language servers can easily use several GB of memory.

...from paging up and down with railgun enabled vs it being fine without it enabled? Figured that was more of a front-end thing?

But are you checking the memory usage of just Neovide or the whole process tree of Neovide?

I'm using Process Explorer which I'm pretty sure measures the selected process (not sub processes). Regardless am I right thinking I should be able to isolate them by running a NeoVim server and directing Neovide to attach to it then measuring the latter only? I'll try that in a bit. (presume won't make a difference whether TCP / Win pipe, right?)

DIY Build

I just tried building your fork. Getting compile errors but quite likely some naive fault on my side. Maybe you can spot my mistake? I followed instructions here. Wasn't sure what I should do for (4) in that list so could believe graphics libraries might be out of date. (might be good to update to provide pointers for noobs like me 😁)

Admin console:

choco install cmake --installargs '"ADD_CMAKE_TO_PATH=System"' -y
choco install llvm -y

User console:

rustup update
cargo install --git https://github.com/fredizzimo/neovide.git

Attached build log. neovide-build-01.log Any ideas?

error[E0432]: unresolved import `tokio_util::compat`
  --> src\bridge\create.rs:17:17
   |
17 | use tokio_util::compat::TokioAsyncReadCompatExt;
   |                 ^^^^^^ could not find `compat` in `tokio_util`

p.s. Thanks so much for taking the time to reply before! 👍

[Arakade]

Definitely front-end and definitely railgun.

Ran with separate process per the instructions. Graphing memory on Neovide only, paging up and down with ctrl-F and B. First flatish line is with railgun disabled. The steep slope is where I enabled it.

HTH

[fredizzimo]

@Arakade, you need to specify the branch when installing too, so cargo install --git https://github.com/fredizzimo/neovide.git --branch 'fsundvik/d3d'

[Arakade]

@Arakade, you need to specify the branch when installing too, so cargo install --git https://github.com/fredizzimo/neovide.git --branch 'fsundvik/d3d'

Ahha, yep, that'd make sense. Aaaaannnd, it builds aaaaannnnnnd, it fixes it! 🎉 (well either this does or some factor I'm not controlling for -- I haven't built main branch to be 100% certain but assuming dependencies are controlled for, it's a good bet.)

Yes, the usual test:

The orange arrow is where I enabled railgun and continued my insane paging up and down. (the first plateau is start, next is after opening help cursor (my usual test file for some reason).

So I'd say the sooner this gets merged the better! Thx for your help. I'll be using my own-built version of your fork for now 👍