bugmldonkey, a multi-networks file-sharing client - Bugs: bug #11149, Core does not close file...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #11149: Core does not close file descriptors and eventually hits ulimit

Submitter:  None
Submitted:  Sat 27 Nov 2004 05:12:31 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Program malfunction Status:  Duplicate
Assigned to:  None Open/Closed:  Closed
Release:  2-5-22 Release:  10.3.6
Operating System:  Mac OS X 10.3 Binaries Origin:  Downloaded from third-party page
CPU type:  PowerPC

Sun 02 Jan 2005 05:12:33 PM UTC, comment #4: 

Duplicate of bug #11384

spiralvoice <spiralvoice>
Group administrator
Tue 14 Dec 2004 09:38:27 AM UTC, comment #3: 

I'm seeing the exact same problem, also under Mac OS X. According to the lsof FAQ:

4.8 What does lsof mean when it says, "no PCB, CANTSENDMORE,
CANTRCVMORE" in a socket file's NAME column?

When an AIX application calls shutdown(2) on an open socket
file, but hasn't called close(2) on the file, the file will
remain visible to lsof as an open socket file without any
extended protocol information.

Lsof reports that state in the NAME column by saying that
there is "no PCB" (Protocol Control Block) for the protocol
(e.g., TCP in the NODE column).  If the open socket file
has the state variables SO_CANTSENDMORE and SO_CANTRCVMORE
set -- i.e., from the shutdown(2) call -- lsof reports them
with the CANTSENDMORE and CANTRCVMORE notes in the NAME
column.

So perhaps mldonkey shuts down the socket without closing it first? It's quite possible that this is OK under e.g. Linux, but not under Darwin.

Sebastian Hagedorn <hgd>
Sun 05 Dec 2004 10:21:06 PM UTC, comment #2: 

It's been a very long time since I've seen such problem on my own core. So It's either MacOS X related, or related to the way to use mlnet.

Anonymous
Sat 27 Nov 2004 07:52:57 PM UTC, comment #1: 

Have discovered that the file descriptors in question are not in the file descriptor list so that "poll" or "select" never sees them.  They must have been opened at some point but because of an error were never added to the file descriptor list but also not closed.  That is apparently why they are left orphaned.

Anonymous
Sat 27 Nov 2004 05:12:31 PM UTC, original submission:  

It would appear that core does not always close dormant file descriptors which causes open file descriptors to increase to the point that core stops working due to reaching max ulimit.  This happens on both Jaguar and Panther and versions 2-5-22 and 2-5-16 of mlnet (current version of Panther is 10.3.6).  Using lsof, the problematic file descriptors look like:

mlnet      1551 jume  113u  IPv4                   0t0      TCP no PCB, CANTSENDMORE, CANTRCVMORE

Hypothesize that this is due to a connection that is not closed properly at the other end and core does not detect that the file descriptor is no longer usable or needed.  After some period of time these file descriptors keep increasing until the ulimit is reached and core hangs.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 2 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-01-02 spiralvoice StatusNone Duplicate
    Open/ClosedOpen Closed

Back to the top

Powered by Savane 3.13-f8d8.
Corresponding source code