J'écris une bibliothèque autochtone Java en C ++ et utilise une manipulation des exceptions au sein de Native Lib même, mais la bibliothèque se bloque dès que j'avoir une exception. Voici mon programme de test simple, lorsque je l'appelle du test Java, il se bloque simplement dès que l'exception est lancée. Le bloc de capture ne fonctionne pas. Des idées ce que je manque. Merci. Compilation et lien: P> g++ -m64 -fPIC -fexceptions -c test.cpp
g++ -shared -m64 -Wl,-soname,libtest.so -Wl,-shared-libgcc test.o -o libtest.so
$ java -d64 -Djava.library.path=/home/vkumar/projects/test -cp $CLASSPATH Test
terminate called after throwing an instance of 'int'
terminate called recursively
Hello World^CAbort (core dumped)
3 Réponses :
J'ai essayé votre examen d'examen et tout s'est bien passé. Mon environnement est Ubuntu 12.04 (64 bits) avec Oracle JDK 1.7.
Alors, je suppose que votre environnement est le coupable. Puisque vous utilisez l'option Veuillez vérifier votre système, JDK, GCC, etc. convient à tous ensemble. -m64 , il pourrait s'agir d'un décalage entre système de 32 bits et 64 bits libtest.so.
Merci, je vérifierai la compatibilité entre tous les composants impliqués. J'utilise Solaris 5.10, GCC 4.3.3 et JDK 1.6
@vkumar j'ai réessayé avec OpenJDK 6 et OpenJDK 7 (GCC 4.6.3). Même résultat: succès.
Merci Olaf, je vais essayer avec une version différente de GCC. Notre produit cible env. Sun Solaris, je ne pourrais pas changer cela. Mais si sa question du compilateur, je peux toujours la mettre à niveau. Merci encore.
Olaf - Vous avez raison. J'ai construit le 32 bit libtest.so et ça marche bien en mode 32 bits. Cela signifie-t-il que j'aurais besoin d'installer 64 bits Java?, J'importais que Java avec le mode Java 44 assurez-vous que le serveur fonctionne en mode 64 bits?
@vkumar je ne connais pas Sunos, mais je suppose que oui. Dans Ubuntu, j'ai des paquets appropriés pour 64 bits (AMD64) et 32 bits (I386), en fonction de l'environnement système / matériel. J'ai également téléchargé le package JDK "X64-Linux" de Oracle. Donc, cela devrait être le même pour votre environnement.
@vkumar Je viens de googler un peu sur Solaris et cela pourrait être, que uname -a vous indique que vous exécutez un noyau 32 bits ou 64 bits.
VKUMAR @ RV-DV-IXTE-03 $ UNAOM -A SUNOS 5.10 generic_142901-14 I86PC I386 I86PC SOLARIS VKUMAR @ RV-DV-IXTE-03 $
@vkumar Cela semble être 32 bits (i386). Il explique pourquoi le code fonctionne en mode 32 bits et non lorsqu'il est compilé pour un environnement 64 bits.
ressemble à une exception n'était pas décourgué. Essayez
int i=1;
try {
throw i;
}
Non, je me suis assuré que j'ai supprimé .so, .o et tout recompilé. Même s'il y a un problème avec la taille int, la capture (...) devrait l'attraper.
est Jniexport ou JnicAll en expansinant pour définir la liaison C? Si oui, alors vous lancez une exception C ++ dans une fonction C et je ne suis pas sûr que le comportement soit défini.
peut-être essayer quelque chose comme
Ce n'est pas un problème de jeter et de prendre une exception dans une fonction externe "c". Ce serait un problème de laisser l'exception échapper à ladite fonction.
quelle plate-forme? Quel fournisseur et la version de Java?
Sunos 5.10, GCC 4.3.3 et JDK 1.6.0, j'ai essayé de compiler tout en mode 32 bit, mais les mêmes résultats.
Je me souviens avoir eu un problème similaire il y a quelques années sur Solaris. À l'époque, le problème utilisait GCC, la liaison GNU et les bibliothèques partagées. Nous avons résolu le problème en utilisant le Sun Linker et en reliant des fichiers binaires statiques. Évidemment, la mise en œuvre de l'essai / attrape de la GCC avait besoin d'un support de liaison non compatible avec la liaison Sun Dynamic. Vous pouvez essayer d'utiliser un lien différent, car votre statique ne vous aidera pas dans un environnement Java.
ToBias, heureusement, j'ai une autre construction de GCC qui utilise Solaris Linker. Je vais l'essayer et voir comment ça se passe.
Je l'ai essayé avec Solaris Linker, mais les mêmes résultats.