J'ai un petit souci avec des cartes ASRock montées dans des
serveurs. Je m'explique : de temps en temps, je suis contraint de
rebooter les machines sauvagement (sous Unix) pour diverses raisons
(en particulier une instabilité d'une JAVA VM qui me fout la
pagaille sur une machine). Il arrive alors que la machine ne démarre
plus (même pas le bios). J'ai vu qu'en retirant la carte graphique,
en redémarrant, l'engin se plaint. Si je remets la carte graphique
par la suite, tout rentre dans l'ordre.
J'ai ce phénomène avec deux ASRock (K7VT et K7VT4A) munies de cartes
graphiques AGP avec chipset nvidia (cartes de base, si j'avais pu
trouver des matrox de base rapidement...). Est-ce un problème connu
et y a-t-il un moyen de résoudre ça ?
Merci de votre attention,
JKB
--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
seb666fr2
JKB wrote:
Bonjour à tous,
Bonjour
J'ai un petit souci avec des cartes ASRock montées dans des serveurs. Je m'explique : de temps en temps, je suis contraint de rebooter les machines sauvagement (sous Unix) pour diverses raisons (en particulier une instabilité d'une JAVA VM qui me fout la pagaille sur une machine). Il arrive alors que la machine ne démarre plus (même pas le bios).
s'il y a des problèmes au niveau du démarrage du bios, il faut avant tout penser à un problème purement matériel plutôt qu'a un éventuelle problème au niveau logiciel.
Personnellement, je pencherai plutôt pour un problème de stabilité de l'alimentation et/ou un problème mémoire, ce dernier pouvant être engendré par le 1er d'ailleur.
J'ai vu qu'en retirant la carte graphique, en redémarrant, l'engin se plaint. Si je remets la carte graphique pa r la suite, tout rentre dans l'ordre.
AMHA c'est un comportement tout à fait normal . Par exemple, avec une
k7s5a (elite), le fait de démarrer sans carte graphique provoque l'émission de 8 bips court.
Merci de votre attention,
Bonne chance
JKB wrote:
Bonjour à tous,
Bonjour
J'ai un petit souci avec des cartes ASRock montées dans des
serveurs. Je m'explique : de temps en temps, je suis contraint de
rebooter les machines sauvagement (sous Unix) pour diverses raisons
(en particulier une instabilité d'une JAVA VM qui me fout la
pagaille sur une machine). Il arrive alors que la machine ne démarre
plus (même pas le bios).
s'il y a des problèmes au niveau du démarrage du bios, il faut avant
tout penser à un problème purement matériel plutôt qu'a un
éventuelle problème au niveau logiciel.
Personnellement, je pencherai plutôt pour un problème de stabilité
de l'alimentation et/ou un problème mémoire, ce dernier pouvant être
engendré par le 1er d'ailleur.
J'ai vu qu'en retirant la carte graphique,
en redémarrant, l'engin se plaint. Si je remets la carte graphique pa r la suite, tout rentre dans l'ordre.
AMHA c'est un comportement tout à fait normal . Par exemple, avec une
k7s5a (elite), le fait de démarrer sans carte graphique provoque
l'émission de 8 bips court.
J'ai un petit souci avec des cartes ASRock montées dans des serveurs. Je m'explique : de temps en temps, je suis contraint de rebooter les machines sauvagement (sous Unix) pour diverses raisons (en particulier une instabilité d'une JAVA VM qui me fout la pagaille sur une machine). Il arrive alors que la machine ne démarre plus (même pas le bios).
s'il y a des problèmes au niveau du démarrage du bios, il faut avant tout penser à un problème purement matériel plutôt qu'a un éventuelle problème au niveau logiciel.
Personnellement, je pencherai plutôt pour un problème de stabilité de l'alimentation et/ou un problème mémoire, ce dernier pouvant être engendré par le 1er d'ailleur.
J'ai vu qu'en retirant la carte graphique, en redémarrant, l'engin se plaint. Si je remets la carte graphique pa r la suite, tout rentre dans l'ordre.
AMHA c'est un comportement tout à fait normal . Par exemple, avec une
k7s5a (elite), le fait de démarrer sans carte graphique provoque l'émission de 8 bips court.
Merci de votre attention,
Bonne chance
JKB
Le 30-10-2005, à propos de Re: ASRock K7VTxx, écrivait dans fr.comp.sys.pc :
JKB wrote:
Bonjour à tous,
Bonjour
J'ai un petit souci avec des cartes ASRock montées dans des serveurs. Je m'explique : de temps en temps, je suis contraint de rebooter les machines sauvagement (sous Unix) pour diverses raisons (en particulier une instabilité d'une JAVA VM qui me fout la pagaille sur une machine). Il arrive alors que la machine ne démarre plus (même pas le bios).
s'il y a des problèmes au niveau du démarrage du bios, il faut avant tout penser à un problème purement matériel plutôt qu'a un éventuelle problème au niveau logiciel.
Cela m'arrive avec toutes mes K7VT et cartes graphiques (nvidia). Si cela n'arrivait qu'avec une seule configuration, je me poserai la question d'une panne matérielle. Mais là, je trouve la coïncidence bizarre...
Personnellement, je pencherai plutôt pour un problème de stabilité de l'alimentation et/ou un problème mémoire, ce dernier pouvant être engendré par le 1er d'ailleur.
J'ai vu qu'en retirant la carte graphique, en redémarrant, l'engin se plaint. Si je remets la carte graphique par la suite, tout rentre dans l'ordre.
AMHA c'est un comportement tout à fait normal . Par exemple, avec une
k7s5a (elite), le fait de démarrer sans carte graphique provoque
Et juste après, en remettant la carte graphique, ça démarre (quelle que soit la config et l'alimentation). Encore une fois, plusieurs machines me font le coup.
Merci de votre attention,
Bonne chance
Merci ;-)
JKB
-- En plus c'est simple, je fais ce genre de trucs en g77 depuis des années : il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 30-10-2005, à propos de
Re: ASRock K7VTxx,
seb666fr2@yahoo.fr écrivait dans fr.comp.sys.pc :
JKB wrote:
Bonjour à tous,
Bonjour
J'ai un petit souci avec des cartes ASRock montées dans des
serveurs. Je m'explique : de temps en temps, je suis contraint de
rebooter les machines sauvagement (sous Unix) pour diverses raisons
(en particulier une instabilité d'une JAVA VM qui me fout la
pagaille sur une machine). Il arrive alors que la machine ne démarre
plus (même pas le bios).
s'il y a des problèmes au niveau du démarrage du bios, il faut avant
tout penser à un problème purement matériel plutôt qu'a un
éventuelle problème au niveau logiciel.
Cela m'arrive avec toutes mes K7VT et cartes graphiques (nvidia). Si
cela n'arrivait qu'avec une seule configuration, je me poserai la
question d'une panne matérielle. Mais là, je trouve la coïncidence
bizarre...
Personnellement, je pencherai plutôt pour un problème de stabilité
de l'alimentation et/ou un problème mémoire, ce dernier pouvant être
engendré par le 1er d'ailleur.
J'ai vu qu'en retirant la carte graphique,
en redémarrant, l'engin se plaint. Si je remets la carte graphique par la suite, tout rentre dans l'ordre.
AMHA c'est un comportement tout à fait normal . Par exemple, avec une
k7s5a (elite), le fait de démarrer sans carte graphique provoque
Et juste après, en remettant la carte graphique, ça démarre (quelle
que soit la config et l'alimentation). Encore une fois, plusieurs
machines me font le coup.
Merci de votre attention,
Bonne chance
Merci ;-)
JKB
--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 30-10-2005, à propos de Re: ASRock K7VTxx, écrivait dans fr.comp.sys.pc :
JKB wrote:
Bonjour à tous,
Bonjour
J'ai un petit souci avec des cartes ASRock montées dans des serveurs. Je m'explique : de temps en temps, je suis contraint de rebooter les machines sauvagement (sous Unix) pour diverses raisons (en particulier une instabilité d'une JAVA VM qui me fout la pagaille sur une machine). Il arrive alors que la machine ne démarre plus (même pas le bios).
s'il y a des problèmes au niveau du démarrage du bios, il faut avant tout penser à un problème purement matériel plutôt qu'a un éventuelle problème au niveau logiciel.
Cela m'arrive avec toutes mes K7VT et cartes graphiques (nvidia). Si cela n'arrivait qu'avec une seule configuration, je me poserai la question d'une panne matérielle. Mais là, je trouve la coïncidence bizarre...
Personnellement, je pencherai plutôt pour un problème de stabilité de l'alimentation et/ou un problème mémoire, ce dernier pouvant être engendré par le 1er d'ailleur.
J'ai vu qu'en retirant la carte graphique, en redémarrant, l'engin se plaint. Si je remets la carte graphique par la suite, tout rentre dans l'ordre.
AMHA c'est un comportement tout à fait normal . Par exemple, avec une
k7s5a (elite), le fait de démarrer sans carte graphique provoque
Et juste après, en remettant la carte graphique, ça démarre (quelle que soit la config et l'alimentation). Encore une fois, plusieurs machines me font le coup.
Merci de votre attention,
Bonne chance
Merci ;-)
JKB
-- En plus c'est simple, je fais ce genre de trucs en g77 depuis des années : il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
seb666fr2
JKB wrote:
Le 30-10-2005, à propos de Re: ASRock K7VTxx, écrivait dans fr.comp.sys.pc :
JKB wrote:
Bonjour à tous,
Bonjour
J'ai un petit souci avec des cartes ASRock montées dans des serveurs. Je m'explique : de temps en temps, je suis contraint de rebooter les machines sauvagement (sous Unix) pour diverses raisons (en particulier une instabilité d'une JAVA VM qui me fout la pagaille sur une machine). Il arrive alors que la machine ne démarre plus (même pas le bios).
s'il y a des problèmes au niveau du démarrage du bios, il faut avant tout penser à un problème purement matériel plutôt qu'a un éventuelle problème au niveau logiciel.
Cela m'arrive avec toutes mes K7VT et cartes graphiques (nvidia). Si cela n'arrivait qu'avec une seule configuration, je me poserai la question d'une panne matérielle. Mais là, je trouve la coïncidence bizarre...
En faisait une recherche rapide sur la bug database de sun, je viens de trouver un rapport de bug (relativement récent) qui semble correspondre à la description de votre problème : http://bugs.sun.com/bugdatabase/view_bug.do?bug_idb98877
JKB wrote:
Le 30-10-2005, à propos de
Re: ASRock K7VTxx,
seb666fr2@yahoo.fr écrivait dans fr.comp.sys.pc :
JKB wrote:
Bonjour à tous,
Bonjour
J'ai un petit souci avec des cartes ASRock montées dans des
serveurs. Je m'explique : de temps en temps, je suis contraint de
rebooter les machines sauvagement (sous Unix) pour diverses raisons
(en particulier une instabilité d'une JAVA VM qui me fout la
pagaille sur une machine). Il arrive alors que la machine ne démarre
plus (même pas le bios).
s'il y a des problèmes au niveau du démarrage du bios, il faut avant
tout penser à un problème purement matériel plutôt qu'a un
éventuelle problème au niveau logiciel.
Cela m'arrive avec toutes mes K7VT et cartes graphiques (nvidia). Si
cela n'arrivait qu'avec une seule configuration, je me poserai la
question d'une panne matérielle. Mais là, je trouve la coïncidence
bizarre...
En faisait une recherche rapide sur la bug database de sun, je viens de
trouver un rapport
de bug (relativement récent) qui semble correspondre à la description
de
votre problème :
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6298877
Le 30-10-2005, à propos de Re: ASRock K7VTxx, écrivait dans fr.comp.sys.pc :
JKB wrote:
Bonjour à tous,
Bonjour
J'ai un petit souci avec des cartes ASRock montées dans des serveurs. Je m'explique : de temps en temps, je suis contraint de rebooter les machines sauvagement (sous Unix) pour diverses raisons (en particulier une instabilité d'une JAVA VM qui me fout la pagaille sur une machine). Il arrive alors que la machine ne démarre plus (même pas le bios).
s'il y a des problèmes au niveau du démarrage du bios, il faut avant tout penser à un problème purement matériel plutôt qu'a un éventuelle problème au niveau logiciel.
Cela m'arrive avec toutes mes K7VT et cartes graphiques (nvidia). Si cela n'arrivait qu'avec une seule configuration, je me poserai la question d'une panne matérielle. Mais là, je trouve la coïncidence bizarre...
En faisait une recherche rapide sur la bug database de sun, je viens de trouver un rapport de bug (relativement récent) qui semble correspondre à la description de votre problème : http://bugs.sun.com/bugdatabase/view_bug.do?bug_idb98877
JKB
Le 30-10-2005, à propos de Re: ASRock K7VTxx, écrivait dans fr.comp.sys.pc :
En faisait une recherche rapide sur la bug database de sun, je viens de trouver un rapport de bug (relativement récent) qui semble correspondre à la description de votre problème : http://bugs.sun.com/bugdatabase/view_bug.do?bug_idb98877
Merci pour cette info. Je n'arrive pas à accéder ce matin à cette base. Y a-t-il une façon de corriger le truc ?
Cordialement,
JKB
-- En plus c'est simple, je fais ce genre de trucs en g77 depuis des années : il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 30-10-2005, à propos de
Re: ASRock K7VTxx,
seb666fr2@yahoo.fr écrivait dans fr.comp.sys.pc :
En faisait une recherche rapide sur la bug database de sun, je viens de
trouver un rapport
de bug (relativement récent) qui semble correspondre à la description
de
votre problème :
http://bugs.sun.com/bugdatabase/view_bug.do?bug_idb98877
Merci pour cette info. Je n'arrive pas à accéder ce matin à cette
base. Y a-t-il une façon de corriger le truc ?
Cordialement,
JKB
--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 30-10-2005, à propos de Re: ASRock K7VTxx, écrivait dans fr.comp.sys.pc :
En faisait une recherche rapide sur la bug database de sun, je viens de trouver un rapport de bug (relativement récent) qui semble correspondre à la description de votre problème : http://bugs.sun.com/bugdatabase/view_bug.do?bug_idb98877
Merci pour cette info. Je n'arrive pas à accéder ce matin à cette base. Y a-t-il une façon de corriger le truc ?
Cordialement,
JKB
-- En plus c'est simple, je fais ce genre de trucs en g77 depuis des années : il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
seb666fr2
JKB wrote:
Le 30-10-2005, à propos de Re: ASRock K7VTxx, écrivait dans fr.comp.sys.pc :
En faisait une recherche rapide sur la bug database de sun, je viens de trouver un rapport de bug (relativement récent) qui semble correspondre à la descripti on de votre problème : http://bugs.sun.com/bugdatabase/view_bug.do?bug_idb98877
Merci pour cette info. Je n'arrive pas à accéder ce matin à cette base. Y a-t-il une façon de corriger le truc ?
Cordialement,
JKB
J'ai fait une copie compléte du rapport ci-dessous. A la fin, il y a la description d'une méthode pour reproduire le bug ce qui devrait permettre de déterminer si votre problème est le même. Hélas il ne semble pas y avoir de workaround. Une solution pourrait toutefois consister à essayer avec une jvm tierce (d'ibm par exemple).
========================= ========================= ======================= Bug ID: 6298877 Votes 7 Synopsis JVM hangs on Linux only, no thread dump possible Category hotspot:jvm_interface Reported Against b09 Release Fixed State In progress, bug Related Bugs Submit Date 19-JUL-2005 Description One of our customers run a number of different web applications in a production environment. Most of the applications run on Sun Sparc hardware running Solaris 8 and the Sun JVM for Solaris. A small number of applications run on a Sun V20z server with AMD64 processor and RedHat AS3 Linux OS, and the Sun JVM for Linux.
Product is actually J2SE 1.4.2_08 (the latest).
All applications work fine in the Solaris/Sparc environment. and most applications work fine on the Linux/AMD environment.
One application on Linux (only!) hangs at irregular intervals. The hang is particularly vexing to solve because the JVM does not respond to a kill -QUIT (which normally produces a thread dump). They have been able to take a core dump of the application with gdb, but because the JVM builds don't have symbols they are unable to make much sense of the core dump. They don't believe this is an application issue due to the fact that the exact same application never hangs on the Solaris platform. However, even if it is an application issue, it's very hard to debug because the JVM won't allow to take a thread dump so they have virtually no information about what might be causing the hang. They are able to terminate the JVM however.
Environment On Which The Problem Is Seen : OS is 64-bit RedHat AS3, platform is a Sun V20Z server (64-bit AMD processor). They are running the 32-bit JVM.
Need to diagonize the hang on Linux platform JVM.
Running Linux strace (the equivalent of Solaris truss) shows only that the jvm is stuck in a futex(2) call, which suggests a deadlock (I believe futex(2) is used on Linux to implement Java locking). The complete core dump of the application in its hung state taken with gdb is available at : Path : /net/hanwka-home1.sfbay/global/export/home1/27/sd158479/ariba File Name : core-2.zip and core-3.zip -->> Totally two files.
2005-07-19 19:35:15 GMT 2005-07-19 20:05:33 GMT
Work Around N/A 2005-07-19 19:35:16 GMT
Evaluation N/A
Comments Include a link with my name & email
Submitted On 05-AUG-2005 Water_Moon I recognized the same thing like the "Bug ID:6298877" in the environment as following. OS : Red Hat Enterprise Linux ES release 3 CPU : 2 JDK : j2sdk1.4.2_05, 1.4.2_06, 1.4.2_08
I didn't see a thread dump when I sent the command "kill -QUIT PID" to the hanging JVM. And I only saw that the JVM was recieved the QUIT signal like following.
JVM hanged with "-Xint" option to turn off the HotSpot.
I didn't recognized the same thing in the environment as following. Solaris9 : j2sdk1.4.2_05, 1.4.2_06, 1.4.2_08, single CPU RHEL ES 3: j2sdk1.3.1, j2sdk1.5.0, dual CPUs
Submitted On 16-AUG-2005 Me too!
Same behaviour with different JDKs under Linux RH ES 3 (1.4.X, 1.5.X) 2 processors, kill -QUIT has no effect, stopped in a futex. Application works fine for month in production under Solaris 8.
Today I upgraded the kernel from 2.4.20-8smp to 2.6.12.3 and (until) now everything works fine - i. e. the bug vanished (AFAIK RH patched the old 2.4 kernel with some 2.6 futexes...)
I found a way to reproduce this bug. Run the attached script. On the buggy system, it hangs after 20 to 50 calls - especially with the 1.5.0_04. On the system with the new kernel I'm about run 25000, still running :-)
cd /tmp while true; do date rm -f t1.class $JAVA_HOME/bin/javac t1.java done ========================= ========================= =======================
JKB wrote:
Le 30-10-2005, à propos de
Re: ASRock K7VTxx,
seb666fr2@yahoo.fr écrivait dans fr.comp.sys.pc :
En faisait une recherche rapide sur la bug database de sun, je viens de
trouver un rapport
de bug (relativement récent) qui semble correspondre à la descripti on
de
votre problème :
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6298877
Merci pour cette info. Je n'arrive pas à accéder ce matin à cette
base. Y a-t-il une façon de corriger le truc ?
Cordialement,
JKB
J'ai fait une copie compléte du rapport ci-dessous. A la fin, il y a
la description d'une méthode pour reproduire le bug ce qui devrait
permettre de déterminer si votre problème est le même. Hélas il ne
semble pas y avoir de workaround. Une solution pourrait toutefois
consister à essayer avec une jvm tierce (d'ibm par exemple).
========================= ========================= =======================
Bug ID: 6298877
Votes 7
Synopsis JVM hangs on Linux only, no thread dump possible
Category hotspot:jvm_interface
Reported Against b09
Release Fixed
State In progress, bug
Related Bugs
Submit Date 19-JUL-2005
Description One of our customers run a number of different web
applications in a production environment. Most of the applications run
on Sun Sparc hardware running Solaris 8 and the Sun JVM for Solaris. A
small number of applications run on a Sun V20z server with AMD64
processor and RedHat AS3 Linux OS, and the Sun JVM for Linux.
Product is actually J2SE 1.4.2_08 (the latest).
All applications work fine in the Solaris/Sparc environment. and most
applications work fine on the Linux/AMD environment.
One application on Linux (only!) hangs at irregular intervals. The
hang is particularly vexing to solve because the JVM does not respond
to a kill -QUIT (which normally produces a thread dump). They have
been able to take a core dump of the application with gdb, but because
the JVM builds don't have symbols they are unable to make much sense of
the core dump. They don't believe this is an application issue due to
the fact that the exact same application never hangs on the Solaris
platform. However, even if it is an application issue, it's very hard
to debug because the JVM won't allow to take a thread dump so they have
virtually no information about what might be causing the hang. They
are able to terminate the JVM however.
Environment On Which The Problem Is Seen :
OS is 64-bit RedHat AS3, platform is a Sun V20Z server (64-bit AMD
processor). They are running the 32-bit JVM.
Need to diagonize the hang on Linux platform JVM.
Running Linux strace (the equivalent of Solaris truss) shows only that
the jvm is stuck in a futex(2) call, which suggests a deadlock (I
believe futex(2) is used on Linux to implement Java locking).
The complete core dump of the application in its hung state taken with
gdb is available at :
Path : /net/hanwka-home1.sfbay/global/export/home1/27/sd158479/ariba
File Name : core-2.zip and
core-3.zip -->> Totally two files.
Work Around N/A
xxxxx@xxxxx 2005-07-19 19:35:16 GMT
Evaluation N/A
Comments
Include a link with my name & email
Submitted On 05-AUG-2005
Water_Moon I recognized the same thing like the "Bug ID:6298877" in the
environment as following.
OS : Red Hat Enterprise Linux ES release 3
CPU : 2
JDK : j2sdk1.4.2_05, 1.4.2_06, 1.4.2_08
I didn't see a thread dump when I sent the command "kill -QUIT PID" to
the hanging JVM. And I only saw that the JVM was recieved the QUIT
signal like following.
JVM hanged with "-Xint" option to turn off the HotSpot.
I didn't recognized the same thing in the environment as following.
Solaris9 : j2sdk1.4.2_05, 1.4.2_06, 1.4.2_08, single CPU
RHEL ES 3: j2sdk1.3.1, j2sdk1.5.0, dual CPUs
Submitted On 16-AUG-2005
Me too!
Same behaviour with different JDKs under Linux RH ES 3 (1.4.X, 1.5.X)
2 processors, kill -QUIT has no effect, stopped in a futex.
Application works fine for month in production under Solaris 8.
Today I upgraded the kernel from 2.4.20-8smp to 2.6.12.3 and (until)
now everything works fine - i. e. the bug vanished (AFAIK RH patched
the old 2.4 kernel with some 2.6 futexes...)
I found a way to reproduce this bug. Run the attached script. On the
buggy system, it hangs after 20 to 50 calls - especially with the
1.5.0_04. On the system with the new kernel I'm about run 25000,
still running :-)
cd /tmp
while true;
do
date
rm -f t1.class
$JAVA_HOME/bin/javac t1.java
done
========================= ========================= =======================
Le 30-10-2005, à propos de Re: ASRock K7VTxx, écrivait dans fr.comp.sys.pc :
En faisait une recherche rapide sur la bug database de sun, je viens de trouver un rapport de bug (relativement récent) qui semble correspondre à la descripti on de votre problème : http://bugs.sun.com/bugdatabase/view_bug.do?bug_idb98877
Merci pour cette info. Je n'arrive pas à accéder ce matin à cette base. Y a-t-il une façon de corriger le truc ?
Cordialement,
JKB
J'ai fait une copie compléte du rapport ci-dessous. A la fin, il y a la description d'une méthode pour reproduire le bug ce qui devrait permettre de déterminer si votre problème est le même. Hélas il ne semble pas y avoir de workaround. Une solution pourrait toutefois consister à essayer avec une jvm tierce (d'ibm par exemple).
========================= ========================= ======================= Bug ID: 6298877 Votes 7 Synopsis JVM hangs on Linux only, no thread dump possible Category hotspot:jvm_interface Reported Against b09 Release Fixed State In progress, bug Related Bugs Submit Date 19-JUL-2005 Description One of our customers run a number of different web applications in a production environment. Most of the applications run on Sun Sparc hardware running Solaris 8 and the Sun JVM for Solaris. A small number of applications run on a Sun V20z server with AMD64 processor and RedHat AS3 Linux OS, and the Sun JVM for Linux.
Product is actually J2SE 1.4.2_08 (the latest).
All applications work fine in the Solaris/Sparc environment. and most applications work fine on the Linux/AMD environment.
One application on Linux (only!) hangs at irregular intervals. The hang is particularly vexing to solve because the JVM does not respond to a kill -QUIT (which normally produces a thread dump). They have been able to take a core dump of the application with gdb, but because the JVM builds don't have symbols they are unable to make much sense of the core dump. They don't believe this is an application issue due to the fact that the exact same application never hangs on the Solaris platform. However, even if it is an application issue, it's very hard to debug because the JVM won't allow to take a thread dump so they have virtually no information about what might be causing the hang. They are able to terminate the JVM however.
Environment On Which The Problem Is Seen : OS is 64-bit RedHat AS3, platform is a Sun V20Z server (64-bit AMD processor). They are running the 32-bit JVM.
Need to diagonize the hang on Linux platform JVM.
Running Linux strace (the equivalent of Solaris truss) shows only that the jvm is stuck in a futex(2) call, which suggests a deadlock (I believe futex(2) is used on Linux to implement Java locking). The complete core dump of the application in its hung state taken with gdb is available at : Path : /net/hanwka-home1.sfbay/global/export/home1/27/sd158479/ariba File Name : core-2.zip and core-3.zip -->> Totally two files.
2005-07-19 19:35:15 GMT 2005-07-19 20:05:33 GMT
Work Around N/A 2005-07-19 19:35:16 GMT
Evaluation N/A
Comments Include a link with my name & email
Submitted On 05-AUG-2005 Water_Moon I recognized the same thing like the "Bug ID:6298877" in the environment as following. OS : Red Hat Enterprise Linux ES release 3 CPU : 2 JDK : j2sdk1.4.2_05, 1.4.2_06, 1.4.2_08
I didn't see a thread dump when I sent the command "kill -QUIT PID" to the hanging JVM. And I only saw that the JVM was recieved the QUIT signal like following.
JVM hanged with "-Xint" option to turn off the HotSpot.
I didn't recognized the same thing in the environment as following. Solaris9 : j2sdk1.4.2_05, 1.4.2_06, 1.4.2_08, single CPU RHEL ES 3: j2sdk1.3.1, j2sdk1.5.0, dual CPUs
Submitted On 16-AUG-2005 Me too!
Same behaviour with different JDKs under Linux RH ES 3 (1.4.X, 1.5.X) 2 processors, kill -QUIT has no effect, stopped in a futex. Application works fine for month in production under Solaris 8.
Today I upgraded the kernel from 2.4.20-8smp to 2.6.12.3 and (until) now everything works fine - i. e. the bug vanished (AFAIK RH patched the old 2.4 kernel with some 2.6 futexes...)
I found a way to reproduce this bug. Run the attached script. On the buggy system, it hangs after 20 to 50 calls - especially with the 1.5.0_04. On the system with the new kernel I'm about run 25000, still running :-)
cd /tmp while true; do date rm -f t1.class $JAVA_HOME/bin/javac t1.java done ========================= ========================= =======================
