Bug#964755: i3: Memory leak consumes all available memory
And can you test with any other window manager (e.g. awesome, dwm, wmii) to see if the issue really is i3 specific please? On Thu, Jul 23, 2020 at 3:05 AM Gabriel Krisman Bertazi wrote: > > Michael Stapelberg writes: > > > Is this fixed with commit > > https://github.com/i3/i3/commit/025743eaf9c993e57c7fdd20127078b835bcd2c0 > > already (not yet released)? Or are we talking about a separate leak? > > Sorry for the delay. > > I built the 4.18 package with this patch, and have been running it for > the past 3 days. The issue persists: > > ❯ ps -o etime= $(pidof Xorg) > 3-05:34:11 > > root@dilma:/home/krisman/src/i3-wm-4.18# cat /proc/$(pidof Xorg)/status | > grep Vm > VmPeak: 5488804 kB > VmSize: 5471796 kB > VmLck: 0 kB > VmPin: 0 kB > VmHWM: 4507732 kB > VmRSS: 4507732 kB > VmData: 4516956 kB > VmStk: 132 kB > VmExe: 1580 kB > VmLib:116212 kB > VmPTE: 9480 kB > VmSwap: 556 kB > > xrestop doesn't seem bad: > > xrestop - Display: localhost > Monitoring 33 clients. XErrors: 0 > Pixmaps: 102802K total, Other: 56K total, All: 102858K total > > The top entry in xrestop, in particular: > res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier > 04049 911 43 41256925K 13K 56938K ? i3 > > Pixmaps is not increasing over time, even though the overall xorg memory > is. > > -- > Gabriel Krisman Bertazi -- Best regards, Michael
Bug#964755: i3: Memory leak consumes all available memory
Michael Stapelberg writes: > Is this fixed with commit > https://github.com/i3/i3/commit/025743eaf9c993e57c7fdd20127078b835bcd2c0 > already (not yet released)? Or are we talking about a separate leak? Sorry for the delay. I built the 4.18 package with this patch, and have been running it for the past 3 days. The issue persists: ❯ ps -o etime= $(pidof Xorg) 3-05:34:11 root@dilma:/home/krisman/src/i3-wm-4.18# cat /proc/$(pidof Xorg)/status | grep Vm VmPeak: 5488804 kB VmSize: 5471796 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 4507732 kB VmRSS: 4507732 kB VmData: 4516956 kB VmStk: 132 kB VmExe: 1580 kB VmLib:116212 kB VmPTE: 9480 kB VmSwap: 556 kB xrestop doesn't seem bad: xrestop - Display: localhost Monitoring 33 clients. XErrors: 0 Pixmaps: 102802K total, Other: 56K total, All: 102858K total The top entry in xrestop, in particular: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 04049 911 43 41256925K 13K 56938K ? i3 Pixmaps is not increasing over time, even though the overall xorg memory is. -- Gabriel Krisman Bertazi
Bug#964755: i3: Memory leak consumes all available memory
Michael Stapelberg writes: > Is this fixed with commit > https://github.com/i3/i3/commit/025743eaf9c993e57c7fdd20127078b835bcd2c0 > already (not yet released)? Or are we talking about a separate leak? I'm not sure. I wasn't aware of this commit but it sounds very promising. Let me give it some test and report back. -- Gabriel Krisman Bertazi
Bug#964755: i3: Memory leak consumes all available memory
Is this fixed with commit https://github.com/i3/i3/commit/025743eaf9c993e57c7fdd20127078b835bcd2c0 already (not yet released)? Or are we talking about a separate leak? On Fri, Jul 10, 2020 at 3:03 AM Gabriel Krisman Bertazi wrote: > > Package: i3 > Version: 4.18-1 > Severity: important > > Dear Maintainer, > > I've seen my xorg grow in memory usage through the course of the day, > until it consumes all RAM available and starts swapping, even when the > machine is left idle. This is 100% reproducible on my system, after > killing X and restarting it, it starts to eat memory again. > > I'm reporting this against i3 instead of xorg, because I found other > Debian derivative users reporting this issue against i3, and it doesn't > seem to reproduce on other X based WM. > > I reproduced this on a machine after a fresh install of bullseye, with > the package version below. > > In my system, it is taking around 1 day to fill up 10GB of RAM. > > I'm happy to apply patches and test packages you provide to help debug > this. > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), > LANGUAGE=en_CA:en (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages i3 depends on: > ii i3-wm 4.18-1 > > Versions of packages i3 recommends: > ii dunst 1.4.1-1 > ii i3lock 2.11.1-1 > ii i3status2.13-3 > ii suckless-tools 45-1 > > i3 suggests no packages. > > -- no debconf information -- Best regards, Michael -- Best regards, Michael
Bug#964755: i3: Memory leak consumes all available memory
Package: i3 Version: 4.18-1 Severity: important Dear Maintainer, I've seen my xorg grow in memory usage through the course of the day, until it consumes all RAM available and starts swapping, even when the machine is left idle. This is 100% reproducible on my system, after killing X and restarting it, it starts to eat memory again. I'm reporting this against i3 instead of xorg, because I found other Debian derivative users reporting this issue against i3, and it doesn't seem to reproduce on other X based WM. I reproduced this on a machine after a fresh install of bullseye, with the package version below. In my system, it is taking around 1 day to fill up 10GB of RAM. I'm happy to apply patches and test packages you provide to help debug this. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages i3 depends on: ii i3-wm 4.18-1 Versions of packages i3 recommends: ii dunst 1.4.1-1 ii i3lock 2.11.1-1 ii i3status2.13-3 ii suckless-tools 45-1 i3 suggests no packages. -- no debconf information
