7. Problèmes connus

Contenu de cette section

7.1 GNU make ne fonctionne plus après l'installation de Java

Les versions récentes de libc corrigent un bogue qui en cachait un autre dans la version GNU de make (le symptôme en est que make ne cherche plus les règles dans les Makefile). Un patch corrigeant ce problème est inclus dans la distribution 5.2.8 de libc.

7.2 Vous avez des erreurs dirname: too many arguments

Votre variable d'environnement CLASSPATH n'est pas initialisée correctement. Dans le fichier .java_wrapper, on trouve quelques lignes ressemblant à :

   PRG=`which $0`
   J_HOME=`dirname $PRG`/..

Malheureusement, la commande which généralement fournie avec Linux est horriblement défectueuse et certains shells risquent d'affecter à $0 le chemin complet. Selon Randy Chapman, la solution est d'utiliser soit~:

    J_HOME=`dirname $0`/..

soit, de façon plus sûre~:

    J_HOME=/usr/local/java

Un autre correctif, proposé par Dave Dittrich, est :

    PRG=`csh -c "which $0"`

Quant à Tim Farnum, il propose de changer la ligne PRG=`which $0` en~:

    PRG=$0

Lutz Behnke, enfin, suggère~:

    PRG=`type -path $0` >/dev/null 2>&1 

Une modification similaire doit être appliquée au script d'appletviewer.

7.3 Vous avez des erreurs du type cannot find class java/lang/Thread

Votre variable d'environnement CLASSPATH n'est pas initialisée correctement. Voir plus haut.

7.4 Un message d'erreur fait référence à /dev/zero

Passez root et faites un chmod 666 /dev/zero.

7.5 SEGFAULT

Il peut arriver que votre écran se remplisse de messages d'erreurs, que le système remplisse joyeusement votre mémoire virtuelle, puis se bloque.

Dans ce cas, il vous manque probablement une bibliothèque quelque part. Lancez ldconfig -v et regardez ce qu'il manque. Il est également possible que les variables d'environnement LD_LIBRARY_PATH ou CLASSPATH ne soient pas positionnées. Enfin, il se trouve que certaines applets sont boguées et bloquent le JDK Linux (il y a d'ailleurs un moyen d'éviter le blocage en ayant un autre xterm dans lequel tourne top. Il suffit alors d'utiliser top pour tuer le processus java AVANT qu'il remplisse la mémoire virtuelle et bloque le système).

Java semble nécessiter d'importantes ressources. Il est donc conseillé de restreindre au maximum le nombre d'applications ouvertes ou qui s'exécutent. Il parvient à se charger sur un 486DX-2-75 avec 8 Mo de RAM et 16 Mo de swap (cela prend tout de même une minute). L'auteur a ainsi réussi à faire tourner deux applets animées simultanément (ou à peu près) avant que le système se retrouve à court de mémoire virtuelle et se bloque.

7.6 bin/java, bin/javac, ou bin/appletviewer vous renvoie un message d'aide

Vous avez oublié des paramètres de la ligne de commande.

7.7 Les applets apparaissent bien dans l'appletviewer, mais pas lorsqu'elles sont placées sur un serveur Web.

Une erreur classique ayant cette conséquence est d'associer aux applets un type MIME incorrect. Votre serveur doit renvoyer avec l'applet un en-tête indiquant qu'elle est du type MIME text/plain, application/octet-stream ou tout autre type pour lequel le client ne dispose pas d'un module de traitement spécial. La manière de remédier à cela dépend du serveur que vous utilisez. (John Franks)

Il semble également que tinyhttpd, un serveur HTTP écrit en Perl, renvoie un content type incorrect. Apache, en revanche, semble fonctionner relativement correctement.

7.8 Fichier de traces

Selon Joey Oravec, HotJava conserve un fichier de traces des actions qu'il accomplit et des éventuels problèmes qu'il rencontre. Si vous devez établir un diagnostic par vous-même, examinez le fichier $HOME/.hotjava/weblog, dans le répertoire racine de l'utilisateur. Ce fichier vous permettra de repérer plus aisément s'il vous manque une bibliothèque ou s'il s'agit d'un problème similaire.


Chapitre suivant, Chapitre Précédent

Table des matières de ce chapitre, Table des matières générale

Début du document, Début de ce chapitre