Tue 10 Aug 2004 08:00:53 PM UTC, comment #16:
Is it even allowed to close stderr with ocaml?
If yes, then this is a bug in ocaml and not mlnet, as the text written appears only in the ocaml library functions (does it even return from the library call, or does it crash right away? I don't have the source here right now, only the static binaries, and wouldn't know where to look anyway).
If no, then stderr should not be closed but redirected to /dev/null or something.
|
Tue 10 Aug 2004 06:45:02 PM UTC, comment #15:
Changing severity to 1 because this bug might be solved in current CVS release.
|
Tue 10 Aug 2004 02:54:02 PM UTC, comment #14:
Please try CVS 2-5-27 and report if the bugs is solved
|
Tue 10 Aug 2004 08:29:30 AM UTC, comment #13:
The out-of-memory error is very hard to use, the only thing that could be useful to do would be to crash the program immediatly before it does any wrong to the files.
By the way, how do you start mldonkey ? Is it started as a daemon. Indeed, if it started like that, it is possible that ocaml writes the "Fatal error" message on stderr, without knowing that the daemon has closed this descriptor and re-uses it for other files.
|
Tue 10 Aug 2004 03:47:03 AM UTC, comment #12:
Upgraded the machine to 256MB last week, and started mlnet with ulimit of 150MB.
Started mlnet on 2004-08-06 1:30. It went down 2004-08-08 19:19 which I see from the timestamp of the file it wrote its "Fatal error: out of memory" into when it did so.
This was a file in a shared folder, not incoming. Still -16q.
grep memory /mld/b0rken_file -a
?*_Àxà|w;S1,
ð±îùÇj¬üíyúõìüüK?,9k¡í£^b²L»§<2gM,8¨3=Û»ë3[Û¾Óg÷»Ù?ã¾J!=ªîQ¨ÔO[â?§¿ÿ¨?@i}á?N(bæK`¸E+G¹PÅzË-NÛø´õi}²Ü¡¦½?5]õw]=,E9TÀ²EnPJËaÙKúþ¿°?3J×
,À?h×È,*
M*)D&¼röÕU ,bFatal error: out of memory.
|
Fri 23 Jul 2004 01:14:36 AM UTC, comment #11:
Does any other user use ulimit to restrict memory usage?
To trigger this problem, you could set the limit to a low value like 30M, that should kill mlnet quite fast.
I'm a bit reluctant to test right now because mlnet -16q is running since 2004-7-17 and even went down from ~80MB to about 30MB when a big file was finished, just now it went up to 53MB though.
In -16m, the problem was still there as you can see below. Did you remove any Printf.printf commands since then?
By the way, a grep -r "Fatal error: out of memory" * in the source tree shows this error message is not in the mlnet source, but in ocaml itself:
e.g.
Binary file patches/local/lib/ocaml/libcamlrun.a matches
|
Thu 22 Jul 2004 11:58:51 PM UTC, comment #10:
AFAICS there are no more Printf.printf commands left so I can't really say which part of the code is responsible. Do users of others OS's have the same problem? Here (x86 Linux) it never occured.
|
Wed 09 Jun 2004 04:03:38 PM UTC, comment #9:
With 2.5-16m:
When mldonkey just went down reaching the ulimit, I found this:
-rw-r--r-- 1 mow users 28 Jun 9 17:25 downloads.ini.tmp
# cat downloads.ini.tmp
Fatal error: out of memory.
#
|
Mon 10 May 2004 02:02:35 PM UTC, comment #8:
FreeBSD 4.x-STABLE, ocaml 3.07pl2
./configure \
--build=i386-artifex-freebsd4.9 \
--prefix=/usr/local \
--enable-local-prefix=/usr/local \
--disable-shared \
--enable-pthread \
--enable-batch \
--enable-checks \
--enable-multinet \
--disable-newgui \
--disable-gui \
--enable-bittorrent \
--enable-donkey \
--disable-audiogalaxy \
--disable-opennap \
--disable-gnutella \
--disable-gnutella2 \
--disable-directconnect \
--disable-soulseek \
--disable-openft \
--disable-cymes \
--disable-fasttrack
gmake depend
gmake
bye
|
Sun 09 May 2004 06:12:48 PM UTC, comment #7:
I didn't. That was the mlnet from the mldonkey-2.5-16l.static.i386-Linux.rar archive you provided.
|
Sun 09 May 2004 03:29:38 PM UTC, comment #6:
How did you compile MLDonkey?
|
Sat 08 May 2004 07:53:32 PM UTC, comment #5:
The problem is even worse than just what the patch addresses according to its description.
To work around my memory problems (see bug #7967) I set ulimits. Now in the last two days I got two files that suddenly got a current timestamp. This did not happen in the weeks before.
I ran a fc on the second file because I happened to have an unchanged copy still lying around, and guess what:
Q:\mldonkey\incoming>fc "filename." f:.
Vergleichen der Dateien gehteuchnixan und F:gehteuchnixan
wäÃ+♦$V‗É^ã?qudé¸\ù♀¯r▲<⌂/«░╔0ëë└j‗¨S_→-~╠▲#b£#>ï´?↔ ½D╔╔6( ■▓²LØ♣5?2☺┘ìµ3 ║Y
☺ _‗╔ôÌïnøOoG{§9S;┬6usöF╔+
Ã|æºæº_‼╦0╠‼░#Mt¿4dìÓe??ª,1#█VÕÞîqWxá┘U1Ù¢‼ó¶§┼Fatal error: out of memory.
ÙOºÈÚÃé↔Ij}TR♀Ü☻ìOñ_ê¬s▲ ı+◄ªYIÓ♀♦êå¸:þ╔Æ┤▒∟♣►må↓┤↓Üê¨?äô▓ba×╝►┌¶ú`rñóa-C
Ñ╬f?ú6«1Q迯þ·]@©╝ß→♂©ËW¿^úÉ?[¾⌂UÕi!9↓♂♫∟∟¹â▲¹Ü"├¸oY=Ñ╩▒<◄³*#2å♫7µ÷mÊé=ÌrÞ╔@÷â☺
«¨Ü░0È║³|½àÓú°êÌK→Ê↕4↓ ?└Û╣
wäÃ+♦$V‗É^ã?qudé¸\ù♀¯r▲<⌂/«░╔0ëë└j‗¨S_→-~╠▲#b£#>ï´?↔ ½D╔╔6( ■▓²LØ♣5?2☺┘ìµ3 ║Y
☺ _‗╔ôÌïnøOoG{§9S;┬6usöF╔+
Ã|æºæº_‼╦0╠‼░#Mt¿4dìÓe??ª,1#█VÕÞîqWxá┘U1Ù¢‼ó¶§┼♦SL☻↑ñ½ßúæâxHqEºO♣ľ☺ë^ßÜGs.ÙOºÈÚ
Ãé↔Ij}TR♀Ü☻ìOñ_ê¬s▲ ı+◄ªYIÓ♀♦êå¸:þ╔Æ┤▒∟♣►må↓┤↓
ê¨?äô▓ba×╝►┌¶ú`rñóa-C
Ñ╬f?ú6«1Q迯þ·]@©╝ß→♂©ËW¿^úÉ?[¾⌂UÕi!9↓♂♫∟∟¹â▲¹Ü"├¸oY=Ñ╩▒<◄³*#2å♫7µ÷mÊé=ÌrÞ╔@÷â☺
«¨Ü░0È║³|½àÓú°êÌK→Ê↕4↓ ?└Û╣
*****
So when mlnet got to the ulimit, it wrote "Fatal error: out of memory." into the file.
I guess it's just murphy that I got this twice the last two days and never before, this message probably got written into some not-yet-fully-downloaded file which then got reloaded in the next chunk check.
So there are probably some more rogue printfs in there which wait to bite our asses.
|
Mon 26 Apr 2004 04:14:40 PM UTC, comment #4:
I applied the patch and start to test. Any report will go to the patch section.
bye
|
Fri 23 Apr 2004 09:45:35 PM UTC, comment #3:
Please try patch 2965 and report if it helps
|
Sun 18 Apr 2004 09:42:23 AM UTC, comment #2:
I take a look into the source and set min_users_on_server back to zero and therefore MLD never try to remove any server. Problem is gone but this is just a temporary solution, I think.
BTW, I try -18 and it collects sources but don't start to download. I switched back to -16l and stuffs started to come. :)
bye
|
Sat 17 Apr 2004 07:03:04 AM UTC, comment #1:
It's happen again with another file. After that I upgraded my MLD to -18 and hope the problem is gone. BTW, I attached an image what happen with my file. It's looks like the log file goes into the file.
bye
|
Thu 15 Apr 2004 01:04:41 PM UTC, original submission:
I start to download a file. It's slowly finished, automatically moved to incoming and I received a notification mail. Great. Now comes the strange part. I download this file to my workstation. After that on the server in the incoming directory the mldonkey write anything (I don't know what) into that file. The md4 value changed of course but on my workstation the file's md4 is correct. What happen? Why MLD write to this file after committed? Strange...
bye
|