bugmldonkey, a multi-networks file-sharing client - Bugs: bug #8580, Writing into file in incoming...

 
 

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

bug #8580: Writing into file in incoming directory

Submitter:  Artifex Maximus <artifex>
Submitted:  Thu 15 Apr 2004 01:04:41 PM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Program malfunction Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  2-5-16 Release:  +Spiralvoice patch k
Operating System:  FreeBSD Binaries Origin:  CVS / Self compiled
CPU type:  Intel x86

Jump to the original submission

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.

Mark-Oliver Wolter <m-o-w>
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.

spiralvoice <spiralvoice>
Group administrator
Tue 10 Aug 2004 02:54:02 PM UTC, comment #14: 

Please try CVS 2-5-27 and report if the bugs is solved

spiralvoice <spiralvoice>
Group administrator
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.

mldonkey admin <mldonkey>
Group administrator
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»§<™2g“M,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.

Mark-Oliver Wolter <m-o-w>
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

Mark-Oliver Wolter <m-o-w>
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.

spiralvoice <spiralvoice>
Group administrator
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.
#

Mark-Oliver Wolter <m-o-w>
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

Artifex Maximus <artifex>
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.

Mark-Oliver Wolter <m-o-w>
Sun 09 May 2004 03:29:38 PM UTC, comment #6: 

How did you compile MLDonkey?

spiralvoice <spiralvoice>
Group administrator
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
*** gehteuchnixan
wäÃ+&#9830;$V&#8215;É^ã?qudé¸\ù&#9792;¯r&#9650;<ƒ&#8962;/«&#9617;&#9556;0ëë&#9492;jƒ&#8215;¨S_&#8594;-~&#9568;&#9650;#b£#>ï´?&#8596; ½D&#9556;&#9556;6(­ &#9632;&#9619;²LØ&#9827;5?2&#9786;&#9496;ìµ3 &#9553;Y
&#9786;       _&#8215;&#9556;ôÌïnøOoG{§9S;&#9516;6usöF&#9556;+
Ã|æºæº_&#8252;&#9574;0&#9568;&#8252;&#9617;#Mt¿4dìÓe??ª,1#&#9608;VÕÞîqWxá&#9496;U1Ù¢&#8252;ó¶§&#9532;Fatal error: out of memory.
ÙOºÈÚÃé&#8596;Ij}TR&#9792;Ü&#9787;ìOñ_ê¬s&#9650; &#305;+&#9668;ªYIÓ&#9792;&#9830;êå¸:þ&#9556;Æ&#9508;&#9618;&#8735;&#9827;&#9658;må&#8595;&#9508;&#8595;Üê¨?ä­ô&#9619;ba×&#9565;&#9658;&#9484;¶ú`rñóa-C
Ñ&#9580;f?ú6«1Q迯þ·ƒ]@©&#9565;ß&#8594;&#9794;©ËW¿^úÉ?[¾&#8962;UÕi!9&#8595;&#9794;&#9835;&#8735;&#8735;¹â&#9650;¹Ü"&#9500;¸oY=Ñ&#9577;&#9618;<&#9668;³*#2å&#9835;7µ÷mÊé=ÌrÞ&#9556;@÷â&#9786;
«¨Ü&#9617;0È&#9553;³|½àÓú°êÌK&#8594;Ê&#8597;4&#8595;       ?&#9492;Û&#9571;
*** F:gehteuchnixan
wäÃ+&#9830;$V&#8215;É^ã?qudé¸\ù&#9792;¯r&#9650;<ƒ&#8962;/«&#9617;&#9556;0ëë&#9492;jƒ&#8215;¨S_&#8594;-~&#9568;&#9650;#b£#>ï´?&#8596; ½D&#9556;&#9556;6(­ &#9632;&#9619;²LØ&#9827;5?2&#9786;&#9496;ìµ3 &#9553;Y
&#9786;       _&#8215;&#9556;ôÌïnøOoG{§9S;&#9516;6usöF&#9556;+
Ã|æºæº_&#8252;&#9574;0&#9568;&#8252;&#9617;#Mt¿4dìÓe??ª,1#&#9608;VÕÞîqWxá&#9496;U1Ù¢&#8252;ó¶§&#9532;&#9830;SL&#9787;&#8593;ñ½ßúæâxHqEºO&#9827;ľ&#9786;ë^ßÜGs.ÙOºÈÚ
Ãé&#8596;Ij}TR&#9792;Ü&#9787;ìOñ_ê¬s&#9650; &#305;+&#9668;ªYIÓ&#9792;&#9830;êå¸:þ&#9556;Æ&#9508;&#9618;&#8735;&#9827;&#9658;må&#8595;&#9508;&#8595;
ê¨?ä­ô&#9619;ba×&#9565;&#9658;&#9484;¶ú`rñóa-C
Ñ&#9580;f?ú6«1Q迯þ·ƒ]@©&#9565;ß&#8594;&#9794;©ËW¿^úÉ?[¾&#8962;UÕi!9&#8595;&#9794;&#9835;&#8735;&#8735;¹â&#9650;¹Ü"&#9500;¸oY=Ñ&#9577;&#9618;<&#9668;³*#2å&#9835;7µ÷mÊé=ÌrÞ&#9556;@÷â&#9786;
«¨Ü&#9617;0È&#9553;³|½àÓú°êÌK&#8594;Ê&#8597;4&#8595;       ?&#9492;Û&#9571;
***

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.

Mark-Oliver Wolter <m-o-w>
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

Artifex Maximus <artifex>
Fri 23 Apr 2004 09:45:35 PM UTC, comment #3: 

Please try patch 2965 and report if it helps

spiralvoice <spiralvoice>
Group administrator
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

Artifex Maximus <artifex>
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

Artifex Maximus <artifex>
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

Artifex Maximus <artifex>

 

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

Attached Files
file #1217:  16hp_err_2.png added by artifex (20KiB - image/png - Image with the problematic part of file)

 

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 6 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-02-01 spiralvoice StatusNone Fixed
    Open/ClosedOpen Closed
2004-08-10 spiralvoice Severity3 - Normal 1 - Wish
2004-08-10 mldonkey Severity6 - Security 3 - Normal
2004-04-23 spiralvoice Severity3 - Normal 6 - Security
2004-04-17 artifex Attached File- Added 16hp_err_2.png, #1200

Back to the top

Powered by Savane 3.13-4448.
Corresponding source code