Date: Sat, 06 Sep 2008 23:57:44 +0200 From: Marcin Cieslak <saper@system.pl> To: freebsd-java@freebsd.org Cc: "Marc G. Fournier" <scrappy@hub.org>, Andreas Rudisch <"cyb."@gmx.net> Subject: Re: Azureus + 7-STABLE == Slow download + No Upload - some idea Message-ID: <48C2FCD8.5010005@system.pl> In-Reply-To: <20080402064543.GA30534@misty.eyesbeyond.com> References: <24A133A6EE9DA04411B3CF04@ganymede.hub.org> <20080401161800.1c4ee021.cyb.@gmx.net> <B335041FDD843616D119BCBB@ganymede.hub.org> <20080402064543.GA30534@misty.eyesbeyond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig284687ADA857B34375A8A090 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable Greg Lewis wrote: > On Tue, Apr 01, 2008 at 09:04:46PM -0300, Marc G. Fournier wrot >>> On FreeBSD 6.1/2/3 Azureus shows the same behaviour (at least on my P= C) >>> when _not_ using /etc/libmap.conf to map libthread to libc_r. >>> >>> Work-arounds like using other clients are one thing, but I would like= >>> to see a fix for this on FreeBSD 7. Is there anything that can be don= e >>> to help identify / solve the problem? > The reason that we've persisted with doing patchsets for Java is so tha= t > everybody can get at the source and investigate/fix things which are > important to them. I've persistently argued against switching solely t= o > binary releases, when that has come up, for just this reason. Greg and friends, I have taken the opportunity to look at the source and compile jdk16=20 with debug patches to investigate. Thanks for providing us possibility=20 to do this for years already. > None of this will even require getting your hands dirty with the code,= it > will just take some time commitment to do it and analyse the results. There was another, simple problem report on the freebsd-java: http://thread.gmane.org/gmane.os.freebsd.devel.java/10146 > If you wanted to go further you could start trying to mess around with > gdb and/or trace statements in the code. I have decided to go dirty anyway :) I have traced this a bit and came up with a testcase code to open a UDP=20 IPv4 connection via the IPv6 socket: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/127057 This testcase is the way JDK16 does UDP connection translated to C code=20 (okay, Java sets first bytes of the sockaddr * structures to zero, but=20 this doesn't matter and doesn't change anything). Either: 1) something is wrong in this code and Java should be fixed (something=20 around: j2se/src/solaris/native/java/net/PlainDatagramSocketImpl.c=20 j2se/src/solaris/native/java/net/net_util_md.c 2) there is wrong in the UDP in the kernel. Even worse, EINVAL is not=20 documented in the manpage, but is returned by udp6_sendto and friends. I've had difficulty single-stepping the kernel but maybe there is=20 something in here. Can anyone replicate my results (I am running an amd64 machine, but this = code gives me the same result on a i386 machine installed from the same=20 codebase)? --Marcin --------------enig284687ADA857B34375A8A090 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQCVAwUBSML83j2W2v2wY27ZAQMcNwP+JiESyZMZYJJVQQAaCtR0Z/qvPpOjc1vG RWGETx+0CxVQXUva3YpAEH48H3UGoQr9d2DxRFnzcyvqzRIygxEJFh8jyaBYKCnT Kjjd6d4WdOOx37pqq4+RzekDIUQRrmLe2DtR5pwS268P4syDqj5fi/dUOxtm7Sgi bglTcIN2wkg= =wATK -----END PGP SIGNATURE----- --------------enig284687ADA857B34375A8A090--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48C2FCD8.5010005>