aMule Forum
English => aMule News => Topic started by: Kry on January 18, 2006, 08:41:21 AM
-
Current CVS tarball does not compile on non-debug builds.
Along the next days, if I were you I would be VERY, VERY careful about using the CVS compialtions. I'm doing some big changes that can break from EC to downloading, uploading, or even the part files if we're so unlucky.
So please, keep that in mind.
-
It is nice that you inform us about this danger. Would you be "evil" ;) enough to inform us when the danger is gone?
-
Sure.
-
Originally posted by Kry
...does not compile on non-debug builds.
Little question: What builds are meant ?
-
--enable-optimize --disable-debug once
-
Actually, you can still use --enable-optimize, but --disable-debug will barf.
-
Just to be sure: this danger is over now, right?
-
No.
-
Is it over NOW?
And does it affect debian sarge's packages?
I just installed yesterday (2.1.1-2 IIRC) and the monolithic as well as the daemon version seem to run fine - except for amuleWEB.
Output shows the socket listening and so does netstat, but there is simply no response but no timeout either.
Rather after about 5min amuled exits with something like this :-)
Saving PartFile 39 of 39
All PartFiles Saved.
aMule shutdown completed.
aMule Version: aMuled 2.1.1 using wxGTK2 v2.6.2 (Unicoded)
Terminated after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
backtrace:
[2] ?? in amuled [0x8064dd8]
[3] wxEntry(int&, wchar_t**) in /usr/lib/libwx_baseu-2.6.so.0[0x401b32db]
[4] wxEntry(int&, char**) in /usr/lib/libwx_baseu-2.6.so.0[0x401b334d]
[5] ?? in amuled [0x8053908]
[6] __libc_start_main in /lib/tls/libc.so.6[0x4038b974]
[7] wxAppConsole::Initialize(int&, wchar_t**) in amuled[0x80537b1]
Sounds like my luck though, the second I try to install something it's in a broken state :-)
-
But there actually is some communication. From what I gather amuleWEB is ok but it's the EC component of amuled (and amule for that matter) that's screwed... Is that correct?
playground:~# tcpdump -ntvi eth0 | grep 4712
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
IP (tos 0x0, ttl 128, id 50965, offset 0, flags [DF], length: 40) 172.16.32.42.1365 > 172.16.32.253.4712: F [tcp sum ok] 2742359292:2742359292(0) ack 384643285 win 65535
IP (tos 0x0, ttl 64, id 57334, offset 0, flags [DF], length: 40) 172.16.32.253.4712 > 172.16.32.42.1365: F [tcp sum ok] 1:1(0) ack 1 win 6432
IP (tos 0x0, ttl 128, id 50966, offset 0, flags [DF], length: 40) 172.16.32.42.1365 > 172.16.32.253.4712: . [tcp sum ok] ack 2 win 65535
IP (tos 0x0, ttl 128, id 50983, offset 0, flags [DF], length: 48) 172.16.32.42.1395 > 172.16.32.253.4712: S [tcp sum ok] 3801684527:3801684527(0) win 65535
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 48) 172.16.32.253.4712 > 172.16.32.42.1395: S [tcp sum ok] 1070212150:1070212150(0) ack 3801684528 win 5840
IP (tos 0x0, ttl 128, id 50984, offset 0, flags [DF], length: 40) 172.16.32.42.1395 > 172.16.32.253.4712: . [tcp sum ok] ack 1 win 65535
IP (tos 0x0, ttl 128, id 50985, offset 0, flags [DF], length: 450) 172.16.32.42.1395 > 172.16.32.253.4712: P 1:411(410) ack 1 win 65535
IP (tos 0x0, ttl 64, id 1496, offset 0, flags [DF], length: 40) 172.16.32.253.4712 > 172.16.32.42.1395: . [tcp sum ok] ack 411 win 6432
-
Originally posted by dukeofnukem
Is it over NOW?
Doesn't look like that.
Originally posted by dukeofnukem
And does it affect debian sarge's packages?
It depends on which ones you are using. There are different ones. Some of them are built from released sources and others are built from CVS.
Originally posted by dukeofnukem
I just installed yesterday (2.1.1-2 IIRC) and the monolithic as well as the daemon version seem to run fine - except for amuleWEB.
2.1.1 is a released version - this topic is about CVS tarballs.
As far as it concerns the crash log: That belongs into the crashes forum.