Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#47668 - [linux] 4.3.3-2: Regression, Memory leak while browsing
Attached to Project:
Arch Linux
Opened by Florian Beverborg (Crazyachmed) - Friday, 08 January 2016, 09:55 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 02 October 2017, 23:04 GMT
Opened by Florian Beverborg (Crazyachmed) - Friday, 08 January 2016, 09:55 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 02 October 2017, 23:04 GMT
|
DetailsDescription: After upgrade there is a memory leak when using Chromium or Firefox (and possilby other things). Reverting the kernel to 4.2.5-1 fixes the issue.
Additional info: * GPU is NVIDIA Corporation G86 [Quadro NVS 290] * xorg-server 1.18.0-3 * Happens with nvidia-340xx (within minutes to an hour) or nouveau (within some hours) * At some point the OoM-Killer reaps the browser, but that actually does not free that much memory (the browsers are obviously the "largest" processes in my session) * At some point the memory is exhausted enough that xorg hangs and I have to power cycle. How can I see where the memory is allocated in kernel? There is no process actually allocating excessive RAM (according to htop and ps) Steps to reproduce: * Open Chromium, Chrome or Firefox to random sites and wait (even with locked screen and no interaction) |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Monday, 02 October 2017, 23:04 GMT
Reason for closing: Fixed
Additional comments about closing: fixed for OP with linux 4.4.1-2
Monday, 02 October 2017, 23:04 GMT
Reason for closing: Fixed
Additional comments about closing: fixed for OP with linux 4.4.1-2
To look for a clue take meminfo, ps, etc snapshots at time intervals while browsing:
$ cat /proc/meminfo
$ firefox &
$ cat /proc/meminfo
etc
Use valgrind:
$ valgrind firefox
but it would be better to recompile firefox with debug option -g and then use valgrind.
systemctl isolate multi-user.target
rmmod nvidia_modeset nvidia drm
then type:
free
You will need to modprobe nvidia nvidia-modeset before restarting Xorg.
Anyhow, I switched back to kernel 4.3 and took the output of "date;free;cat /proc/meminfo" three times. Used (not cached!) RAM usage was about 80% in the file meminfo3. For meminfo4 I switched to multi-user.target with no real effect (of course some RAM is freed because there are much less processes). The file meminfo5 was taken after "echo 0 > /sys/class/vtconsole/vtcon1/bind; rmmod nouveau", also with no noticable change. Also there is the output from "ps aux" from that point.
Anything else I can unload or take a look at?
...
DirectMap4k: 111180 kB
DirectMap2M: 5908480 kB
DirectMap1G: 3145728 kB <---------------
Next, you may want to compare IPC data (from good and bad kernel runs, with the same user space environment):
$ lsipc
$ ipcs
Next, have you tried to eliminate graphics driver as a cause ?
Add /etc/X11/xorg.conf.d/xorg.conf and restart Xorg server.
Section "Device"
Identifier "Configured Video Device"
Driver "vesa"
EndSection
Verify:
$ free
$ cat /proc/meminfo
$ lsipc
$ ipcs
etc
* linux 4.3.3-2
* xf86-video-intel 1:2.99.917+519+g8229390-1
* xorg-server 1.18.0-4
The freezing issue never happened prior to linux-4.2.1, though it gets extremely more often since the latest kernel upgrade (linux 4.3.3-2). It already happened to me like 3 times. Not sure if it's related to memory leak, though.
mem-4.2 is from kernel 4.2 after boot
mem-4.3 same for 4.3
mem-4.3_5 is after 3.5h of uptime (leak here)
$ ps -e -orss=,args= | sort -b -k1,1n
So far I can confirm the following:
- Issue independent of graphics driver (nvidia, nouveau or vesa)
- No issue when starting with "init=/bin/sh"
- No issue when starting with option "single"
- Issue present when starting lightdm without logging in
- I still don't now where the memory "goes"
If I reboot the computer and immediately do 'systemctl isolate rescue.target', I see around 70MB memory usage.
If I go back to graphical target for 12 hours and back to rescue.target, clear /tmp, memory usage is around 90MB.
It increases by 20 MB per 24 hours after that.
Going to rescue.target and running systemctl daemon-rexec and systemctl restart systemd-timesyncd, systemd-udevd, systemd-journald free ~2MB so the main leak is in the kernel.
plugging in my phone to a usb port on the computer seems to add to those memory leaks.
rmmod nvidia_modeset nvidia drm and modprobing them again isn't freeing any memory.
I am pretty sure kernel 4.2.x didn't have those issues.
only 4.3 and 4.4 seem to be affected.
> - Issue present when starting lightdm without logging in
This DM and its lightdm-[gtk|kde]-greeter have a history of causing memory leaks:
https://forums.gentoo.org/viewtopic-p-7865050.html?sid=808a147dd090b6d701f24d52ea9fb98a
I would suggest you test with:
1. a different display manager/greater
2. without display manager/greater, i.e. reconfigure your systemd to start with text tty, login, and startx.
Ref: Google search: lightdm memory leak
Bus 002 Device 005: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
(pulling it and unloading its modules does not free RAM)
Let me try that tomorrow with kernel 4.4
I don't have networkmanager.