Project

General

Profile

Bug #3197

nwam-manager leaks memory; causes swapping hell.

Added by Nick Zivkovic about 7 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
2012-09-15
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

The nwam manager leaks memory and causes swapping hell. Output from mdb (with libumem pre-loaded) is attached.

I used `findleaks -dfv`

This can observed on OI-151a, by using mdb and umem to hook into the nwam-manager process and using the findleaks command.

As for reproducing, use WiFi and nwam-manager.


Files

nwam_leak (2.02 KB) nwam_leak Nick Zivkovic, 2012-09-15 11:21 PM

History

#1

Updated by Milan Jurik about 7 years ago

  • Status changed from New to Feedback

I do not see any significant leak from the report. Could you provide gcore of that process?

#2

Updated by Nick Zivkovic about 7 years ago

The core file that I have is 214M in size (attachments are limited to 4M).

Also, it is not the same one that was used to get the first report.

And, the first report was done only after the leak had caused swapping hell and forced me to reboot the system.

Strangely, I have not been able to reproduce the swapping hell, yet.

Either way, the process is currently 213M in size, which is a little... excessive.

PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
29671 nickziv 380M 285M sleep 39 0 0:10:45 2.8% firefox-bin/11
27965 nickziv 213M 213M sleep 59 0 0:07:14 0.1% nwam-manager/3
18455 nickziv 354M 100M sleep 59 0 0:07:09 0.2% Xorg/3
26731 root 87M 84M sleep 59 0 0:01:22 0.0% mdb/1
18589 nickziv 129M 60M sleep 49 0 0:00:07 0.0% nautilus/2
18588 nickziv 108M 44M sleep 59 0 0:00:03 0.0% gnome-panel/1
18605 nickziv 54M 34M sleep 12 19 0:00:05 0.0% updatemanagerno/1
#3

Updated by Enrico Papi about 7 years ago

Hi Nick,
i probably know the source of the problem.
It can be for my #405 workaround in illumos-gate which might have required some changes to nwam-manager too. This can happen when you switch to 151a6 and you don't have an empty known-wlan.conf in /etc/nwam/

I'm busy in my spare time in rewriting nwam-manger to support all the changes to the wifi stack done in illumos-gate during the gsoc problem.

If someone does not consider this of high priority i'll focus on my nwam-manager development for now which would solve many current issues.

#4

Updated by Nick Zivkovic about 7 years ago

Here is a more drastic prstat

PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
21643 nickziv 375M 317M sleep 59 0 0:17:15 0.3% nwam-manager/3
618 nickziv 399M 311M sleep 35 0 0:47:28 2.4% firefox-bin/11
1189 nickziv 425M 167M sleep 59 0 0:35:23 0.4% Xorg/3
19733 nickziv 141M 83M sleep 49 0 0:00:03 0.0% evince/4
1531 nickziv 116M 56M sleep 49 0 0:00:14 0.0% nautilus/2
1541 nickziv 57M 39M sleep 12 19 0:00:20 0.0% updatemanagerno/1
1528 nickziv 90M 36M sleep 59 0 0:00:04 0.0% gnome-panel/1
1556 nickziv 87M 23M sleep 59 0 0:00:08 0.0% clock-applet/1
1538 nickziv 80M 22M sleep 59 0 0:00:11 0.0% gnome-power-man/1
1540 nickziv 81M 22M sleep 59 0 0:00:18 0.0% isapython2.6/1
1558 nickziv 80M 21M sleep 59 0 0:00:26 0.0% mixer_applet2/3
1544 nickziv 32M 21M sleep 59 0 0:00:00 0.0% isapython2.6/1
1535 nickziv 78M 20M sleep 59 0 0:03:24 0.0% wnck-applet/1
1522 nickziv 28M 19M sleep 59 0 0:00:03 0.0% gnome-settings-/1
1537 nickziv 77M 19M sleep 59 0 0:00:00 0.0% trashapplet/1
12767 nickziv 75M 19M sleep 59 0 0:00:00 0.0% notification-da/1
1527 nickziv 74M 18M sleep 59 0 0:00:37 0.0% metacity/1
21397 nickziv 26M 18M sleep 12 19 0:00:02 0.0% trackerd/2
4704 nickziv 23M 16M sleep 12 19 0:00:00 0.0% tracker-indexer/1
597 root 22M 15M sleep 59 0 0:00:09 0.0% fmd/27
1559 nickziv 24M 14M sleep 59 0 0:00:24 0.0% notification-ar/1
1467 nickziv 18M 11M sleep 59 0 0:00:02 0.0% gnome-session/3
12 root 11M 10M sleep 59 0 0:08:18 0.0% svc.configd/16
1587 nickziv 13M 8400K sleep 59 0 0:04:07 0.0% xterm/1
7051 nickziv 13M 8344K sleep 49 0 0:00:01 0.0% xterm/1
1672 root 9276K 7948K sleep 59 0 0:03:12 0.0% nwamd/11
1622 nickziv 13M 7788K sleep 49 0 0:00:00 0.0% xterm/1
1516 nickziv 9448K 7552K sleep 59 0 0:00:57 0.0% gconfd-2/1
614 root 10M 6744K sleep 59 0 0:00:02 0.0% rad/5
620 root 7620K 6492K sleep 59 0 0:00:22 0.0% intrd/1
1533 nickziv 9128K 6464K sleep 59 0 0:00:02 0.0% bonobo-activati/3
26234 nickziv 11M 6252K sleep 59 0 0:00:00 0.0% gvfsd-http/1
1547 nickziv 9004K 6208K sleep 59 0 0:00:13 0.0% xscreensaver/1
10 root 8132K 6124K sleep 59 0 0:01:36 0.0% svc.startd/12
446 root 7328K 5988K sleep 59 0 0:00:09 0.0% hald/5
23150 nickziv 9720K 5916K cpu0 59 0 1:34:37 0.4% prstat/1
317 root 11M 5748K sleep 59 0 0:00:00 0.0% cupsd/1
1530 nickziv 9108K 5692K sleep 59 0 0:00:03 0.0% gvfs-hal-volume/3
1543 nickziv 8772K 5372K sleep 59 0 0:00:00 0.0% gvfsd-trash/1
1524 nickziv 8336K 5260K sleep 59 0 0:00:02 0.0% gnome-keyring-d/6
1526 nickziv 8296K 4756K sleep 59 0 0:00:00 0.0% gvfsd/1
9055 nickziv 8356K 4456K sleep 59 0 0:00:00 0.0% gvfsd-metadata/1
1456 root 5672K 4380K sleep 59 0 0:00:00 0.0% gdm-session-wor/2
1188 root 6188K 4372K sleep 59 0 0:00:00 0.0% gdm-simple-slav/2
48 netcfg 5292K 4100K sleep 59 0 0:02:04 0.0% netcfgd/6
19731 nickziv 6364K 3980K sleep 59 0 0:00:00 0.0% evinced/1
7056 nickziv 6424K 3888K sleep 59 0 0:00:00 0.0% ksh/1
1623 nickziv 6412K 3832K sleep 59 0 0:00:00 0.0% ksh/1
1588 nickziv 6412K 3832K sleep 59 0 0:00:00 0.0% ksh/1
524 root 6404K 3672K sleep 59 0 0:00:02 0.0% inetd/4
13774 root 5692K 3596K sleep 59 0 0:00:00 0.0% nscd/18
NPROC USERNAME SWAP RSS MEMORY TIME CPU
47 nickziv 1006M 1111M 27% 3:26:24 3.5%
47 root 72M 84M 2.1% 0:55:08 0.1%
1 netcfg 2892K 5052K 0.1% 0:02:04 0.0%
1 netadm 1144K 3956K 0.1% 0:00:03 0.0%
1 smmsp 1400K 5048K 0.1% 0:00:00 0.0%
1 daemon 1000K 2864K 0.1% 0:00:00 0.0%
1 gdm 304K 3516K 0.1% 0:00:00 0.0%

Here we are using MORE memory than firefox with 26 tabs open, no flash, no java plugins.

This is a rather severe memory leak.

A quick work around that I'm using is to `kill -9` nwam-manager. This results in the system automatically starting a new instance with reduced memory usage (typically 91M).

I've deleted the text in /etc/nwam/known-wlan.conf. I'll see how that works out.

Thanks.

#5

Updated by Milan Jurik about 7 years ago

Well, it says something inside nwam-manager is consuming memory. But we need to know what - if you preload libumem and provide gcore after sometime it is running I can look at it. Please, contact me directly, I will give you some space where you can upload the gcore file.

#6

Updated by Ken Mays almost 7 years ago

  • Assignee set to Milan Jurik
#7

Updated by Ken Mays over 6 years ago

  • Assignee changed from Milan Jurik to OI JDS
#8

Updated by Ken Mays almost 6 years ago

  • Assignee changed from OI JDS to Milan Jurik
#9

Updated by Serghei Samsi almost 6 years ago

Hello Nick,
Please add the line
env LD_PRELOAD=/lib/libumem.so UMEM_DEBUG=default UMEM_LOGGING=transaction
before nwamd binary in SMF method file net-physical
Then restart nwamd.
After 10 minutes run gcore <NWAMD_PID>
After 2 hours run gcore <NWAMD_PID>
Both gcore files attach to the Issue.

Thanks,
Serghei

#10

Updated by Ken Mays over 5 years ago

  • Status changed from Feedback to Closed
  • Assignee changed from Milan Jurik to Ken Mays
  • % Done changed from 0 to 100

Tested for hipster-070114. Issue resolved.
Reviewed both nwamd and nwam-manager over a 30 minute session using
prstat and Firefox 17.0.11ESR. No major memory leak increases beyond 1-3 megs after FF activation.

Also available in: Atom PDF