[Mldonkey-bugs] [bugs #8580] Writing into file in incoming directory

[spiralvoice]

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

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

Changes by: 
                spiralvoice <address@hidden>
'Date: 
                Thu 07/22/04 at 23:58 (Europe/Berlin)

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






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

URL: <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=8580>
Project: mldonkey, a multi-networks file-sharing client
Submitted by: Artifex Maximus
On: Thu 04/15/04 at 13:04

Category:  Core
Severity:  9 - Blocker
Item Group:  Program malfunction
Resolution:  None
Assigned to:  None
Status:  Open
Release:  2-5-16
Release:  +Spiralvoice patch k
Platform Version:  FreeBSD
Binaries Origin:  CVS / Self compiled
CPU type:  Intel x86


Summary:  Writing into file in incoming directory

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

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


-------------------------------------------------------
Date: Thu 07/22/04 at 23:58         By: spiralvoice
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.

-------------------------------------------------------
Date: Wed 06/09/04 at 16:03         By: m-o-w
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.
#


-------------------------------------------------------
Date: Mon 05/10/04 at 14:02         By: artifex
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

-------------------------------------------------------
Date: Sun 05/09/04 at 18:12         By: m-o-w
I didn't. That was the mlnet from the mldonkey-2.5-16l.static.i386-Linux.rar 
archive you provided.

-------------------------------------------------------
Date: Sun 05/09/04 at 15:29         By: spiralvoice
How did you compile MLDonkey?

-------------------------------------------------------
Date: Sat 05/08/04 at 19:53         By: m-o-w
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:mldonkeyincoming>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;address@hidden&#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;address@hidden&#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. 

-------------------------------------------------------
Date: Mon 04/26/04 at 16:14         By: artifex
I applied the patch and start to test. Any report will go to the patch section.

bye

-------------------------------------------------------
Date: Fri 04/23/04 at 21:45         By: spiralvoice
Please try patch 2965 and report if it helps

-------------------------------------------------------
Date: Sun 04/18/04 at 09:42         By: artifex
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

-------------------------------------------------------
Date: Sat 04/17/04 at 07:03         By: artifex
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






File Attachments
-------------------

-------------------------------------------------------
Date: Sat 04/17/04 at 07:03  Name: 16hp_err_2.png  Size: 20.02KB   By: artifex
Image with the problematic part of file
http://savannah.nongnu.org/bugs/download.php?item_id=8580&amp;item_file_id=1200






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

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