[Openmcl-devel] mach ports leaking?

[David Reitter]

On 3 Feb 2009, at 02:26, Gary Byers wrote:

> I don't know what your program's doing, so I can't really guess why  
> top
> clams that it's using as many Mach ports as it is.

Most of the code that I'm running there isn't mine, so I can't tell  
for sure.  But asking the author (and doing a "grep") revealed that no  
threads seem to be used.

> I'm sure that there are lots of ways in which ports are used in and  
> allocated
> by the Mach kernel (possibly by the memory system, I/O, other forms  
> of IPC,
> whatever ...).  I don't know exactly what it would mean for an  
> application
> to "leak" ports that it doesn't explicitly create.

After running this overnight, it does not appear that the ports are  
cleaned up.  I have 39M and 354M ports, respectively, and, what's  
worse, they seem to be correlated with memory usage.

   PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD   
RSIZE  VSIZE
30211 dx86cl64     0.0%  2:03:17   3     0    419   39M   188K     
40M   470M
14994 dx86cl64     0.0%  8:21:10   3     0    473  354M   188K    
355M   625M

> Depending on how files are opened, they may hae locks associated with
> them, as can hash tables and other lisp data structures.  (Locks in
> Darwin have semaphores - and therefore Mach ports - associated with
> them.)  All of these things should get GCed eventually, unless
> something takes unusual steps to keep this from happening (e.g., (PUSH
> (MAKE-HASH-TABLE) *BIG-LIST-OF-HASH-TABLES*))

lsof doesn't show excessive numbers of open files.  How do I show the  
heap size?
(ccl:gc) doesn't help.

Running your (mach-port-count) returns NIL in both of the above  
processes.

> FireFox is using about 300 at the moment ... so yes, 90000 seems a bit
> high.

Indeed. If 90k is much, how does 354 million sound then...?

> <http://developer.apple.com/samplecode/MachPortDump/>

I grabbed and built this, but it fails to attach to the CCL processes.

I'd be happy to do my bit in hunting this bug; I can't tell whether  
it's in CCL or in the library that I am using.  I could also make the  
code available privately.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2193 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090203/25990463/attachment.bin>