http://defect.opensolaris.org/bz/show_bug.cgi?id=10225
Anurag S. Maskey <Anurag.Maskey at Sun.COM> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ACCEPTED |CLOSED
Resolution| |FIXINBUILD
--- Comment #2 from Anurag S. Maskey <Anurag.Maskey at Sun.COM> 2009-08-10
13:28:56 ---
The MMAP leaks still seen in nwamd (and also netcfgd) are false positive.
Thanks for Rao Shoaib for taking time to look at the code and processes. Below
is his analysis:
Rao Shoaib wrote:
> I have gone through the code and have verified that the memory leaks seen are
> not real memory leaks. The short answer is in the email threads that I have
> attached.
>
> I did verify that the memory is being allocated by the door threads so the
> issue mentioned in the thread is same as yours.
>
> ps -aef | grep netcfgd
> netcfg 14877 1 0 02:52:41 ? 0:00 /lib/inet/netcfgd.orig
> unknown# mdb -p 14877
> Loading modules: [ ld.so.1 libumem.so.1 libnvpair.so.1 ]
> > ::findleaks -dv
> findleaks: maximum buffers => 115
> findleaks: actual buffers => 24
> findleaks:
> findleaks: potential pointers => 286511
> findleaks: dismissals => 265636 (92.7%)
> findleaks: misses => 16898 ( 5.8%)
> findleaks: dups => 3954 ( 1.3%)
> findleaks: follows => 23 ( 0.0%)
> findleaks:
> findleaks: peak memory usage => 57 kB
> findleaks: elapsed CPU time => 0.0 seconds
> findleaks: elapsed wall time => 0.0 seconds
> findleaks:
> BYTES LEAKED VMEM_SEG CALLER
> 8192 1 d1066000 MMAP
> ------------------------------------------------------------------------
> Total 1 oversized leak, 8192 bytes
>
> mmap(2) leak: [d1066000, d1068000), 8192 bytes
>
> According to pmap this address is an anonymous segment.
>
> unknown# pmap 14877
> 14877: /lib/inet/netcfgd.orig
> 08046000 8K rw--- [ stack ]
> 08050000 8K r-x-- /lib/inet/netcfgd.orig
> 08062000 4K rw--- /lib/inet/netcfgd.orig
> 08063000 448K rw--- [ heap ]
> D0CE0000 36K r-x-- /lib/libnvpair.so.1
> D0CF9000 4K rw--- /lib/libnvpair.so.1
> D0D00000 624K r-x-- /lib/libnsl.so.1
> D0DAC000 16K rw--- /lib/libnsl.so.1
> D0DB0000 20K rw--- /lib/libnsl.so.1
> D0EBE000 4K rw--R [ stack tid=4 ]
> D0EC0000 16K r-x-- /lib/libsecdb.so.1
> D0ED4000 4K rw--- /lib/libsecdb.so.1
> D0EE0000 64K rwx-- [ anon ]
> D0FEF000 4K rw--R [ stack tid=3 ]
> D1066000 8K rw--R [ anon ]
> ^^^^^^^^^^^^^^^^^
> D1069000 536K rw--R [ stack tid=2 ]
> D10F0000 100K r-x-- /lib/libumem.so.1
> D1119000 20K rw--- /lib/libumem.so.1
> <....>
>
> If we look at the process segments via kernel mdb[1] we see that this address
> is part of the mmap segment starting at address d0ff1000 of size 1016k.
>
> > ::pgrep netcfgd
> S PID PPID PGID SID UID FLAGS ADDR NAME
> R 14877 1 14876 14876 17 0x42020000 dd0928b8 netcfgd.orig
> > dd0928b8::pmap
> SEG BASE SIZE RES PATH
> d7592900 08046000 8k 8k [ anon ]
> dcb6d188 08050000 8k /lib/inet/netcfgd.orig
> e67b3740 08062000 4k 4k /lib/inet/netcfgd.orig
> d930fb90 08063000 448k 428k [ anon ]
> df789400 d0ce0000 36k /lib/libnvpair.so.1
> d930f450 d0cf9000 4k 4k /lib/libnvpair.so.1
> ecfbf1c0 d0d00000 624k /lib/libnsl.so.1
> dcb6d708 d0dac000 16k 16k /lib/libnsl.so.1
> d98b5940 d0db0000 20k 20k [ anon ]
> ecfbfa00 d0dc1000 1016k 4k [ anon ]
> dcb6dec8 d0ec0000 16k /lib/libsecdb.so.1
> ed0ee290 d0ed4000 4k 4k /lib/libsecdb.so.1
> dcb6db08 d0ee0000 64k 64k [ anon ]
> d54c7848 d0ef2000 1016k 4k [ anon ]
> d7f2d810 d0ff1000 1016k 544k [ anon ]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> d7c841c0 d10f0000 100k /lib/libumem.so.1
>
> Look at truss output we where it was allocated
>
> <...>
> 14945: chmod("/etc/svc/volatile/nwam", 07555) = 0
> 14945: chown("/etc/svc/volatile/nwam", 16, 65) = 0
> 14945: open("/etc/svc/volatile/nwam/nwam_backend_door",
> O_RDWR|O_NONBLOCK|O_CRE
> AT|O_EXCL|O_NOFOLLOW, 0444) Err#17 EEXIST
> 14945: door_create(0xD11C75F0, 0x00000000, DOOR_REFUSE_DESC) = 5 14945:
> getpid() = 14945 [14943]
> 14945: priocntlsys(1, 0x080478B0, 3, 0x080479A0, 0) = 14945
> 14945: priocntlsys(1, 0x08047840, 1, 0x08047900, 0) = 3
> 14945: priocntlsys(1, 0x08047800, 0, 0xD1373EB0, 0) = 3
> 14945: mmap(0x00000000, 131072, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANON, -1,
> 0) = 0xD116F000
> 14945: mmap(0x00000000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON,
> -1,
> 0) = 0xD1150000
> 14945: sigaction(SIGCANCEL, 0x080479C0, 0x00000000) = 0
> 14945: sysconfig(_CONFIG_STACK_PROT) = 3
> 14945: mmap(0x00000000, 1040384, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_NORESERV
> E|MAP_ANON, -1, 0) = 0xD0FF1000
> <==============================================mmap call.
> 14945: getcontext(0x08047810)
> 14945: uucopy(0x080477E0, 0xD10EEFF0, 16) = 0
> 14945: lwp_create(0x08047A60, LWP_DETACHED|LWP_SUSPENDED, 0x08047A5C) = 2
> <======= 2nd thread created.
> 14945/1: lwp_continue(2) = 0 14945/1: yield()
>
> <....>
>
> So when the door_create call is made it will eventually call
> door_server_func() which results in calling door_create_server() to create a
> thread for the door. The call to mmap is being made by the thread library.
> The calling sequence is below
>
> door_create_server --> thr_create -->_thrp_create --> find_stack --> mmap()
> _thrp_create --> setup_context --> setup_top_frame --> uucopy()
>
> So this is similar to the issue in the attached messages.
> I have only looked at netcfg but I am sure nwamd shows leaked memory because
> of the same reason.
>
> Let me know if you have any questions. I am also ccing Alan since he was
> looking at this issue as well.
>
> Rao.
Subject:
Re: [mdb-discuss] Question about mdb/::findleaks and mmap(2) leaks
From:
Michen Chang <Michen.Chang at sun.com>
Date:
Fri, 09 Feb 2007 19:48:00 -0600
To:
Eric Schrock <eric.schrock at sun.com>
To:
Eric Schrock <eric.schrock at sun.com>
CC:
mdb-discuss at opensolaris.org
Hi Eric,
Thanks for the information.
Using DTrace, I don't see that the program (nscd) calls the getmntent,
getmntany, getextmntent, or resetmnttab libc calls, but it does show me that
door_create() is one of the functions that calls mmap(). After stopping nscd
and running mdb/findleaks before and after the door_create call, I can confirm
that the mmap leak is due to nscd's calling door_create(). Not sure if nscd can
do anything about it since no pointer is passing back, so I assume, as you
said, this is not a concern.
Thanks,
Michen
Eric Schrock wrote:
> No, this is not a concern. Most likely what is happening is that you
> are using one of the getmntent() family of libc calls. This does an
> ioctl() to /etc/mnttab which ends up creating a mapping within the user
> process on behalf of the kernel. User applications typically don't keep
> these pointers around, so it often appears as a leaked mmap() memory
> region.
>
> - Eric
>
> On Thu, Feb 08, 2007 at 12:08:20PM -0600, Michen Chang wrote:
>
>> Hi,
>>
>> For the OpenSolaris Project Sparks (name service switch/nscd enhancements),
>> we have a test suite (nss2) that includes test cases using
>> gcore/mdb/findleaks
>> to detect memory leaks. It works pretty good except that we saw a lot of
>> ::findleaks output like the following that caused the test cases to fail:
>>
>> stdout| findleaks: maximum buffers => 442
>> stdout| findleaks: actual buffers => 181
>> stdout| findleaks:
>> stdout| findleaks: potential pointers => 166153
>> stdout| findleaks: dismissals => 125325 (75.4%)
>> stdout| findleaks: misses => 36775 (22.1%)
>> stdout| findleaks: dups => 3873 ( 2.3%)
>> stdout| findleaks: follows => 180 ( 0.1%)
>> stdout| findleaks:
>> stdout| findleaks: peak memory usage => 61 kB
>> stdout| findleaks: elapsed CPU time => 0.0 seconds
>> stdout| findleaks: elapsed wall time => 0.0 seconds
>> stdout| findleaks:
>> stdout| BYTES LEAKED VMEM_SEG CALLER
>> stdout| 8192 1 cdb9c000 MMAP
>> stdout|
>> ------------------------------------------------------------------------
>> stdout| Total 1 oversized leak, 8192 bytes
>> stdout|
>> stdout| mmap(2) leak: [cdb9c000, cdb9e000), 8192 bytes
>>
>> I remember reading someone's weblog (may be Jonathan Adams')
>> saying that these are due to kernel's work and not really are
>> true leaks. But I could no longer find the weblog or document
>> I read.
>>
>> Is this something we should be concerned with ? If so, how do
>> we go about root-causing it ?
>>
>> Thanks,
>> Michen
>>
>> _______________________________________________
>> mdb-discuss mailing list
>> mdb-discuss at opensolaris.org
>>
>
> --
> Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
>
_______________________________________________
mdb-discuss mailing list
mdb-discuss at opensolaris.org
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
