bugmldonkey, a multi-networks file-sharing client - Bugs: bug #21172, MLDonkey crashes on 64bit archs...

 
 

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

bug #21172: MLDonkey crashes on 64bit archs when compiled with Ocaml 3.10.0

Submitted by:  Emmet Brown <chatmann>
Submitted on:  Thu 27 Sep 2007 08:03:00 PM UTC  
 
Category:  Core Severity:  5 - Blocker
Item Group:  Segmentation Fault Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  Release:  2.9.2
Operating System:  Linux Binaries Origin:  None
CPU type:  x86_64

( Jump to the original submission)

Mon 24 Dec 2007 07:02:54 AM UTC, comment #34: 

It's been running for nearly three days now with moderate activity, built using CVS ocaml from the "release310" tag updated on Dec 20. No new core dump was produced. Looks better!

Thomas Klausner <tk>
Sun 16 Dec 2007 01:59:27 PM UTC, comment #33: 

@tk: Did you test the MLDonkey with the new Ocaml CVS snapshot already?

spiralvoice <spiralvoice>
Project Administrator
Wed 28 Nov 2007 11:38:24 PM UTC, comment #32: 

Ok, it seems everything is fine with ocaml 3.10.1+dev2. I'll report any issue anyway, but heavy loads over long time do not seem to trigger a segfault anymore!

Cool!

Chris.

Emmet Brown <chatmann>
Sun 25 Nov 2007 07:15:28 PM UTC, comment #31: 

Some fixes were applied to Ocaml 3.10 branch, please
test Ocaml 3.10.1+dev2 (2007-11-20)

cvs -d:pserver:anoncvs@camlcvs.inria.fr:/caml login
cvs -z3 -d:pserver:anoncvs@camlcvs.inria.fr:/caml co -P -r release310 ocaml
cd ocaml
./configure
make world.opt
make install

and re-compile MLDonkey with it. You may have to use
./configure --enable-ocamlver=3.10
for MLDonkey.

spiralvoice <spiralvoice>
Project Administrator
Sun 25 Nov 2007 03:13:04 PM UTC, comment #30: 

I'm seeing core dump problems on NetBSD-current/amd64.

Some remarks:
It doesn't seem to happen when I'm only using torrents.
It does happen when I'm only using donkey or a mix of donkey and torrents.

Sometimes there are many crashes in a row when it is in the process of finishing a download. It does happen in between too, however.

It happens much more often for popular files with many peers.

I build mlnet with ./configure --enable-pthread-lib --enable-gui=newgui2 --disable-gd --with-libiconv-prefix=/usr/pkg
in case it matters. It also happens with --enable-minimum.

Thomas Klausner <tk>
Mon 05 Nov 2007 10:21:54 PM UTC, comment #29: 

Hi,
still the same behaviour. I have run a few more times the thing and it seems that duplicate chunks are received even if the file is not bound to be committed (dunno if what I am saying make sense...): the crash then occurs when some of these connections are closed?

I have attached a last 10s log when verb is set to all and with the "disconnect" patch. All the others look pretty like the same, with always the "fallback to linear strategy" and the basicSocket CLOSING at the end with always a few "ALREADY RECEIVED" around.

Chris.

(file #14307)

Emmet Brown <chatmann>
Sun 04 Nov 2007 08:21:03 PM UTC, comment #28: 

Updated crash_debug.patch

I changed the way the client is disconnected after receiving
data for an already finished file, see the patch in donkeyOneFile.ml

@@ -301,8 +348,12 @@
 (*                connection_delay c.client_connection_control; *)
                 match c.client_source.DonkeySources.source_sock with
                   Connection sock ->
+lprintf_nl "debug get_from_client, disconnect %s" (full_client_identifier c);
+                    disconnect_client c (Closed_for_error (Printf.sprintf "No file to download from %s" (full_client_identifier c)));
+(*
                     TcpBufferedSocket.close sock
-                      (Closed_for_error "No file to download");
+                      (Closed_for_error (Printf.sprintf "No file to download from %s" (full_client_identifier c)));
+*)
                 | _ -> ()
               end

Here I am using function "disconnect_client" instead of TcpBufferedSocket.close. I do not know if this fixes the bug,
which is not present when using Ocaml < 3.10, but its worth a try.

(file #14296)

spiralvoice <spiralvoice>
Project Administrator
Sun 04 Nov 2007 07:52:44 PM UTC, comment #27: 

Thanks for the explanations, I'll monitor the thing then.

Indeed, this file was committed a few minutes before the crash:

2007/11/04 11:03:43 [Ux32] Exception in FDCache.mtime64 temp/urn_ed2k_xxx: stat failed on temp/urn_ed2k_xxx: No such file or directory
2007/11/04 11:03:43 [EDK] Share: Trying mtime on new name incoming/files/lodt, disk_name temp/urn_ed2k_xxx
2007/11/04 11:03:43 [Ux32] Open incoming/files/ xxx (ro)
2007/11/04 11:03:43 [Ux32] Close incoming/files/xxx
2007/11/04 11:03:43 [EDK] Remember incoming/files/xxx
2007/11/04 11:03:43 [cSha] sharing incoming/files/xxx
2007/11/04 11:03:43 [Ux32] Close incoming/files/xxx
2007/11/04 11:03:43 [EDK] op_network_share: Sharing incoming/files/xxx
2007/11/04 11:03:43 [EDK] donkeyShare: Using old MD4s for incoming/files/xxx
2007/11/04 11:03:43 [EDK] Sharing file with MD4: 2261F4F6428DCE5E7B8499EDE2AA356F
2007/11/04 11:03:43 [EDK] New file with changed filename temp/urn_ed2k_2261F4F6428DCE5E7B8499EDE2AA356F to incoming/files/xxx
2007/11/04 11:03:43 [Ux32] Open incoming/files/xxx (rw)
2007/11/04 11:03:43 [cSha] NEW SHARED shared2/xxx/incoming/files/xxx

and actually, the last "fallback to linear strategy" was also concerning that file. A few seconds before:

2007/11/04 11:03:36 [cSw] select_block: fallback to linear strategy for file temp/urn_ed2k_xxx
2007/11/04 11:03:36 [cSw] debug1 linear_select_blocks temp/urn_ed2k_xxx
2007/11/04 11:03:36 [cSw] debug3 linear_select_blocks iter_complete temp/urn_ed2k_xxx
2007/11/04 11:03:36 [cSw] debug3 linear_select_blocks iter_complete temp/urn_ed2k_xxx
2007/11/04 11:03:36 [cSw] debug3 linear_select_blocks iter_complete temp/urn_ed2k_xxx
...
...
2007/11/04 11:03:36 [cSw] debug3 linear_select_blocks iter_complete temp/urn_ed2k_xxx
2007/11/04 11:03:36 [cSw] debug3 linear_select_blocks iter_complete temp/urn_ed2k_xxx
2007/11/04 11:03:36 [cSw] debug3 linear_select_blocks iter_complete temp/urn_ed2k_xxx
2007/11/04 11:03:36 [cSw] debug3 linear_select_blocks iter_complete temp/urn_ed2k_xxx
2007/11/04 11:03:36 [cSw] debug2 linear_select_blocks iter_partial temp/urn_ed2k_xxx

Emmet Brown <chatmann>
Sun 04 Nov 2007 07:24:57 PM UTC, comment #26: 

Small excerpt of your log, I filtered by IP 189.4.147.168

This client uploads data to your MLDonkey:

2007/11/04 11:04:06 [EDK] Message from 189.4.147.168:45005(31) (eMU 0.48a) 'LAP-Alien'
2007/11/04 11:04:06 [EDK] EmuleCompressedPart for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 582615040 184299 len 10841
2007/11/04 11:04:07 [EDK] Message from 189.4.147.168:45005(31) (eMU 0.48a) 'LAP-Alien'
2007/11/04 11:04:07 [EDK] EmuleCompressedPart for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 582615040 184299 len 10841
2007/11/04 11:04:10 [EDK] Message from 189.4.147.168:45005(31) (eMU 0.48a) 'LAP-Alien'
2007/11/04 11:04:10 [EDK] EmuleCompressedPart for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 582615040 184299 len 10841
2007/11/04 11:04:11 [EDK] Message from 189.4.147.168:45005(31) (eMU 0.48a) 'LAP-Alien'
2007/11/04 11:04:11 [EDK] EmuleCompressedPart for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 582615040 184299 len 10841
2007/11/04 11:04:13 [EDK] Message from 189.4.147.168:45005(31) (eMU 0.48a) 'LAP-Alien'
2007/11/04 11:04:13 [EDK] EmuleCompressedPart for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 582615040 184299 len 10841
2007/11/04 11:04:15 [EDK] Message from 189.4.147.168:45005(31) (eMU 0.48a) 'LAP-Alien'
2007/11/04 11:04:15 [EDK] EmuleCompressedPart for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 582615040 184299 len 10843
2007/11/04 11:04:15 [EDK] Complete compressed block received!

Now one block (180kb) was completely received.

2007/11/04 11:04:15 [EDK] Decompressed: 184320/184299
2007/11/04 11:04:15 [EDK] debug1 block_received from 189.4.147.168:45005(31) (eMU 0.48a) 'LAP-Alien', md4 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2007/11/04 11:04:15 [cSw] received on 582615040-582799360
Dismiss unwanted data from 2209 for lodt.dat: 582615040-582799360
2007/11/04 11:04:15 [cSw]   received: file_pos:582615040 string:0 184320
2007/11/04 11:04:15 [cSw]   ranges:

But the file was already completed. Can you check when this happened?

2007/11/04 11:04:15 [cSw] received: wrong file state FileShared for temp/urn_ed2k_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2007/11/04 11:04:15 [EDK] ALREADY RECEIVED: 0 < 184320
2007/11/04 11:04:15 [cSw] find_range: file temp/urn_ed2k_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx in bad state FileShared
2007/11/04 11:04:15 [bS] CLOSING: FD donkey client connection:18 (error No file to download from 189.4.147.168:45005(31) (eMU 0.48a) 'LAP-Alien')

Then the connection to this client is closed and apparently this
leads to a crash of MLDonkey. Could you please continue to
monitor your MLDonkey for future crashes and control if this
behaviour is the real reason for the crashes?
This might happen after committing a file, because MLDonkey
always asks several clients for the last chunk so its normal
to receive this data from more than one client, this is a likely
case for well-spread files.

spiralvoice <spiralvoice>
Project Administrator
Sun 04 Nov 2007 06:32:03 PM UTC, comment #25: 

Here it is. This time, the fallback to linear strategy is like 2mn before the crash and does not appear in the last 10s. Let me know if you want more logs, I have 1Gb of logs :)

(file #14295)

Emmet Brown <chatmann>
Sat 03 Nov 2007 09:57:57 PM UTC, comment #24: 

Attached crash_debug.patch, please apply to 2.9.2 and post the last 10s before a crash.

(file #14286)

spiralvoice <spiralvoice>
Project Administrator
Sat 03 Nov 2007 02:36:25 PM UTC, comment #23: 

With set vorbosity "all", there is an additional line at the end of the log. This is with the 2.9.2 version. I also note that I get the crash more often on heavy load.

2007/11/03 14:27:11 [cSw] Files:
2007/11/03 14:27:11 [cSw]   File num: 14
2007/11/03 14:27:11 [cSw]   primary
2007/11/03 14:27:11 [cSw]   Downloaded: 488271872
2007/11/03 14:27:11 [cSw]   Bitmap: 30000000000003300003333300000000000000300000000000030000000000000030000000000000000000000000300000000003000300330000000000300000000000000033300000000000333000003000300003000000000000000100003330000000033000000000000033300000003000000033000333330000013003333333
2007/11/03 14:27:11 [cSw] select_block: fallback to linear strategy
2007/11/03 14:27:11 [bS] CLOSING: FD donkey client connection:14 (error No file to download)

Emmet Brown <chatmann>
Sat 03 Nov 2007 12:11:39 PM UTC, comment #22: 

I forgot to attach 6005_remove.patch, but as 2.8.7 crashes as well, its not needed. I guess there is a deeper problem in either MLDonkey or Ocaml 3.10.0, where I still do not know.

When you increase verbosity to "all", is "fallback to linear strategy" still the last log line before the crash?

spiralvoice <spiralvoice>
Project Administrator
Sat 03 Nov 2007 10:48:58 AM UTC, comment #21: 

Other news: exactely the same crash with mlnet 2.8.7 compiled with ocaml 3.10.0! Last line in log still "fallback to linear strategy".

Chris.

Emmet Brown <chatmann>
Sat 03 Nov 2007 01:00:08 AM UTC, comment #20: 

I can already confirm that the last line in mlnet.log after a second crash is always:

2007/11/02 22:06:22 [cSw] select_block: fallback to linear strategy

Chris.

PS: I do not see yet the patch 6005_remove.patch

Emmet Brown <chatmann>
Fri 02 Nov 2007 01:48:12 PM UTC, comment #19: 

For further testing I attached file 6005_remove.patch
It must be applied to MLDonkey 2.9.2 and removes the
code provided by patch 6005.

spiralvoice <spiralvoice>
Project Administrator
Thu 01 Nov 2007 01:41:06 PM UTC, comment #18: 

Hi,
I was not aware of the "download_order" command, so if it is not activated somehow I certainly never used it.
I'll test with 2.8.7 compiled with ocaml 3.10.0, as the logs.

Thanks,
Chris.

Emmet Brown <chatmann>
Thu 01 Nov 2007 01:24:47 PM UTC, comment #17: 

Can you, or other people having the problem, confirm
that the last log message before the crash is always:

2007/10/31 12:57:18 [cSw] select_block: fallback to linear strategy

Until now I thought, based on reports I received, that the problem
is related to the commit process, which seems not to be the case.

This command was added to MLDonkey 2.9.0:

6005: Swarmer: Implement new download mechanism
- its now possible to switch the order blocks are downloaded from random
  (first and last block first, default) to linear
- new command: download_order <file number> <random|linear>

Do you use it?

MLDonkey 2.8.7 can also be compiled with Ocaml 3.10.0,
does it crash as well?

spiralvoice <spiralvoice>
Project Administrator
Thu 01 Nov 2007 12:47:45 PM UTC, comment #16: 

Attached the last 10s.
In fact, it seems that no file finished to be downloaded at the crash time in the sense that the incoming directory did not contain any new file.

The first file committed after restarting mlnet was urn_ed2k_71F3339003DE55638FEBBAA8E1832B6B, the same verified at 2007/10/31 12:57:18. But it was committed like 6hours later.

Chris.

(file #14269)

Emmet Brown <chatmann>
Thu 01 Nov 2007 12:03:47 AM UTC, comment #15: 

Which file finished and caused the crash?
Could you provide more lines of mlnet.log,
at least 10s before the crash?

spiralvoice <spiralvoice>
Project Administrator
Wed 31 Oct 2007 11:57:17 PM UTC, comment #14: 

Ok, I did not manage to crash it again with little files, even with a bunch of them. But, on big files, the segfault appears again.
Hopefully this time, I use both the patch and the relevant set verbosity... Attached the tail of mlnet.log till the segfault.

Chris.

(file #14267)

Emmet Brown <chatmann>
Sun 28 Oct 2007 06:54:41 PM UTC, comment #13: 

Please try to reproduce the crash with

- set verbosity "verb share file md4 swarming"
- and the patch applied

Your last test was without the extended verbosity settings.
One user from IRC said that crashes occured with files
having non-ASCII chars in the filename.

spiralvoice <spiralvoice>
Project Administrator
Sun 28 Oct 2007 03:20:07 PM UTC, comment #12: 

So, it did not crash at commit of the ed2k link (dear!) and for a fresh directory, here the log. I'll try with more little files.

2007/10/28 11:59:08 [cCO] Options correctly saved
2007/10/28 12:14:08 [cCO] Options correctly saved
2007/10/28 12:29:08 [cCO] Options correctly saved
2007/10/28 12:44:08 [cCO] Options correctly saved
2007/10/28 12:59:08 [cCO] Options correctly saved
2007/10/28 13:14:08 [cCO] Options correctly saved
2007/10/28 13:29:08 [cCO] Options correctly saved
2007/10/28 13:44:08 [cCO] Options correctly saved
2007/10/28 13:59:08 [cCO] Options correctly saved
2007/10/28 14:14:08 [cCO] Options correctly saved
2007/10/28 14:29:08 [cCO] Options correctly saved
2007/10/28 14:44:08 [cCO] Options correctly saved
2007/10/28 14:59:08 [cCO] Options correctly saved
2007/10/28 15:02:24 [cInt] debug1 start file_commit of eMule0.48a-Installer.exe
2007/10/28 15:02:24 [cInt] debug2 file_commit - before move
2007/10/28 15:02:24 [cInt] debug3 file_commit - after move - before file_completed_cmd
2007/10/28 15:02:24 [cInt] debug4 file_commit - after file_completed_cmd - before destroy fd
2007/10/28 15:02:24 [cInt] debug5 file_commit - after destroy fd
2007/10/28 15:02:24 [cInt] debug6 file_commit - before op_file_commit
2007/10/28 15:02:24 [cInt] debug7 file_commit - after op_file_commit - before new_shared
2007/10/28 15:02:24 [cInt] debug8 file_commit - after new_shared - before update_file_state
2007/10/28 15:02:24 [cInt] debug9 file_commit - after update_file_state
2007/10/28 15:02:24 [cInt] debug10 file_commit
2007/10/28 15:02:24 [cInt] debug11 file_commit - before commit secondaries
2007/10/28 15:14:08 [cCO] Options correctly saved
2007/10/28 15:29:08 [cCO] Options correctly saved
2007/10/28 15:44:08 [cCO] Options correctly saved
2007/10/28 15:59:08 [cCO] Options correctly saved
2007/10/28 16:14:08 [cCO] Options correctly saved

Emmet Brown <chatmann>
Sat 27 Oct 2007 09:13:56 PM UTC, comment #11: 

The backtrace is already known to me, but does not help much.
Could you try again with Ocaml 3.10.0-compiled MLDonkey, but
use it in a clean $MLDONKEY_DIR and download only one file, like

ed2k://|file|eMule0.48a-Installer.exe|3858985|455361F9D95C3CD7E6BF2192D1CB3D02|/

The verbosity log output should then only concern the one file and
I hope MLDonkey will crash during its download;-)

spiralvoice <spiralvoice>
Project Administrator
Sat 27 Oct 2007 08:54:42 PM UTC, comment #10: 

So, I compiled with --enable-debug and ran mlnet in gdb. The segfault occurs in gdb as

[New Thread 1082132816 (LWP 21671)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47494811358320 (LWP 21667)]
0x000000000050498d in camlDonkeyProtoCom__fun_1250 ()

a "list" command gives:
 1 in rtld.c

Concerning the log file, I set the verbosity as you suggested but there is nothing more than a long list of message like the following ones:

2007/10/27 21:32:02 [cSw] received on 217917440-217927680
2007/10/27 21:32:02 [Ux32] really_write temp/urn_ed2k_... 217917440 10240
2007/10/27 21:32:02 [cSw] received on 217835520-217845760
2007/10/27 21:32:02 [Ux32] really_write temp/urn_ed2k_... 217835520 10240
2007/10/27 21:32:03 [Ux32] really_read temp/urn_ed2k_38083174A70383A6564B08DCE2BE4F64 4574576640 10240
2007/10/27 21:32:04 [Ux32] really_read
2007/10/27 21:32:04 [cSw] received on 217845760-217856000
2007/10/27 21:32:04 [Ux32] really_write temp/urn_ed2k_... 217845760 10240
2007/10/27 21:32:05 [Ux32] really_read temp/urn_ed2k_... 1457369501 10240
2007/10/27 21:32:05 [cSw] received on 217927680-217937920
2007/10/27 21:32:05 [Ux32] really_write temp/urn_ed2k_... 217927680 10240

Emmet Brown <chatmann>
Mon 22 Oct 2007 10:08:28 PM UTC, comment #9: 

I expected some log output, related to the commit process because the error is reported to happen during commit, but it seems to take
place in another section of the code.

Please enable these verbosity options:

set verbosity "verb share file md4 swarming"

and let MLDonkey crash again. For testing it would be a good
idea to create a test setup and download only cue files or
other small stuff.

Please the logout output before which lead up to the crash,
at least the last 100 lines but remove any data about the files
used.

spiralvoice <spiralvoice>
Project Administrator
Mon 22 Oct 2007 01:37:51 PM UTC, comment #8: 

Hi,
I tested more carefully mlnet compiled with ocaml 3.10.0, patch applied. So I am getting the segfaults of mlnet before any commit.

mlnet[14621] general protection rip:505825 rsp:73835c error:0

I don't know if this is expected, but even with the patch, there is nothing more than usual in the log file (mlnet.log).

Chris.

Emmet Brown <chatmann>
Sat 20 Oct 2007 09:11:04 PM UTC, comment #7: 

This is a known bug, confirmed present on Linux/NetBSD@64bit
when MLDonkey is compiled with Ocaml 3.10.0.

Please compile MLDonkey with the attached patch to return
debug information in log_file about the commit process.

(file #14173)

spiralvoice <spiralvoice>
Project Administrator
Sat 20 Oct 2007 12:43:19 PM UTC, comment #6: 

I use Ocaml 3.10.0, I didnt't try with 3.9.3 yet.

Anyway, the crashes are, for me, exactly related when MLdonkey tries to commit a finish download. But only a ed2k download (bittorrent works fine).

Christophe <kitof>
Sat 20 Oct 2007 12:26:23 PM UTC, comment #5: 

Okay, so after 2 days mlnet compiled with ocaml 3.09.3 seems to work fine. A few downloads were also committed without trouble during that period.

Concerning ocaml 3.10.0, I don't think the errors occurred at commit times, I had more segfaults than commits. I can test that more carefully if needed.

Chris.

Emmet Brown <chatmann>
Sat 20 Oct 2007 12:03:00 PM UTC, comment #4: 

Are the crashes on x86_64 related to a time when
MLDonkey tries to commit a finished download?

spiralvoice <spiralvoice>
Project Administrator
Thu 18 Oct 2007 06:19:17 PM UTC, comment #3: 

Hi,
the issue was for mlnet compiled with ocaml 3.10.0.
I am just trying with 3.09.3 and waiting the crash. I'll report in a few hours, or luckily days if this works!

Cheers,
Chris.

Emmet Brown <chatmann>
Thu 18 Oct 2007 09:52:28 AM UTC, comment #2: 

Which Ocaml version do you both use?
Please test with 3.10.0 and 3.09.3

spiralvoice <spiralvoice>
Project Administrator
Wed 17 Oct 2007 09:31:37 AM UTC, comment #1: 

I confirme. Exactly same trouble here since 2.9.0 on x86_64.

I can make some tests if needed.

Christophe <kitof>
Thu 27 Sep 2007 08:03:00 PM UTC, original submission:  

Hi guys,
just wanted to report this issue on x86_64. If this is due to some misconfig from myself, apologizes.

However I tried from binary rpm or compiled by myself, after a few tens of minutes mlnet crashes with this error; and always the same number in rip and rsp. This thing is actually there at least from 2.9.0. My previous version was 2.8.5 which was fine.

Let me know if need more tests.

Thanks,
Chris.

Emmet Brown <chatmann>

 

Attached Files
file #14307:  mlnet5_10s.log added by chatmann (227KiB - text/x-log - last 10s mlnet 2.9.2 updated crash_debug.patchy + verb all)
file #14296:  crash_debug.patch added by spiralvoice (17KiB - text/x-diff)
file #14295:  mlnet2_10s.log added by chatmann (241KiB - text/x-log - last 10s of mlnet 2.9.2 + crash_debug_patch + set verbosity "all")
file #14269:  mlnet_10s.log added by chatmann (29KiB - text/x-log)
file #14267:  mlnet_tail.log added by chatmann (15KiB - text/x-log - tail of mlnet.log with set verbosity, just before crash.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tk (Posted a comment)
  • -email is unavailable- added by spiralvoice (Posted a comment)
  • -email is unavailable- added by kitof (Posted a comment)
  • -email is unavailable- added by chatmann (Submitted the item)
  • -email is unavailable- added by chatmann
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 18 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-01-08 spiralvoice Open/ClosedOpen => Closed
    2007-12-27 spiralvoice StatusNeed Info => Fixed
        Summarymlnet[pidnumber] general protection rip:50498d rsp:7377cc error:0 => MLDonkey crashes on 64bit archs when compiled with Ocaml 3.10.0
    2007-11-05 chatmann Attached File- => Added mlnet5_10s.log, #14307
    2007-11-04 spiralvoice Attached File- => Added crash_debug.patch, #14296
    2007-11-04 spiralvoice Attached File#14286 => Removed
    2007-11-04 chatmann Attached File- => Added mlnet2_10s.log, #14295
    2007-11-03 spiralvoice Attached File- => Added crash_debug.patch, #14286
    2007-11-03 spiralvoice Attached File#14173 => Removed
    2007-11-03 spiralvoice Release2.9.1 => 2.9.2
    2007-11-01 chatmann Attached File- => Added mlnet_10s.log, #14269
    2007-10-31 chatmann Attached File- => Added mlnet_tail.log, #14267
    2007-10-22 spiralvoice Severity3 - Normal => 5 - Blocker
    2007-10-20 spiralvoice Release2.9.1 =>
        ReleaseNone => 2.9.1
    2007-10-20 spiralvoice Attached File- => Added commit_3100_debug.patch, #14173
    2007-10-20 spiralvoice StatusNone => Need Info
    2007-09-27 chatmann Carbon-Copy- => Added dirteat@gmail.com

    Back to the top


    Powered by Savane 3.5