Comment dépanner l'échec de chargement Java JVM?


Je travaille sur une grande application 32 bits héritée (15 Mo) écrite en C++Builder 6 qui doit utiliser une API tierce pour interagir avec un système extérieur. L'API se compose d'un groupe de DLL qui utilisent en interne Java (je suppose que JNI). Notre code n'interagit qu'avec une DLL particulière directement, et il est chargé en retard à l'exécution.

Lorsque l'application est exécutée sur le système d'un client, la DLL plante pour des raisons inconnues. J'ai donc essayé de reproduire sur mon système (XP Pro 32bit) et j'ai rencontré un le problème est différent.

L'application crée un thread qui tente d'initialiser l'API, qui tente en interne de charger la JVM Java et échoue, et l'API signale une erreur "JVM create failure" dans mon code.

Cependant, le même code de thread s'exécutant dans une petite application de test fonctionne, Java se charge très bien et l'API fonctionne normalement.

Les deux applications sont exécutées à partir du même dossier, il ne s'agit donc pas d'un problème de chemin d'accès pour localiser les DLL API ou les DLL Java JVM. Je me suis aussi assuré que les deux les projets utilisent les mêmes paramètres de compilateur/éditeur de liens pour l'utilisation de la mémoire, la taille du tas, l'alignement, le type de processeur, etc.

J'ai vu une référence en ligne suggérant que la JVM a besoin de l'espace d'adressage du processus appelant pour avoir une grande section de mémoire contiguë disponible, est-ce vrai? Si oui, combien?

J'ai essayé d'activer la journalisation/traçage dans le panneau de configuration Java, mais rien d'utile n'a été enregistré.

Existe - t-il un moyen de savoir pourquoi Java ne se charge pas quand appelé par l'application principale, mais pas l'appli de test?

Author: Remy Lebeau, 2014-07-02

1 answers

Il semble que l'application soit lancée avec moins de mémoire.

La mémoire par défaut utilisée par jre pour lancer la JVM dépend de la configuration du système. Très probablement, la mémoire par défaut n'est pas assez grande pour charger toutes les classes et exécuter OOM.

Mieux vaut répliquer sur votre application de test est de réduire la mémoire de tas à 64, puis de voir ce qui se passe. De cette façon, nous pouvons être plus proches d'obtenir si c'est vraiment un problème de mémoire.

 1
Author: Abhishek, 2014-07-02 05:39:59