ForceSensorCapture with QueueDraw X11 bug!. Was: Cairo Memory leak on KDE neon (Plasma)
XaviB computer and MSI computer have KDE neon (plasma) on force sensor capture, computer memory is eaten. The strange thing is top is not associating that memory to Chronojump
on MSI mem is ok when using 2.3.0cherry (gtk2) But is not ok on master (gtk3)
Tried thinks that do not work (leak persist)
- Updating mono from 6.8.0.105+dfsg.3.2 to 6.12.0.182-0xamarin1+ubuntu2004b1
- apt-dist upgrade
- on initGraph do not change font
- do not draw nothing, just initGraph and dispose
- call GC.Collect (); GC.WaitForPendingFinalizers();
- call surface.Dispose (); instead of hardDisposeSurface (surface);
- g = null;
- using xfce4 the problem still persists
- MONO_THREADS_PER_CPU=200 chronojump does not worked. https://stackoverflow.com/a/75616327
Leak is fixed if:
- do not execute initGraph
Wayland vs X11: Is not related to Wayland as my Debian11 uses Wayland and the two KDE neon: no. Tried Wayland on MSI machine, but all the desktop is just a black screen
On Chromebook works as expected.
Comparisons:
- checking GC.GetTotalMemory() at start and end of endGraphDisposing, it is more or less the same
- GC.GetTotalMemory() for a 60 s capture starts at 9788 ends at 11586 on my computer and MSI, so the same approx, BUT on the MSI lot more memory is used by the app for some reason.
- According to top on MSI, before start cj: 13650; then 13450, capture starts 13000, capture ending (60s): 6600
- According to top on my laptop, before start cj: 2045; then 1940, capture starts 1930, capture ending (60s): 1924
- making the pointsToCopy list = null after the DoSendingList (also not worked)
more tests:
- apt-install mono-profiler
- but on creation of profile: cd bin; mono --profile=log Chronojump.exe (the log is created but it is truncated on reading by: emveepee, mprof-decoder, mprof-heap-viewer
- installed mono-utils (to have: mprof-report), with that do: mono --profile=log:report Chronojump.exe > report.txt and we have the report, but is more or less the same.
Top shows how free moemory goes down, but used memory is stable, what increases a lot is buffer/cache
On the MSI (mono 6.12) and XaviP (mono 6.8) computer, according to free -m, at 120s aprox swap is started using. available goes down since the beginning, buff/cache goes up, ... let's inspect better the code to find the leak. On my computer (mono 6.12) this never happens