mldonkey, a multi-networks file-sharing client - Bugs: bug #11384, Source of Orphaned File Descriptor...
You are not allowed to post comments on this tracker with your current authentication level.
bug #11384: Source of Orphaned File Descriptor Bug
Submitter: | Shunga <shunga> | ||
Submitted: | Thu 23 Dec 2004 03:46:35 PM UTC | ||
Category: | Core | Severity: | 3 - Normal |
Item Group: | Program malfunction | Status: | Fixed |
Assigned to: | None | Open/Closed: | Closed |
Release: | None | Release: | 2.5-22 |
Operating System: | Mac OS X 10.3 | Binaries Origin: | CVS / Self compiled |
CPU type: | PowerPC |
Jump to the original submission
Thu 13 Jan 2005 07:02:56 PM UTC, comment #19: |
Shunga <shunga> |
Thu 13 Jan 2005 12:48:18 AM UTC, comment #18: Patch #3637 is online... |
spiralvoice <spiralvoice> |
Thu 13 Jan 2005 12:25:07 AM UTC, comment #17: Saw that as well, but I don't know how to download OCaml CVS version. Some months ago I used these commands:
|
spiralvoice <spiralvoice> |
Wed 12 Jan 2005 09:56:27 PM UTC, comment #16: I've received an email from caml that the OCAML issue with the open file descriptors (id = 3423) has been fixed in the CVS version of OCAML. |
Shunga <shunga> |
Mon 10 Jan 2005 09:20:01 PM UTC, comment #15: FYI: There are bug reports at Inria so this problem will be fixed sometime.
|
spiralvoice <spiralvoice> |
Fri 07 Jan 2005 04:06:19 AM UTC, comment #14: I think I've verified that the problem is in the OCAML unix library, not in mldonkey. I modified OCAML's unix library and moved the unix_error call that was in alloc_sockaddr to the routines that called alloc_sockaddr and returned a value of -1 from within alloc_sockaddr. That allowed me in unix_accept to close(retcode) before calling unix_error. I rebuilt 2.5.29ab with the begin/end added to tcp_handler, but removed the "close t" because that is incorrect. The log file indicates that I've gotten a number of tcp_handler errors but now I have only one orphaned file descriptor (the one due to send_paquet_to_mlchat and I've verified that I still have a high ID (since the close t was removed).
|
Shunga <shunga> |
Fri 07 Jan 2005 02:26:53 AM UTC, comment #13: Although I don't understand the source of the problem, I think I now know the reason for the orphaned socket on Mac OS X. I believe the source of the problem is the OCAML Unix.accept routine. This routine I think calls the OCAML unix_accept routine defined in ocaml-3.08.0/otherlibs/unix/accept.c and the code looks like this:
|
Anonymous |
Thu 06 Jan 2005 04:55:26 PM UTC, comment #12: Just my observation: with 2-5-28i and this patch I always got LowID´s, without it HighID´s. |
spiralvoice <spiralvoice> |
Thu 06 Jan 2005 02:47:12 PM UTC, comment #11: Adding the begin/end around the "try" in tcp_handler fixed the compilation warning bug didn't change anything. It still appears that when "close t" is performed that the socket for port 4662 is closed and from that point on because that port is now closed future server connections get a low ID. The error in the log "Exception tcp_handler: failed: Address family not supported by protocol family" appears to be an error due to a Unix connect call and not due to the accept call, although when I added a Unix.Unix_error match to the try, Unix.Unix_error was never matched, only "e". What I would like to try but don't know how to do is when the error occurs, close the socket "s" that was created by the Unix.accept call instead of closing t (which appears to be the socket for port 4662). I expect that whaterver the problem is, it is not actually in tcp_handler, but somewhere else and perhaps related to a connect call.
|
Shunga <shunga> |
Thu 06 Jan 2005 02:06:30 PM UTC, comment #10: I compiled the tag-2-5-29ab source that you pointed to that schlumpf provided with no changes. After I posted the bug and the "try" suggestion to illustrate the error, I did notice the compilation warning and added the begin/end combination just as you did in the patch. As I recall, it didn't change anything, but I'll try it once more to make sure using the tag-2-5-29ab source..
|
Anonymous |
Thu 06 Jan 2005 01:40:02 PM UTC, comment #9: I compiled the tag-2-5-29ab source that you pointed to that schlumpf provided with no changes. After I posted the bug and the "try" suggestion to illustrate the error, I did notice the compilation warning and added the begin/end combination just as you did in the patch. As I recall, it didn't change anything, but I'll try it once more to make sure using the tag-2-5-29ab source..
|
Anonymous |
Thu 06 Jan 2005 04:55:25 AM UTC, comment #8: did you try that with or without the patch i posted in the forum linked in my last comment to this bug? if without please try with it applied. (oh and no need to message me through savannah i get notified on changes of bugs i posted to)
|
Amorphous <amorphous> |
Thu 06 Jan 2005 03:33:04 AM UTC, comment #7: When I suggested the try, I noticed the same thing that I'm noticing with 2.5.29ab. When I originally suggested the "try" in tcp_handler to illustrate the error, I noticed the following issue which also occurs with the patch. When the error occurs and the "close t" is issued, that close apparently closes the socket on port 4662. After that occurs, it is true that there are no more orphaned file descriptors, however, it appears that any additional connections to servers results in a lowid. For example in my console log, after the error occurs, I start seeing the following when attaching to new servers:
|
Shunga <shunga> |
Wed 05 Jan 2005 06:53:56 PM UTC, comment #6: it's in the svn repository mentioned in another thread in that forum-group. i added a link to an archive of the source, schlumpf provided. |
Amorphous <amorphous> |
Wed 05 Jan 2005 09:34:49 AM UTC, comment #5: I would like to try this but with what? I read the post at http://mldonkey.berlios.de/modules.php?name=Forums&file=viewtopic&t=3201&sid=6c52a2530f6046d72fdfbbb94c0c1d72 and I have looked at the CVS-page but I don't know where the/which source to download - where is the 29ab-version? |
d-b |
Wed 05 Jan 2005 09:30:54 AM UTC, comment #4: I would like to try this but with what? I read the post at http://mldonkey.berlios.de/modules.php?name=Forums&file=viewtopic&t=3201&sid=6c52a2530f6046d72fdfbbb94c0c1d72 and I have looked at the CVS-page but I don't know where the/which source to download - where is the 29ab-version? |
d-b |
Wed 05 Jan 2005 08:23:28 AM UTC, comment #3: could you confirm if this is fixed with 2.5.29ab? see http://mldonkey.berlios.de/modules.php?name=Forums&file=viewtopic&t=3201&sid=6c52a2530f6046d72fdfbbb94c0c1d72 |
Amorphous <amorphous> |
Thu 23 Dec 2004 08:51:27 PM UTC, comment #2: Programmer asleep at the switch :-). I was wrong about some other software change. Turns out tcp_handler does fail if changed as follows:
|
Shunga <shunga> |
Thu 23 Dec 2004 08:03:07 PM UTC, comment #1: Well it would appear that the failure in tcp_handler was due to some other change that I must have made while attempting to debug this. When I start over with a fresh copy of the source the handler doesn't fail and the file descriptors start building up.
|
Shunga <shunga> |
Thu 23 Dec 2004 03:46:35 PM UTC, original submission:
On Mac OS X and I assume other systems there are two bugs in mlnet which together generate hundreds of orphaned file descriptors causing mlnet to eventually hang. I worked with mlnet 2.5-22 source and ocaml 3.07-p12 to debug the source of the problem:
|
Shunga <shunga> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2005-01-30 | spiralvoice | Status | None | Fixed | |
Open/Closed | Open | Closed | |||
2005-01-03 | hgd | Carbon-Copy | - | Added hgd | |
2005-01-02 | d-b | Carbon-Copy | - | Added i97_bed --AT-- i --DOT-- kth --DOT-- se |
Powered by Savane 3.13-f8d8.
Corresponding source code
It looks like the fix was applied to the tag named "release308" which I assume will eventually become the 3.08.3 release. I think you will have to use the CVS -r option with the CVS checkout command to download that tagged version.
cvs co -r release308 ocaml