Crash JRE inexpliqué

**icareo** · 14/07/2010, 02h23

Bonjour,

Pour introduire le contexte :
J'ai un applet java utilisant du code natif chargé depuis une dll (donc uniquement sous windows)

Ce code natif est chargé dynamiquement depuis le serveur :
- la DLL est téléchargée dans le répertoire 'System.getProperty("java.home")'
- elle est chargée via System.load("nom.dll");

Donc je déclare les méthodes implémentées dans la dll via un habituel :
public static final native String mamethode();

Ce que fait l'applet :
Il contient un bouton.
Lorsque ce bouton est cliqué, il reçoit des infos depuis un périphérique usb (d'où la nécessité d'utiliser du code natif) et les transmet à la page html.

Voilà la bizarrerie :

* J'ai créé un html contenant une balise <applet> intégrant mon applet dans une page.

* Une fois mon applet compilé, j'ouvre la page sans passer par le protocole http. Autrement dit, via l'adresse file://C:/monchemin/mapage.html
=> L'applet marche super bien... tout bien comme il faut... il recoit les données depuis le périphérique usb.

* Maintenant, je passe par http via un serveur apache local.
Donc j'accède au MEME applet, même page html... tout pareil, mais maintenant via http://localhost/mapage.html

=> L'applet se lance...
- je clique sur le bouton...
- l'applet reçoit quelques infos simples du périphérique (version, nombre de données à recevoir...)
- puis il tente de recevoir des données du périphérique... et là, c'est le drame :

L'applet plante purement et simplement.
En fait, c'est le processus de la JVM qui plante. Donc plus de console pour me donner des infos !
L'applet laisse donc place à un écran noir dans firefox, ou une image bloquée dans IE....

Quelqu'un aurrait-il une piste à me fournir ?
Y a-t-il un "log caché" que je puisse consulter pour en savoir plus sur ce qui a fait planter la JVM ?

EDIT :
La seule piste que j'aie trouvée est ici :
http://java.sun.com/javase/6/webnote...l/crashes.html
Mais le fait que tout marche bien dans un de mes deux cas cités ci dessus me fait dire que ça ne peut pas être le code natif qui plante...

De plus, étant tout nouveau en développement java (toujours tourné sous .NET) et n'ayant pas tout compris à la procédure pour signer un jar, le .jar de mon applet est autosigné (j'ai fait ça via "Projet>properties>Application>Web start>self-signed" dans NetBeans)
... si ça peut aider...

**tchize_** · 14/07/2010, 10h33

Quand une jvm avec du code natif crashe, faut pas chercher plus loin, c'est le code natif qui est en cause (corruption de données, pointeurs null, dangling pointers, etc). Maintenant, comme toujours, trouver la raison du plantage n'est pas évident. La JVM ne fait, normalement, aucune différence entre une applet chargée avec http://..... et file:///.....,ça reste une applet soumises aux même règles. Si votre applet n'est pas dans un jar, n'oubliez pas qu'il peux y avoir un certain délai pour charger une classe que vous n'avez pas encore chargée (le temps de la trouver sur le serveur) et que c'est d'office plus lent par http que par file://, ce qui peut rendre visible des erreurs de programmation de la dll.

Vous pourriez éventuellement utiliser l'application appletviewer pour voir les messages du crash dans la console.

**icareo** · 14/07/2010, 17h43

Merci pour la réponse...

Cependant, appletviewer ne me sera pas d'une grande utilité : mon applet marche super bien dans ce dernier.

Après moult tests en tous genres, j'en arrive encore et toujours à la même conclusion : il n'y a vraiment que dans un contexte http que l'app plante.

L'applet est stocké dans un .JAR, ainsi que les dlls dont il a besoin (donc un seul même fichier pour le tout).

Autre fait "amusant" : l'applet a marché une fois ou deux, sans raison apparente quand je l'utilise via http... i.e. il a reçu des données depuis le périphérique, pour finalement planter après.

si ça peut aider le log du crash de la JVM est ici : http://icareo.free.fr/hs_err_pid9708.log

**tchize_** · 14/07/2010, 19h06

ha ben voilà, toi qui disais que t'avais pas de log :/

T'as plus qu'a prendre ton debugger C++ et aller voir ce que fait ta dll en [libPodo.dll+0x18ee]