[Mldonkey-bugs] [bugs #11149] Core does not close file descriptors and eventually hits ulimit

[Sebastian Hagedorn]

This mail is an automated notification from the bugs tracker
 of the project: mldonkey, a multi-networks file-sharing client.

/**************************************************************************/
[bugs #11149] Latest Modifications:

Changes by: 
                Sebastian Hagedorn <address@hidden>
'Date: 
                Die 14.12.2004 at 09:38 (GMT)

------------------ Additional Follow-up Comments ----------------------------
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.






/**************************************************************************/
[bugs #11149] Full Item Snapshot:

URL: <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=11149>
Project: mldonkey, a multi-networks file-sharing client
Submitted by: 0
On: Sam 27.11.2004 at 17:12

Category:  Core
Severity:  5 - Average
Item Group:  Program malfunction
Resolution:  None
Privacy:  Public
Assigned to:  None
Status:  Open
Release:  2-5-22
Release:  10.3.6
Platform Version:  Mac OS X Jaguar
Binaries Origin:  Downloaded from third-party page
CPU type:  PowerPC


Summary:  Core does not close file descriptors and eventually hits ulimit

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.


Follow-up Comments
------------------


-------------------------------------------------------
Date: Die 14.12.2004 at 09:38       By: Sebastian Hagedorn <hgd>
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.

-------------------------------------------------------
Date: Son 05.12.2004 at 22:21       By: 0 <None>
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.


-------------------------------------------------------
Date: Sam 27.11.2004 at 19:52       By: 0 <None>
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.












For detailed info, follow this link:
<http://savannah.nongnu.org/bugs/?func=detailitem&item_id=11149>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/