bugmldonkey, a multi-networks file-sharing client - Bugs: bug #15959, Assertion fails at startup - all...

 
 

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

bug #15959: Assertion fails at startup - all files lost

Submitter:  Sakari Aaltonen <sakari>
Submitted:  Thu 02 Mar 2006 04:41:47 PM UTC
   
 
Category:  Core Severity:  5 - Blocker
Item Group:  Program malfunction Status:  None
Assigned to:  None Open/Closed:  Closed
Release:  None Release:  2.7.3
Operating System:  Linux Binaries Origin:  CVS / Self compiled
CPU type:  Intel x86

Jump to the original submission

Tue 16 May 2006 10:17:50 PM UTC, comment #7: 

"It would be better if the second torrent-file got another local name instead of overwriting the one thatäs allready in use."

I could reproduce the error using your good description, thanks.

Trying to fix this is not that easy, inside the .torrent file
is a hard-coded filename which is used by MLDonkey.
Renaming the .torrent file makes this out-of-sync.

Another idea was to put the .torrent into torrents/downloads/<file_id>/file.torrent.
file_id as seen in files.ini is a SHA1 hash of the text content
of the torrent file. Your two .torrent files differ for example
that one .torrent has one file more inside so different file_id
values were produced.
This solution produces the problem that the built-in tracker will
get confused when asked for Dag Vag - Almanacka (1983).torrent:

./torrents/downloads/X34OR7VZKJDR3SL2QXT2BN2H2VXW4VYZ/Dag Vag - Almanacka (1983).torrent
./torrents/downloads/CNJUFHE26BBFTAG3Y4CBWHMDF6AHTCMH/Dag Vag - Almanacka (1983).torrent
This scenario will avoid overwriting a .torrent file in your case.
But the MLDonkey tracker will not know which file to use.

After thinking about it the easiest solution would be to disallow
starting a new BT download when the .torrent file has the same
name than a currently working download, or maybe even also
seeded torrents. As this does happen seldomly (otherwise more
users would have experienced your bug) and its easy to code
without unwanted side-effects I would code this unless you or
others have a better idea to fix this bug.

spiralvoice <spiralvoice>
Group administrator
Sat 13 May 2006 07:14:21 PM UTC, comment #6: 

Forget part of my last entry, please. I must have been cinfused myself when reading "files.ini".

The second entry does not have the same swarmer-name as the first.

I do suspect I've identified the problem though.

The two entries pints to the same torrent file name, but really should point to two different files.

The reason for this i probably that I have enterned URLs forf both torrent-files in mlnet's web interface without realising they had the same file name.

The result seems to be that the second file overwrote the first, but the info in "files.ini" was updated for both files.

It would be better if the second torrent-file got another local name instead of overwriting the one thatäs allready in use.

Jonas Eckerman <jonas_e_se>
Wed 10 May 2006 08:28:44 PM UTC, comment #5: 

Some checking in files.ini seems to indicate that mlnet is confusing two different torrents. More below.

I'm also attaching a tet file with somewhat more complete snippets of the same stuff as here.

The patch gives this output:
---8<---
-su-2.05b# ./mlnet.2.7.5.dbg
2006/05/10 21:36:53 Starting MLDonkey 2.7.5 ...
2006/05/10 21:36:53 Language EN, locale ASCII, ulimit for open files 3636
2006/05/10 21:36:53 MLDonkey is working in .
2006/05/10 21:36:53 [DNS] Resolving [boomer.truls.org] ...
2006/05/10 21:36:54 [DNS] Resolving www.mldonkey.net ...
2006/05/10 21:36:58 [IPblock] loading guarding.p2p
2006/05/10 21:37:06 [IPblock] 115067 ranges loaded - optimized to 100848
2006/05/10 21:37:06 [cUd] converting 3 users to new format
2006/05/10 21:37:06 Updating options to version 10
2006/05/10 21:37:06 Updating options to version 11
2006/05/10 21:37:07 [cSw2] file_size for ./temp/BT-X34OR7VZKJDR3SL2QXT2BN2H2VXW4VYZ does not match: swarmer 54143112 / real 58866719
---8<---

Checking BT-X34OR7VZKJDR3SL2QXT2BN2H2VXW4VYZ in "files.ini" I find the following (snipped here):
---8<---
 swarmers = [
[...]
  {     file_size = 54143112
     file_name = "./temp/BT-X34OR7VZKJDR3SL2QXT2BN2H2VXW4VYZ"
     file_bitmap = "333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333303333333333333333333333333333333333333333333333333"
     file_chunk_sizes = [
      262144;]
};
[...]
 files = [
  {     file_network = BitTorrent
     file_size = 54143112
     file_priority = 0
     file_state = Downloading
     file_filename = "Dag Vag - Almanacka (1983)"
     file_age = 147002461
     file_primary = true
     file_swarmer = "./temp/BT-X34OR7VZKJDR3SL2QXT2BN2H2VXW4VYZ"
     file_mtime = 1147102580.
     file_chunks = "333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333303333333333333333333333333333333333333333333333333"
     file_present_chunks = [
      (0, 41156608);
      (41418752, 54143112)]
     file_downloaded = 53880968
[...]
     file_temp = "./temp/BT-X34OR7VZKJDR3SL2QXT2BN2H2VXW4VYZ"
     file_piece_size = 262144
     file_name = "Dag Vag - Almanacka (1983)"
     file_uploaded = 27230208
     file_id = X34OR7VZKJDR3SL2QXT2BN2H2VXW4VYZ
     file_trackers = [
      "http://tracker.prq.to/announce";]
---8<---

Adding togetrehr the size of all individual files in the entry above gives 54143112 wich corresponds exactly with "file_size".

When comparing the files in the directory "./temp/BT-X34OR7VZKJDR3SL2QXT2BN2H2VXW4VYZ" the only difference is that in the directory the file "09 - Dimma.mp3" is only 1290530 bytes.

Adding together the size of all files in the directory gives 53992068 bytes, wich coresponds exactly with "file_downloaded" in "files.ini".

Trying to find "58866719" (from the error message at the top) in "files.ini" I find an entry for another torrent with the same filename ("Dag Vag - Almanacka (1983)") and almost the same content, but with a different ID and temp dir.

For some reason the second entry has the same "file_swarmer" as the first even though the "file_id" and "file_temp" are different.

Some snippets from that files entries in "files.ini":

---8<---
 swarmers = [
  {     file_size = 58866719
     file_name = "./temp/BT-CNJUFHE26BBFTAG3Y4CBWHMDF6AHTCMH"
     file_bitmap = "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
     file_chunk_sizes = [
      262144;]
};
[...]
 files = [
  {     file_network = BitTorrent
     file_size = 54143112
     file_priority = 0
     file_state = Downloading
     file_filename = "Dag Vag - Almanacka (1983)"
     file_age = 147002461
     file_primary = true
     file_swarmer = "./temp/BT-X34OR7VZKJDR3SL2QXT2BN2H2VXW4VYZ"
     file_mtime = 1147102580.
     file_chunks = "333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333303333333333333333333333333333333333333333333333333"
     file_present_chunks = [
      (0, 41156608);
      (41418752, 54143112)]
     file_downloaded = 53880968
[...]
     file_temp = "./temp/BT-CNJUFHE26BBFTAG3Y4CBWHMDF6AHTCMH"
     file_piece_size = 262144
     file_name = "Dag Vag - Almanacka (1983)"
     file_uploaded = 0
     file_id = CNJUFHE26BBFTAG3Y4CBWHMDF6AHTCMH
     file_trackers = [
      "http://tracker.prq.to/announce";]
---8<---

Jonas Eckerman <jonas_e_se>
Wed 10 May 2006 11:29:24 AM UTC, comment #4: 

Please try the attached patch, it improves the error message
so you can check which file blocks MLDonkey start.

spiralvoice <spiralvoice>
Group administrator
Tue 09 May 2006 07:41:20 PM UTC, comment #3: 

I had the exact same problem as Sakari with 2.7.3. After upgrading to 2.7.5, the only thing that differs is the characters numbers. The error message now looks like this:

Exception: File "src/daemon/common/commonSwarming.ml", line 0, characters 594-2: Assertion failed while handling option:files
  in files.ini

This is after closing down mlnet by logging in through telnet and giving the command "kill".

I have never used the "merge" command AFAIK.

The 1006K big "files.ini" this is happening with is is available at:
http://mmm.truls.org/m/20060509_2123_files.ini.asis

I don't know anything at all about OCaml, but I do compile mlnet from source so if someone has some hints to flags or tests that could help in debugging this I'm willing to try them.

Jonas Eckerman <jonas_e_se>
Wed 22 Mar 2006 08:17:32 PM UTC, comment #2: 

did you use the "merge" command for some downloads?

spiralvoice <spiralvoice>
Group administrator
Thu 02 Mar 2006 04:49:04 PM UTC, comment #1: 

It seems I cannot attach <files.ini> because, even when compressed, it is over 512K.

Sakari Aaltonen <sakari>
Thu 02 Mar 2006 04:41:47 PM UTC, original submission:  

I killed mldonkey for a while to burn a CD-R. I had some 12 files downloading, some of them a week old. When I restarted mldonkey,
it quit immediately (no messages). Looking at file <mlnet.log>:
___________________________________________
sakari@gongli:~/.mldonkey$ tail mlnet.log
Aborting
.2006/03/02 16:19:06 Started logging...
Exception: File "src/daemon/common/commonSwarming2.ml", line 0, characters 571-2: Assertion failed while handling option:files
  in files.ini
Aborting
.2006/03/02 16:19:59 Started logging...
Exception: File "src/daemon/common/commonSwarming2.ml", line 0, characters 571-2: Assertion failed while handling option:files
  in files.ini
Aborting
sakari@gongli:~/.mldonkey$
_____________________________________________--_

The only solution I could think of was to delete file <files.ini>. Then, mldonkey would start again. Unfortunately, I lost everything I had downloaded.


Sakari Aaltonen       -email is unavailable-


Sakari Aaltonen <sakari>

 

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

No files currently attached

 

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

Date Changed by Updated Field Previous Value => Replaced by
2006-05-18 spiralvoice Reassign ItemFrom group mldonkey, a multi-networks file-sharing client, bugs tracker To group mldonkey, a multi-networks file-sharing client, patch tracker
2006-05-17 spiralvoice Severity3 - Normal 5 - Blocker
2006-05-10 jonas_e_se Attached File- Added testresult.txt, #9940
2006-05-10 spiralvoice Attached File- Added swarming_assert_verbose.patch, #9937

Back to the top

Powered by Savane 3.13-bb6a.
Corresponding source code