From owner-freebsd-java Thu Oct 29 09:05:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA17220 for freebsd-java-outgoing; Thu, 29 Oct 1998 09:05:55 -0800 (PST) (envelope-from owner-freebsd-java@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA17210; Thu, 29 Oct 1998 09:05:38 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA23930; Thu, 29 Oct 1998 10:05:36 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA16987; Thu, 29 Oct 1998 10:05:35 -0700 Date: Thu, 29 Oct 1998 10:05:35 -0700 Message-Id: <199810291705.KAA16987@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mahadevan Iyer Cc: java-port@FreeBSD.ORG, freebsd-java@FreeBSD.ORG, saurabh@internetdevices.com, namit@internetdevices.com Subject: Re: Possible Bug in JVM socket code on FreeBSD, java.net.Socket In-Reply-To: <36381ADB.DCCDAB3D@internetdevices.com> References: <36381ADB.DCCDAB3D@internetdevices.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I have a simple Server and Client pair > Server listens for connections on fixed port > Clients connect to the server on the port > > The Client opens N connections to the server and keeps them open > The Server sends data on each of these connections > The Client listens for data on each of these connections in a single > thread > > N > 250 causes the Client to dump core I can verify that this bug does indeed exist in the FreeBSD JDK. However, I do not (yet) have any idea why. It's happening inside the OS dependant socket code, but I haven't yet figured out why. *IF* I run the program with 'java_g -t' (tracing), it works with more connections, but that changes the timing quite a bit (it's ALOT slower) and can possibly be using different compiler optimization which might cause the program to act differently. I'll keep looking into it, since this behavior is critical to the success of my product. Ahh, I just tested with a larger value, and it blows up. Unfortunately, it doesn't tell me why it's dying, since it appears that it might be dying in the call itself. :( More later. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message