Discussion :

[ForgetTheNorm]

Bonjour !

Je développe depuis plusieurs mois une application JAVA avec une dizaine de personnes dans le cadre de mes études.
Cette application permet d'afficher les valeurs des variables dans un algorithme.
Nous reprenons un projet déjà existant afin d'y ajouter des fonctionnalités (gestion de processus, fonctions, graphes, arbres, float, rationnels...)

Nous avons effectué la majeure partie du travail et avons essayé de "pousser" un peu l'application. Tout se déroule correctement sauf qu'au bout d'un certain moment (très variable), la machine finit par planter avec un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xb78638bc, pid=15265, tid=2991299488
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode, sharing)
# Problematic frame:
# V  [libjvm.so+0x2688bc]
#

Voilà, je me retrouve donc avec un fichier de report de bug, mais je ne sais pas du tout par où commencer !
En effet, l'application comporte environ 350 classes...
Je vous lance le fichier de bug, si jamais vous pouvez m'indiquer une piste !


Merci

Pierre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
 
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xb791a9be, pid=5165, tid=2992049056
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode, sharing)
# Problematic frame:
# V  [libjvm.so+0x2689be]
#
 
---------------  T H R E A D  ---------------
 
Current thread (0x08099900):  VMThread [id=5170]
 
siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000659
 
Registers:
EAX=0x00000601, EBX=0xb7a39aec, ECX=0x9128f5b8, EDX=0x89167290
ESP=0xb256faa0, EBP=0xb256fab8, ESI=0xb7a2c980, EDI=0xb7a47ac8
EIP=0xb791a9be, CR2=0x00000659, EFLAGS=0x00210202
 
Top of Stack: (sp=0xb256faa0)
0xb256faa0:   9128f5b8 89167290 0806cc08 0806cc08
0xb256fab0:   b7a39aec b7a315c4 b256fad8 b791accc
0xb256fac0:   b7a315c4 b7ebab91 b256fae8 b79abd7c
0xb256fad0:   b256fb20 b7a39aec b256fb08 b79b6754
0xb256fae0:   b7a47ac8 b7a315c4 b7f8555c b7f85458
0xb256faf0:   b256fb20 b256fb2c b79e50e3 b7a39aec
0xb256fb00:   00000002 0806cae8 b256fb48 b77f2ff0
0xb256fb10:   b7a47ac8 00000000 00000001 00000001 
 
Instructions: (pc=0xb791a9be)
0xb791a9ae:   40 08 8b 14 88 8b 42 04 8d 48 08 8b 40 08 52 51
0xb791a9be:   ff 50 58 8b 06 83 c4 10 8b 08 85 c9 75 d9 eb d0 
 
Stack: [0xb24f0000,0xb2571000),  sp=0xb256faa0,  free space=510k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x2689be]
V  [libjvm.so+0x268ccc]
V  [libjvm.so+0x304754]
V  [libjvm.so+0x140ff0]
V  [libjvm.so+0x1438d8]
V  [libjvm.so+0x143122]
V  [libjvm.so+0x14c8ad]
V  [libjvm.so+0x2f0dce]
V  [libjvm.so+0x1409ff]
V  [libjvm.so+0xfd07e]
V  [libjvm.so+0x140c92]
V  [libjvm.so+0x32dda4]
V  [libjvm.so+0x32dad6]
V  [libjvm.so+0x32d0e7]
V  [libjvm.so+0x32d355]
V  [libjvm.so+0x32cec0]
V  [libjvm.so+0x28bbe8]
C  [libpthread.so.0+0x5504]
 
VM_Operation (0xb17fcbc0): generation collection for allocation, mode: safepoint, requested by thread 0x08508b60
 
 
---------------  P R O C E S S  ---------------
 
Java Threads: ( => current thread )
  0x084ec898 JavaThread "Thread-47" [_thread_blocked, id=5266]
  0x08508b60 JavaThread "Thread-4" [_thread_blocked, id=5217]
  0x08458488 JavaThread "AWT-EventQueue-1" [_thread_blocked, id=5186]
  0xb1902568 JavaThread "TimerQueue" daemon [_thread_blocked, id=5185]
  0x0805ce30 JavaThread "DestroyJavaVM" [_thread_blocked, id=5165]
  0x08457e48 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=5182]
  0xb1901440 JavaThread "AWT-Shutdown" [_thread_blocked, id=5181]
  0x083ace90 JavaThread "thread applet-ihm.Main.class" [_thread_blocked, id=5180]
  0x083a4eb8 JavaThread "AWT-XAWT" daemon [_thread_blocked, id=5178]
  0x08393ee0 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=5177]
  0x080a6fd8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=5175]
  0x080a5a30 JavaThread "CompilerThread0" daemon [_thread_blocked, id=5174]
  0x080a4ab8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=5173]
  0x0809d1d8 JavaThread "Finalizer" daemon [_thread_blocked, id=5172]
  0x0809c4f0 JavaThread "Reference Handler"

[Janitrix]

thread applet-ihm.Main.class c'est une classe à toi ça ?
Sinon recherches sur le site de Sun, peut-être que c'est un bug de la JVM, mais j'en doute. Le seul moyen dans ces cas la reste le deboguage pas à pas. Bonne chance

[ForgetTheNorm]

thread applet-ihm.Main.class c'est une classe à toi ça ?
Sinon recherches sur le site de Sun, peut-être que c'est un bug de la JVM, mais j'en doute. Le seul moyen dans ces cas la reste le deboguage pas à pas. Bonne chance

Oui, ihm/Main.class est la classe qui lance l'application... Qui s'occupe seulement de lancer une JFrame et c'est tout !

[Janitrix]

Bah apparemment le problème vient de là. Enfin, je n'ai jamais vu d'erreur de ce type, ça n'est pas une exception, ça ressemble plus à une erreur interne de HotSpotVirtualMachine .

[gronono]

Bonjour,

je ne sais pas si cela va t'aider, mais j'ai déjà eu le même genre de problème.
Le programme est lancé via un executable windows transformé en service windows. On n'a pas résolut le problème sur les postes de développement mais il marche sur le serveur de production. Je fais la maintenance applicative et le programme n'a pas encore évolué. Donc je n'ai pas eu à creuser le problème. Mais je passe que c'est une question de variable système et la présence d'une DDL de la jvm dans le PATH.

Est-ce que ton application est à 100% Java, est-ce qu'elle est appelé directement via la commande java ou est-ce qu'elle utilise une librairie native ?

Tu as essayé de réinstaller la JVM ?


A+

[ForgetTheNorm]

Bah apparemment le problème vient de là. Enfin, je n'ai jamais vu d'erreur de ce type, ça n'est pas une exception, ça ressemble plus à une erreur interne de HotSpotVirtualMachine .

Comme je l'ai dit plus haut, la classe ihm/Main s'occupe simplement de lancer la fenetre de l'application... Est-ce qu'il y a moyen d'aller plus "en profondeur" pour savoir à quel moment, ou sur quel appel de méthode, la JVM plante ?
Puisqu'apparemment, ça a l'air d'un plantage de la JVM plutôt qu'autre chose...

Bonjour,
je ne sais pas si cela va t'aider, mais j'ai déjà eu le même genre de problème.
Le programme est lancé via un executable windows transformé en service windows. On n'a pas résolut le problème sur les postes de développement mais il marche sur le serveur de production. Je fais la maintenance applicative et le programme n'a pas encore évolué. Donc je n'ai pas eu à creuser le problème. Mais je passe que c'est une question de variable système et la présence d'une DDL de la jvm dans le PATH.

Est-ce que ton application est à 100% Java, est-ce qu'elle est appelé directement via la commande java ou est-ce qu'elle utilise une librairie native ?

Tu as essayé de réinstaller la JVM ?
A+

Ma machine est sous Linux (Ubuntu) avec une installation de la JVM toute récente...
Mon application utilise 3 librairies :
- JFreeChart - pour un affichage de graphiques plus évolués tels histogrammes, etc...
- liquidlnf - pour avoir un "look&feel", c'est à dire que la fenetre prend les graphiques de l'environnement local
- jcommon - pour représenter des petits graphiques pas très évolués

Cette application est destinée à être compilée pour être utilisée dans une page Web.
Pour l'instant, elle est encore en développement, donc je la lance simplement avec le Run d'Eclipse, sans plus de paramètres spécifiques.

thread applet-ihm.Main.class c'est une classe à toi ça ?
Sinon recherches sur le site de Sun, peut-être que c'est un bug de la JVM, mais j'en doute. Le seul moyen dans ces cas la reste le deboguage pas à pas. Bonne chance

J'ai bien essayé le débogage pas à pas, seulement, j'ai l'impression que la JVM plante lors d'une "surcharge" d'appels de méthodes ; le débogage ne permet pas de simuler cette surcharge...