From owner-freebsd-java Mon Nov 29 1:51:40 1999 Delivered-To: freebsd-java@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id 88F7814E19 for ; Mon, 29 Nov 1999 01:51:36 -0800 (PST) (envelope-from K.J.Koster@research.kpn.com) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #35196) with ESMTP id <01JIWO1H8L8E0002XR@research.kpn.com> for freebsd-java@freebsd.org; Mon, 29 Nov 1999 10:51:35 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Nov 1999 10:51:34 +0100 Content-return: allowed Date: Mon, 29 Nov 1999 10:51:25 +0100 From: "Koster, K.J." Subject: Followup: appletvierer dies reproducably To: 'FreeBSD Java mailing list' Message-id: <59063B5B4D98D311BC0D0001FA7E45220FD060@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear FreeBSD Java, As promised I've sat down and made an attempt to isolate the crashing appletviewer bug. It seems to be related to memory management problems. Quite ironic that a java application dies on memory management, but that's a programmer's life for you. I reduced the applet to the merest splinter of what I had previously. I tested this on FreeBSD 3.3 stable, with the 1999-11-9 build of JDK 1.1.8. It dies quite reliably now. As a side note, it dies in the same way on a Sun Sparc, so I guess solving this problem is not really a FreeBSD java port issue. However, because of the more strict memory management that FreeBSD does, I believe that FreeBSD developers have an edge here. Create the four files that I quoted below. Run "make all", followed by "make client". An applet will start with two text fields. Don't touch the text fields, but click on the [Applet] meny item and select [Reload]. Repeat reloading the applet. On my system it dies after between two to five reloads. As you reload the applet, you may see malloc(3) complain about chunks being freed, or pages and chunks being moved. The JDK and FreeBSD clearly disagree on what proper memory management is: LikeEver% make client /usr/local/jdk1.1.8/bin/appletviewer GameClient.html java_X in free(): warning: chunk is already free. java_X in free(): warning: chunk is already free. The same behaviour I've observed in the GraphicsTest applet in the JDK demos, although it only reports chunks to be already free, and does not crash: LikeEver% cd /usr/local/jdk1.1.8/demo/GraphicsTest LikeEver% appletviewer example1.html java_X in free(): warning: chunk is already free. java_X in free(): warning: chunk is already free. java_X in free(): warning: chunk is already free. Any idea what I'm doing wrong? Kees Jan ==== - GameClient.html - ====

==== - GameClient.java - ==== import java.applet.Applet; public class GameClient extends Applet { public void init() { LoginPanel loginPanel = new LoginPanel(); add(loginPanel); } } ==== - LoginPanel.java - ==== import java.awt.Panel; import java.awt.TextField; public class LoginPanel extends Panel { public LoginPanel() { TextField userBox = new TextField(25); add(userBox); TextField passwordBox = new TextField(25); passwordBox.setEchoChar('*'); add(passwordBox); } } ==== - Makefile - ==== JAVA_HOME=/usr/local/jdk1.1.8 CLASSPATH=$(JAVA_HOME)/lib/classes.zip JAVA = $(JAVA_HOME)/bin/java JAVAC = $(JAVA_HOME)/bin/javac JAR = $(JAVA_HOME)/bin/jar RMIC = $(JAVA_HOME)/bin/rmic APPLET = $(JAVA_HOME)/bin/appletviewer all: rm -rf *.class $(JAVAC) -classpath $(CLASSPATH) -d . *.java client: GameClient.html $(APPLET) GameClient.html === To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message