This section attempts to answer your initial questions when you're trying to solve problems with the Blackdown JDK. Last Update

$Id: 04-trouble.sgml,v 1.2 1998/11/13 02:50:16 stevemw Exp $ Typical Questions to Ask Yourself When Debugging Problems

Does your system hardware and software satisfy the minimum requirements? See section . Are you running the current version? You can find that information in section . Have you checked to see if your libc, glibc, and X11 libraries could be the problem? See section . If you learn something we can add to there, please post them! Environment Variables. Here are the top candidates for problems: CLASSPATH Should either be unset or start with .:$JAVA_HOME/lib/classes.zip. PATH Should include $JAVA_HOME/bin -- ahead of /usr/bin where Kaffe often lives, please! JAVA_HOME This should be set to your top-level JDK directory. JDK_HOME Although the JDK doesn't need this, it ought to be set to your top-level JDK directory (if at all). HotJava uses this environment variable, as do other packages other than the JDK. Are all the required X11 fonts installed? This is a subtle area of concern. People have experienced crashes from not having 75dpi fonts installed. Are your font and localization properties correct? Another area that is difficult to troubleshoot. I hope to add more information here soon! Kaffe and the Blackdown JDK 1.1 are Installed. Neither Work!

After running

javac HelloWorld.java

and seeing this message:

Failed to open object 'HelloWorld/java'

Other people have reported error messages such as these: $ javac Failed to locate native library in path: /usr/lib Aborting. reports: ...The javac which was giving the problem was /usr/bin/javac, that is the kaffe javac. Now that I moved $JAVA_HOME/bin ahead in my $PATH, both javac and java work, and I see a wonderful "Hello, World!". In other words, always check for conflicting environment variable problems. For details on how to do this, see section .

A very common cause for problems with Kaffe is having /usr/bin in your path ahead of $JAVA_HOME/bin. I Have the Blackdown JDK 1.1.x and RMI is Giving Me Fits!

reports that running the Blackdown JDK 1.1.5v7libc works better than the glibc version, and forwards this advice from : The problem is related to naming in /etc/hosts. This is a known Java problem in picking up the right name for the interface. Change the localhost name to your real machine name. This may cause problems with talk though ... Help, I've Upgraded to ld.so-1.9.9 and Now the JDK Coredumps!

Slackware users have found that removing the libdl.so.* and libc.so.* files from $JAVA_HOME/lib/i386/green_threads takes care of this problem. We don't know what causes it yet, though. Help, Java Said it Ran out of Memory!

You have two strong candidates as causes for this problem. Your program needs more than the default that the JVM allows. Memory limits can be set like this: java -ms16m -mx64m .... From the JDK documentation: -ms<number> set the initial Java heap size -mx<number> set the maximum Java heap size You actually don't have enough virtual memory (the total of physical RAM and swap space) available. The free command can help you there. See the manual page for free(1). For the current minimum system requirements, see the discussion of them in section . How Do I Add Swap Space?

See the manual pages for swapon(8) and mkswap(8). Where Can I Report Bugs?

Karl Asha has setup a problem-report form at . Please report problems by filling this in as best you can. There are some guidelines for this in section .

Before submitting a bug, you may be able to help by visiting Javasoft's Bug Parade at and checking for related problems. If you mention a bug from a JDC bug ID in your problem report, it can help Blackdown JDK developers. At this time, you will have to join the JDC in order to search this database.

As usual, feel free to open a discussion about your problems on the mailing list. What Should I Report?

Although it may not seem so, solving Linux JDK problems can sometimes be difficult because of the large variation of systems that are in use. Please do your best when reporting a bug to tell us all about your system, the code you're running, and anything else that can help. Here's a checklist of items to mention. A careful synopsis of the problem. Which JDK you're using. Type java -version to see. Your Linux distribution (i.e. RedHat) and its version. The LibC version you're using. Type ldconfig -D 2>&1 | grep libc | tail -1 to see. The loader you're running. Type ldconfig -D 2>&1 | grep ld | tail -1 to see. . Type xdpyinfo | grep 'release number' to see. The version of the Linux kernel you're running. Type uname -r to see. if you've found one. A URL where with some related Java code or binary data. Your assessment of the problem's priority. Are There Any Debugging Techniques I Can Try Myself?

Try running the JDK java, appletviewer, and javac wrapper scripts like this:

$ sh -x $JAVA_HOME/bin/java -verbose -verbosegc -cs -verify ... or this: $ strace -f -s 256 $JAVA_HOME/bin/java ... That last command will be very noisy, but you may be surprised what you learn from reading it. That Didn't Help. What Else Can I Do?

We've created a troubleshooting information collection script that you can download from and follow the instructions at the top of it. Read the output carefully; it's full of hints that can help you solve the problem on your own.