Salut,
Je suis pas trop sûr que ce soit le meilleur endroit pour poser la
question, mais c'est pas le pire :-)
Au bureau, on a des machines en 64 bits (enfin, dans mon équipe, on en a
... 1) qui tournent avec RH Entreprise 3.5. Et j'ai constaté des trucs
bizarres qui me font douter de la stabilité de la chose.
Par exemple, avec un gros programme dans lequel je développe, une erreur
de code (un dépassement de tableau, truc con...) m'a causé à peu près
systématiquement des plantages. Non, pas de mon code, ça, c'est normal.
Des plantages de la machine. Complets. Hard reboot obligatoire. Comme
c'est pas un code qui va triturer le noyau ou je-ne-sais quel autre
machin de bas niveau, ça me semble déjà pas normal du tout...
J'ai aussi eu d'autres plantages un peu aléatoires dans les libs de Qt
(qui ont été recompilées sur cette machine), ou encore, un jour que la
machine était pas mal chargée, gcc qui a crashé en me disant que j'avais
un bug dans mon hardware ou mon système (c'était la première fois que je
voyais ça !).
Bref, des comportements non seulement pas normaux, mais en plus qui ne
dépendent pas d'une application particulière, ce qui me fait penser soit
à un problème de matériel, soit à un problème du noyau ou des
bibliothèques système.
Et ce qui me fait soupçonner le 64 bits, c'est que les mêmes opérations,
sur la même machine, mais avec du code compilé en 32 bits, tournent sans
le moindre problème (enfin si, mon dépassement de tableau crashait, mais
que mon code, pas la machine !).
Ma question, c'est donc : est-ce que quelqu'un est au courant de ce
genre d'instabilités sur RH EL 3.5 ? Faut-il que je demande à mes admins
sys (*) de chercher ce qui se passe, ou est-ce que c'est une problème de
RH plus globalement ?
Merci !
Salut,
Je suis pas trop sûr que ce soit le meilleur endroit pour poser la
question, mais c'est pas le pire :-)
Au bureau, on a des machines en 64 bits (enfin, dans mon équipe, on en a
... 1) qui tournent avec RH Entreprise 3.5. Et j'ai constaté des trucs
bizarres qui me font douter de la stabilité de la chose.
Par exemple, avec un gros programme dans lequel je développe, une erreur
de code (un dépassement de tableau, truc con...) m'a causé à peu près
systématiquement des plantages. Non, pas de mon code, ça, c'est normal.
Des plantages de la machine. Complets. Hard reboot obligatoire. Comme
c'est pas un code qui va triturer le noyau ou je-ne-sais quel autre
machin de bas niveau, ça me semble déjà pas normal du tout...
J'ai aussi eu d'autres plantages un peu aléatoires dans les libs de Qt
(qui ont été recompilées sur cette machine), ou encore, un jour que la
machine était pas mal chargée, gcc qui a crashé en me disant que j'avais
un bug dans mon hardware ou mon système (c'était la première fois que je
voyais ça !).
Bref, des comportements non seulement pas normaux, mais en plus qui ne
dépendent pas d'une application particulière, ce qui me fait penser soit
à un problème de matériel, soit à un problème du noyau ou des
bibliothèques système.
Et ce qui me fait soupçonner le 64 bits, c'est que les mêmes opérations,
sur la même machine, mais avec du code compilé en 32 bits, tournent sans
le moindre problème (enfin si, mon dépassement de tableau crashait, mais
que mon code, pas la machine !).
Ma question, c'est donc : est-ce que quelqu'un est au courant de ce
genre d'instabilités sur RH EL 3.5 ? Faut-il que je demande à mes admins
sys (*) de chercher ce qui se passe, ou est-ce que c'est une problème de
RH plus globalement ?
Merci !
Salut,
Je suis pas trop sûr que ce soit le meilleur endroit pour poser la
question, mais c'est pas le pire :-)
Au bureau, on a des machines en 64 bits (enfin, dans mon équipe, on en a
... 1) qui tournent avec RH Entreprise 3.5. Et j'ai constaté des trucs
bizarres qui me font douter de la stabilité de la chose.
Par exemple, avec un gros programme dans lequel je développe, une erreur
de code (un dépassement de tableau, truc con...) m'a causé à peu près
systématiquement des plantages. Non, pas de mon code, ça, c'est normal.
Des plantages de la machine. Complets. Hard reboot obligatoire. Comme
c'est pas un code qui va triturer le noyau ou je-ne-sais quel autre
machin de bas niveau, ça me semble déjà pas normal du tout...
J'ai aussi eu d'autres plantages un peu aléatoires dans les libs de Qt
(qui ont été recompilées sur cette machine), ou encore, un jour que la
machine était pas mal chargée, gcc qui a crashé en me disant que j'avais
un bug dans mon hardware ou mon système (c'était la première fois que je
voyais ça !).
Bref, des comportements non seulement pas normaux, mais en plus qui ne
dépendent pas d'une application particulière, ce qui me fait penser soit
à un problème de matériel, soit à un problème du noyau ou des
bibliothèques système.
Et ce qui me fait soupçonner le 64 bits, c'est que les mêmes opérations,
sur la même machine, mais avec du code compilé en 32 bits, tournent sans
le moindre problème (enfin si, mon dépassement de tableau crashait, mais
que mon code, pas la machine !).
Ma question, c'est donc : est-ce que quelqu'un est au courant de ce
genre d'instabilités sur RH EL 3.5 ? Faut-il que je demande à mes admins
sys (*) de chercher ce qui se passe, ou est-ce que c'est une problème de
RH plus globalement ?
Merci !
Par exemple, avec un gros programme dans lequel je développe, une erreur
de code (un dépassement de tableau, truc con...) m'a causé à peu près
systématiquement des plantages. Non, pas de mon code, ça, c'est normal.
Des plantages de la machine. Complets. Hard reboot obligatoire. Comme
c'est pas un code qui va triturer le noyau ou je-ne-sais quel autre
machin de bas niveau, ça me semble déjà pas normal du tout...
J'ai aussi eu d'autres plantages un peu aléatoires dans les libs de Qt
(qui ont été recompilées sur cette machine), ou encore, un jour que la
machine était pas mal chargée, gcc qui a crashé en me disant que j'avais
un bug dans mon hardware ou mon système (c'était la première fois que je
voyais ça !).
Bref, des comportements non seulement pas normaux, mais en plus qui ne
dépendent pas d'une application particulière, ce qui me fait penser soit
à un problème de matériel, soit à un problème du noyau ou des
bibliothèques système.
Et ce qui me fait soupçonner le 64 bits, c'est que les mêmes opérations,
sur la même machine, mais avec du code compilé en 32 bits, tournent sans
le moindre problème (enfin si, mon dépassement de tableau crashait, mais
que mon code, pas la machine !).
Ma question, c'est donc : est-ce que quelqu'un est au courant de ce
genre d'instabilités sur RH EL 3.5 ? Faut-il que je demande à mes admins
sys (*) de chercher ce qui se passe, ou est-ce que c'est une problème de
RH plus globalement ?
Par exemple, avec un gros programme dans lequel je développe, une erreur
de code (un dépassement de tableau, truc con...) m'a causé à peu près
systématiquement des plantages. Non, pas de mon code, ça, c'est normal.
Des plantages de la machine. Complets. Hard reboot obligatoire. Comme
c'est pas un code qui va triturer le noyau ou je-ne-sais quel autre
machin de bas niveau, ça me semble déjà pas normal du tout...
J'ai aussi eu d'autres plantages un peu aléatoires dans les libs de Qt
(qui ont été recompilées sur cette machine), ou encore, un jour que la
machine était pas mal chargée, gcc qui a crashé en me disant que j'avais
un bug dans mon hardware ou mon système (c'était la première fois que je
voyais ça !).
Bref, des comportements non seulement pas normaux, mais en plus qui ne
dépendent pas d'une application particulière, ce qui me fait penser soit
à un problème de matériel, soit à un problème du noyau ou des
bibliothèques système.
Et ce qui me fait soupçonner le 64 bits, c'est que les mêmes opérations,
sur la même machine, mais avec du code compilé en 32 bits, tournent sans
le moindre problème (enfin si, mon dépassement de tableau crashait, mais
que mon code, pas la machine !).
Ma question, c'est donc : est-ce que quelqu'un est au courant de ce
genre d'instabilités sur RH EL 3.5 ? Faut-il que je demande à mes admins
sys (*) de chercher ce qui se passe, ou est-ce que c'est une problème de
RH plus globalement ?
Par exemple, avec un gros programme dans lequel je développe, une erreur
de code (un dépassement de tableau, truc con...) m'a causé à peu près
systématiquement des plantages. Non, pas de mon code, ça, c'est normal.
Des plantages de la machine. Complets. Hard reboot obligatoire. Comme
c'est pas un code qui va triturer le noyau ou je-ne-sais quel autre
machin de bas niveau, ça me semble déjà pas normal du tout...
J'ai aussi eu d'autres plantages un peu aléatoires dans les libs de Qt
(qui ont été recompilées sur cette machine), ou encore, un jour que la
machine était pas mal chargée, gcc qui a crashé en me disant que j'avais
un bug dans mon hardware ou mon système (c'était la première fois que je
voyais ça !).
Bref, des comportements non seulement pas normaux, mais en plus qui ne
dépendent pas d'une application particulière, ce qui me fait penser soit
à un problème de matériel, soit à un problème du noyau ou des
bibliothèques système.
Et ce qui me fait soupçonner le 64 bits, c'est que les mêmes opérations,
sur la même machine, mais avec du code compilé en 32 bits, tournent sans
le moindre problème (enfin si, mon dépassement de tableau crashait, mais
que mon code, pas la machine !).
Ma question, c'est donc : est-ce que quelqu'un est au courant de ce
genre d'instabilités sur RH EL 3.5 ? Faut-il que je demande à mes admins
sys (*) de chercher ce qui se passe, ou est-ce que c'est une problème de
RH plus globalement ?
Par exemple, avec un gros programme dans lequel je développe, une erreur
de code (un dépassement de tableau, truc con...) m'a causé à peu près
systématiquement des plantages. Non, pas de mon code, ça, c'est normal.
Des plantages de la machine. Complets. Hard reboot obligatoire. Comme
c'est pas un code qui va triturer le noyau ou je-ne-sais quel autre
machin de bas niveau, ça me semble déjà pas normal du tout...
Quel noyau ?
Y-a-t-il un oops qui est généré ?
Pourrais-tu donner un exemple minimal de code qui aboutisse à ce
résultat (ou à défaut ton code complet) ?
La plupart des logiciels ont été codé (salement) dans l'optique de
toujours tourner sur des systèmes 32 bits. L'erreur la plus fréquente
lorsque ces programmes passent en 64 bits, c'est que le code contient
des casts de pointeurs vers des entiers de 32 bits (alors qu'en
architecture 64 bits, les pointeurs font 64 bits) et réciproquement.
Si tu considères cela en sachant que Linux intègre maintenant l'ASLR de
PaX (Address Space Layout Randomization) et que les adresses ne seront
pas forcément prises parmi les 2^32 premières cases mémoire,
- Ces erreurs sont aléatoires (tant que l'on reste dans un espace
mémoire de 32 bits tout se passe bien mais dès qu'on en sort... pouf!)
Ce que je ne comprends pas du tout, par contre, c'est comment un
programme qui réside en user-space puisse faire un freeze complet du
système. Le kernel-space est tout de même protégé par le MMU du
processeur.
Il est donc possible qu'il y ait un bug dans le noyau (ou
alors seul X freeze, mais je suppose que lorsque tu dis que la machine
freeze tu as bien vérifié que cela incluait le noyau)
ou de chroot (voir
plus loin).
De toute façon, les distributions RedHat et Mandriva sont de fausses
64bits. Elles exécutent du code x86-32 dans un chroot. Ce qui n'est pas
vraiment pareil que d'exécuter vraiment en 64bits.
Et ce qui me fait soupçonner le 64 bits, c'est que les mêmes opérations,
sur la même machine, mais avec du code compilé en 32 bits, tournent sans
le moindre problème (enfin si, mon dépassement de tableau crashait, mais
que mon code, pas la machine !).
Hum, cela me fait penser que si tu exécutais du code 64bits dans un
chroot 32bits, il y a dû y avoir quelques problèmes. Cela indique
peut-être un bug au niveau du chroot plutôt, non ?
Personellement, j'utilise une Debian AMD64 (encore expérimentale) depuis
peu. Je commence à me renseigner sur les différents problèmes et les
bugs que je trouve n'ont jamais ne serait-ce qu'approché ce que tu décris.
Bref, je suis intrigué ! :)
Par exemple, avec un gros programme dans lequel je développe, une erreur
de code (un dépassement de tableau, truc con...) m'a causé à peu près
systématiquement des plantages. Non, pas de mon code, ça, c'est normal.
Des plantages de la machine. Complets. Hard reboot obligatoire. Comme
c'est pas un code qui va triturer le noyau ou je-ne-sais quel autre
machin de bas niveau, ça me semble déjà pas normal du tout...
Quel noyau ?
Y-a-t-il un oops qui est généré ?
Pourrais-tu donner un exemple minimal de code qui aboutisse à ce
résultat (ou à défaut ton code complet) ?
La plupart des logiciels ont été codé (salement) dans l'optique de
toujours tourner sur des systèmes 32 bits. L'erreur la plus fréquente
lorsque ces programmes passent en 64 bits, c'est que le code contient
des casts de pointeurs vers des entiers de 32 bits (alors qu'en
architecture 64 bits, les pointeurs font 64 bits) et réciproquement.
Si tu considères cela en sachant que Linux intègre maintenant l'ASLR de
PaX (Address Space Layout Randomization) et que les adresses ne seront
pas forcément prises parmi les 2^32 premières cases mémoire,
- Ces erreurs sont aléatoires (tant que l'on reste dans un espace
mémoire de 32 bits tout se passe bien mais dès qu'on en sort... pouf!)
Ce que je ne comprends pas du tout, par contre, c'est comment un
programme qui réside en user-space puisse faire un freeze complet du
système. Le kernel-space est tout de même protégé par le MMU du
processeur.
Il est donc possible qu'il y ait un bug dans le noyau (ou
alors seul X freeze, mais je suppose que lorsque tu dis que la machine
freeze tu as bien vérifié que cela incluait le noyau)
ou de chroot (voir
plus loin).
De toute façon, les distributions RedHat et Mandriva sont de fausses
64bits. Elles exécutent du code x86-32 dans un chroot. Ce qui n'est pas
vraiment pareil que d'exécuter vraiment en 64bits.
Et ce qui me fait soupçonner le 64 bits, c'est que les mêmes opérations,
sur la même machine, mais avec du code compilé en 32 bits, tournent sans
le moindre problème (enfin si, mon dépassement de tableau crashait, mais
que mon code, pas la machine !).
Hum, cela me fait penser que si tu exécutais du code 64bits dans un
chroot 32bits, il y a dû y avoir quelques problèmes. Cela indique
peut-être un bug au niveau du chroot plutôt, non ?
Personellement, j'utilise une Debian AMD64 (encore expérimentale) depuis
peu. Je commence à me renseigner sur les différents problèmes et les
bugs que je trouve n'ont jamais ne serait-ce qu'approché ce que tu décris.
Bref, je suis intrigué ! :)
Par exemple, avec un gros programme dans lequel je développe, une erreur
de code (un dépassement de tableau, truc con...) m'a causé à peu près
systématiquement des plantages. Non, pas de mon code, ça, c'est normal.
Des plantages de la machine. Complets. Hard reboot obligatoire. Comme
c'est pas un code qui va triturer le noyau ou je-ne-sais quel autre
machin de bas niveau, ça me semble déjà pas normal du tout...
Quel noyau ?
Y-a-t-il un oops qui est généré ?
Pourrais-tu donner un exemple minimal de code qui aboutisse à ce
résultat (ou à défaut ton code complet) ?
La plupart des logiciels ont été codé (salement) dans l'optique de
toujours tourner sur des systèmes 32 bits. L'erreur la plus fréquente
lorsque ces programmes passent en 64 bits, c'est que le code contient
des casts de pointeurs vers des entiers de 32 bits (alors qu'en
architecture 64 bits, les pointeurs font 64 bits) et réciproquement.
Si tu considères cela en sachant que Linux intègre maintenant l'ASLR de
PaX (Address Space Layout Randomization) et que les adresses ne seront
pas forcément prises parmi les 2^32 premières cases mémoire,
- Ces erreurs sont aléatoires (tant que l'on reste dans un espace
mémoire de 32 bits tout se passe bien mais dès qu'on en sort... pouf!)
Ce que je ne comprends pas du tout, par contre, c'est comment un
programme qui réside en user-space puisse faire un freeze complet du
système. Le kernel-space est tout de même protégé par le MMU du
processeur.
Il est donc possible qu'il y ait un bug dans le noyau (ou
alors seul X freeze, mais je suppose que lorsque tu dis que la machine
freeze tu as bien vérifié que cela incluait le noyau)
ou de chroot (voir
plus loin).
De toute façon, les distributions RedHat et Mandriva sont de fausses
64bits. Elles exécutent du code x86-32 dans un chroot. Ce qui n'est pas
vraiment pareil que d'exécuter vraiment en 64bits.
Et ce qui me fait soupçonner le 64 bits, c'est que les mêmes opérations,
sur la même machine, mais avec du code compilé en 32 bits, tournent sans
le moindre problème (enfin si, mon dépassement de tableau crashait, mais
que mon code, pas la machine !).
Hum, cela me fait penser que si tu exécutais du code 64bits dans un
chroot 32bits, il y a dû y avoir quelques problèmes. Cela indique
peut-être un bug au niveau du chroot plutôt, non ?
Personellement, j'utilise une Debian AMD64 (encore expérimentale) depuis
peu. Je commence à me renseigner sur les différents problèmes et les
bugs que je trouve n'ont jamais ne serait-ce qu'approché ce que tu décris.
Bref, je suis intrigué ! :)
Au bureau, on a des machines en 64 bits (enfin, dans mon équipe, on en
a ... 1) qui tournent avec RH Entreprise 3.5. Et j'ai constaté des
trucs bizarres qui me font douter de la stabilité de la chose.
[...]
Chez nous nous ne sommes pas en Redhat mais en Mandrake et j'ai
rencontré des problemes assez similaires sur des bi-opterons à base de
carte mere TYAN 2882
en 32 bits pas de probleme
en 64 bits plantages bizzares , aléatoires et pas très fréquents
en fait ceci ne se produisait que sur les machines qui avaient 8
Barettes mémoires . Remplacement des 8 barettes de 512Mo par 4 barettes
de 1Go et depuis
les machines sont parfaitement stables
Si cela peut t'aider
Au bureau, on a des machines en 64 bits (enfin, dans mon équipe, on en
a ... 1) qui tournent avec RH Entreprise 3.5. Et j'ai constaté des
trucs bizarres qui me font douter de la stabilité de la chose.
[...]
Chez nous nous ne sommes pas en Redhat mais en Mandrake et j'ai
rencontré des problemes assez similaires sur des bi-opterons à base de
carte mere TYAN 2882
en 32 bits pas de probleme
en 64 bits plantages bizzares , aléatoires et pas très fréquents
en fait ceci ne se produisait que sur les machines qui avaient 8
Barettes mémoires . Remplacement des 8 barettes de 512Mo par 4 barettes
de 1Go et depuis
les machines sont parfaitement stables
Si cela peut t'aider
Au bureau, on a des machines en 64 bits (enfin, dans mon équipe, on en
a ... 1) qui tournent avec RH Entreprise 3.5. Et j'ai constaté des
trucs bizarres qui me font douter de la stabilité de la chose.
[...]
Chez nous nous ne sommes pas en Redhat mais en Mandrake et j'ai
rencontré des problemes assez similaires sur des bi-opterons à base de
carte mere TYAN 2882
en 32 bits pas de probleme
en 64 bits plantages bizzares , aléatoires et pas très fréquents
en fait ceci ne se produisait que sur les machines qui avaient 8
Barettes mémoires . Remplacement des 8 barettes de 512Mo par 4 barettes
de 1Go et depuis
les machines sont parfaitement stables
Si cela peut t'aider
Uh... Je sais pas... celui qui est en standard dans RH Enterprise 3.5 ?
(la machine est au boulot et je poste de chez moi, donc je peux pas
vérifier) C'est un 2.4, c'est tout ce que je sais.
Je sais pas... Je n'ai rien sur mes terminaux visibles au moment du
crash, mais comme la machine est complétement morte, peut-être y'a-t-il
quelque chose sur un terminal que je ne vois pas. J'ai fait un passage
rapide dans les logs, j'ai rien vu de ce genre.
Hélas. Si seulement... dans ce cas, je pourrais envoyer tout ça à nos
admins sys et ne plus me préoccuper de la chose. :-)
J'ai un code énorme (mais propriétaire -- oui, je sais, c'est pas bien,
mais c'est ça qui me nourrit ;-) )
qui provoque ce résultat de temps en
temps, sur des données relativement grosses elles-aussi. Et un peu plus
fréquemment quand d'autres personnes travaillent en même temps sur la
machine, mais rien de systèmatique non plus...
Si j'ai du temps (mouarf, on peut toujours réver), j'essaierais un jour
de générer un truc plus simple qui fasse planter tout le temps, ou au
moins très souvent. J'ai essayé rapidement quelques trucs basiques
(genre allouer suffisamment de mémoire pour que les adresses ne tiennent
plus sur 32 bits -- j'ai 2 Go de RAM et autant de swap, ça me laisse de
quoi jouer --, en une ou plusieurs fois, aller y lire/écrire,
recommencer, jouer un peu avec l'operateur placement new en C++ pour
forcer quelques goreteries, mais je n'arrive jamais à faire crasher la
machine...).
J'ai entendu parler de ce truc, mais j'avoue ne pas très bien comprendre
comment ça marche (bon, à la limite, je m'en fiche un peu) et en quoi ça
peut impacter le fonctionnement de la bête...
Oui. De fait, dans des cas où je plantais relativement régulièrement, un
passage au débuggeur (avant le crash... puisque après la machine était
morte !) m'indiquait toujours des adresses mémoires de plus de 32 bits
(enfin... un emplacement dont l'adresse ne tient pas sur 32 bits) pour
le pointeur mis en cause (celui qui pointait sur le tableau qui
débordait). Mais la réciproque n'est hélas (ou heureusement ?) pas vraie
: j'ai aussi pleins d'autres moments où j'utilise des adresses de plus
de 32 bits sans le moindre problème.
Ben, la machine ne répond plus à un ping et l'ACPI est aussi mort (pour
faire un reboot en appuyant sur le bouton, par exemple). Je ne pense pas
qu'un freeze de X puisse faire ça, non ?
Et je vois mal ce que je peux
tester d'autre (le clavier et la souris sont morts, mais ça, si X est
planté, c'est normal). Les disques ne tournaient plus du tout, mais bon,
si y'avait pas d'activité, c'est normal aussi.
Gnè ?? Tu peux détailler ? Je ne comprends pas... En quoi un chroot
permet de faire semblant d'être en 64 bits tout en étant en 32 en fait ?
À partir du moment où j'ai un programme qui addresse plus de 2 Go de
mémoire, peu importe où j'écris dans la mémoire, il me faut des adresses
réellement en 64 bits, non ?
Uh... Je sais pas... celui qui est en standard dans RH Enterprise 3.5 ?
(la machine est au boulot et je poste de chez moi, donc je peux pas
vérifier) C'est un 2.4, c'est tout ce que je sais.
Je sais pas... Je n'ai rien sur mes terminaux visibles au moment du
crash, mais comme la machine est complétement morte, peut-être y'a-t-il
quelque chose sur un terminal que je ne vois pas. J'ai fait un passage
rapide dans les logs, j'ai rien vu de ce genre.
Hélas. Si seulement... dans ce cas, je pourrais envoyer tout ça à nos
admins sys et ne plus me préoccuper de la chose. :-)
J'ai un code énorme (mais propriétaire -- oui, je sais, c'est pas bien,
mais c'est ça qui me nourrit ;-) )
qui provoque ce résultat de temps en
temps, sur des données relativement grosses elles-aussi. Et un peu plus
fréquemment quand d'autres personnes travaillent en même temps sur la
machine, mais rien de systèmatique non plus...
Si j'ai du temps (mouarf, on peut toujours réver), j'essaierais un jour
de générer un truc plus simple qui fasse planter tout le temps, ou au
moins très souvent. J'ai essayé rapidement quelques trucs basiques
(genre allouer suffisamment de mémoire pour que les adresses ne tiennent
plus sur 32 bits -- j'ai 2 Go de RAM et autant de swap, ça me laisse de
quoi jouer --, en une ou plusieurs fois, aller y lire/écrire,
recommencer, jouer un peu avec l'operateur placement new en C++ pour
forcer quelques goreteries, mais je n'arrive jamais à faire crasher la
machine...).
J'ai entendu parler de ce truc, mais j'avoue ne pas très bien comprendre
comment ça marche (bon, à la limite, je m'en fiche un peu) et en quoi ça
peut impacter le fonctionnement de la bête...
Oui. De fait, dans des cas où je plantais relativement régulièrement, un
passage au débuggeur (avant le crash... puisque après la machine était
morte !) m'indiquait toujours des adresses mémoires de plus de 32 bits
(enfin... un emplacement dont l'adresse ne tient pas sur 32 bits) pour
le pointeur mis en cause (celui qui pointait sur le tableau qui
débordait). Mais la réciproque n'est hélas (ou heureusement ?) pas vraie
: j'ai aussi pleins d'autres moments où j'utilise des adresses de plus
de 32 bits sans le moindre problème.
Ben, la machine ne répond plus à un ping et l'ACPI est aussi mort (pour
faire un reboot en appuyant sur le bouton, par exemple). Je ne pense pas
qu'un freeze de X puisse faire ça, non ?
Et je vois mal ce que je peux
tester d'autre (le clavier et la souris sont morts, mais ça, si X est
planté, c'est normal). Les disques ne tournaient plus du tout, mais bon,
si y'avait pas d'activité, c'est normal aussi.
Gnè ?? Tu peux détailler ? Je ne comprends pas... En quoi un chroot
permet de faire semblant d'être en 64 bits tout en étant en 32 en fait ?
À partir du moment où j'ai un programme qui addresse plus de 2 Go de
mémoire, peu importe où j'écris dans la mémoire, il me faut des adresses
réellement en 64 bits, non ?
Uh... Je sais pas... celui qui est en standard dans RH Enterprise 3.5 ?
(la machine est au boulot et je poste de chez moi, donc je peux pas
vérifier) C'est un 2.4, c'est tout ce que je sais.
Je sais pas... Je n'ai rien sur mes terminaux visibles au moment du
crash, mais comme la machine est complétement morte, peut-être y'a-t-il
quelque chose sur un terminal que je ne vois pas. J'ai fait un passage
rapide dans les logs, j'ai rien vu de ce genre.
Hélas. Si seulement... dans ce cas, je pourrais envoyer tout ça à nos
admins sys et ne plus me préoccuper de la chose. :-)
J'ai un code énorme (mais propriétaire -- oui, je sais, c'est pas bien,
mais c'est ça qui me nourrit ;-) )
qui provoque ce résultat de temps en
temps, sur des données relativement grosses elles-aussi. Et un peu plus
fréquemment quand d'autres personnes travaillent en même temps sur la
machine, mais rien de systèmatique non plus...
Si j'ai du temps (mouarf, on peut toujours réver), j'essaierais un jour
de générer un truc plus simple qui fasse planter tout le temps, ou au
moins très souvent. J'ai essayé rapidement quelques trucs basiques
(genre allouer suffisamment de mémoire pour que les adresses ne tiennent
plus sur 32 bits -- j'ai 2 Go de RAM et autant de swap, ça me laisse de
quoi jouer --, en une ou plusieurs fois, aller y lire/écrire,
recommencer, jouer un peu avec l'operateur placement new en C++ pour
forcer quelques goreteries, mais je n'arrive jamais à faire crasher la
machine...).
J'ai entendu parler de ce truc, mais j'avoue ne pas très bien comprendre
comment ça marche (bon, à la limite, je m'en fiche un peu) et en quoi ça
peut impacter le fonctionnement de la bête...
Oui. De fait, dans des cas où je plantais relativement régulièrement, un
passage au débuggeur (avant le crash... puisque après la machine était
morte !) m'indiquait toujours des adresses mémoires de plus de 32 bits
(enfin... un emplacement dont l'adresse ne tient pas sur 32 bits) pour
le pointeur mis en cause (celui qui pointait sur le tableau qui
débordait). Mais la réciproque n'est hélas (ou heureusement ?) pas vraie
: j'ai aussi pleins d'autres moments où j'utilise des adresses de plus
de 32 bits sans le moindre problème.
Ben, la machine ne répond plus à un ping et l'ACPI est aussi mort (pour
faire un reboot en appuyant sur le bouton, par exemple). Je ne pense pas
qu'un freeze de X puisse faire ça, non ?
Et je vois mal ce que je peux
tester d'autre (le clavier et la souris sont morts, mais ça, si X est
planté, c'est normal). Les disques ne tournaient plus du tout, mais bon,
si y'avait pas d'activité, c'est normal aussi.
Gnè ?? Tu peux détailler ? Je ne comprends pas... En quoi un chroot
permet de faire semblant d'être en 64 bits tout en étant en 32 en fait ?
À partir du moment où j'ai un programme qui addresse plus de 2 Go de
mémoire, peu importe où j'écris dans la mémoire, il me faut des adresses
réellement en 64 bits, non ?
Hum, il faudrait recompiler le noyau en mode "debug" et tenter de
reproduire le bug.
Si je t'ai demandé la version du noyau c'est que des bugs relatifs aux
architectures 64 bits sont corrigés régulièrement. Tu pourrais aussi
demander aux admins de fournir un noyau plus récent (pour voir si cela
continue).
Pour ce qui est de l'ASLR, c'est assez bas niveau et cela se joue au
niveau des pages mémoires qui constituent l'espace d'adressage d'un
processus.
Il faut comprendre que ce problème est la conjonction de deux facteurs:
1) Que tu heurtes une partie de ton code qui transforme des adresse
64bits en 32bits en les tronquants à mort.
2) Que l'adresse qui est stockée dans ces variables soient en dehors des
2^32.
Si l'une des deux conditions est remplie, cela ne veut rien dire sur
l'autre.
Je persiste à croire que ton code (ou une bibliothèque que ton code
utilise) doit passer par ce style de code (pointeurs casté vers du
32bits).
Mais cela n'explique pas le crash noyau.
Et je vois mal ce que je peux
tester d'autre (le clavier et la souris sont morts, mais ça, si X est
planté, c'est normal). Les disques ne tournaient plus du tout, mais bon,
si y'avait pas d'activité, c'est normal aussi.
Si les leds du clavier clignotent c'est un kernel panic.
Hum, il faudrait recompiler le noyau en mode "debug" et tenter de
reproduire le bug.
Si je t'ai demandé la version du noyau c'est que des bugs relatifs aux
architectures 64 bits sont corrigés régulièrement. Tu pourrais aussi
demander aux admins de fournir un noyau plus récent (pour voir si cela
continue).
Pour ce qui est de l'ASLR, c'est assez bas niveau et cela se joue au
niveau des pages mémoires qui constituent l'espace d'adressage d'un
processus.
Il faut comprendre que ce problème est la conjonction de deux facteurs:
1) Que tu heurtes une partie de ton code qui transforme des adresse
64bits en 32bits en les tronquants à mort.
2) Que l'adresse qui est stockée dans ces variables soient en dehors des
2^32.
Si l'une des deux conditions est remplie, cela ne veut rien dire sur
l'autre.
Je persiste à croire que ton code (ou une bibliothèque que ton code
utilise) doit passer par ce style de code (pointeurs casté vers du
32bits).
Mais cela n'explique pas le crash noyau.
Et je vois mal ce que je peux
tester d'autre (le clavier et la souris sont morts, mais ça, si X est
planté, c'est normal). Les disques ne tournaient plus du tout, mais bon,
si y'avait pas d'activité, c'est normal aussi.
Si les leds du clavier clignotent c'est un kernel panic.
Hum, il faudrait recompiler le noyau en mode "debug" et tenter de
reproduire le bug.
Si je t'ai demandé la version du noyau c'est que des bugs relatifs aux
architectures 64 bits sont corrigés régulièrement. Tu pourrais aussi
demander aux admins de fournir un noyau plus récent (pour voir si cela
continue).
Pour ce qui est de l'ASLR, c'est assez bas niveau et cela se joue au
niveau des pages mémoires qui constituent l'espace d'adressage d'un
processus.
Il faut comprendre que ce problème est la conjonction de deux facteurs:
1) Que tu heurtes une partie de ton code qui transforme des adresse
64bits en 32bits en les tronquants à mort.
2) Que l'adresse qui est stockée dans ces variables soient en dehors des
2^32.
Si l'une des deux conditions est remplie, cela ne veut rien dire sur
l'autre.
Je persiste à croire que ton code (ou une bibliothèque que ton code
utilise) doit passer par ce style de code (pointeurs casté vers du
32bits).
Mais cela n'explique pas le crash noyau.
Et je vois mal ce que je peux
tester d'autre (le clavier et la souris sont morts, mais ça, si X est
planté, c'est normal). Les disques ne tournaient plus du tout, mais bon,
si y'avait pas d'activité, c'est normal aussi.
Si les leds du clavier clignotent c'est un kernel panic.
(**) et en plus, la hierarchie a réussi le chef d'oeuvre de changer
toutes les machines de prod, alors que nous, en R&D, on en a une seule
nouvelle (que tout le monde veut utiliser, donc). Ce qui veut dire que
les utilisateurs demandent des applis sur une config que nous n'avons
pas réellement dispo pour developper les applis. Grandiose...
Ouais, d'accord. Ça explique en effet l'aspect aléatoire des plantages.
Et probablement aussi le fait qu'ils arrivent plus souvent quand la
machine est fortement chargée, je suppose (les plages occuppées en
mémoire doivent être plus fréquemment au dela des 32 bits, non ?).
Oh, ça, je n'oserais pas prétendre le contraire :-)
Je ne crois pas faire de casts de pointeurs en int ou trucs de ce genre
dans mon code, mais je ne jurerais pas que cela n'arrive jamais. Pour le
reste, j'ai malheureusement moins de marge de manoeuvre (mais de toute
façon, vu la taille du reste du code... :-( ).
Ah, je savais pas (j'ai pas souvent des kernel panic...) ! Je sais plus
si c'était le cas...
Mais ça marche même si X a complétement freezé le clavier aussi ?
Enfin bon, vu comme c'est chiant de tester ça (genre quand tu as enfin
réussi à trouver un exemple qui plante, ça veut dire qu'il faut rebooter
la machine... et donc personne d'autre ne peut l'utiliser pendant tout
le temps que je fais les tests...), et que j'ai autre chose à faire, je
sens que ça va pas avancer très vite, cette affaire.
Merci pour tes explications !
(**) et en plus, la hierarchie a réussi le chef d'oeuvre de changer
toutes les machines de prod, alors que nous, en R&D, on en a une seule
nouvelle (que tout le monde veut utiliser, donc). Ce qui veut dire que
les utilisateurs demandent des applis sur une config que nous n'avons
pas réellement dispo pour developper les applis. Grandiose...
Ouais, d'accord. Ça explique en effet l'aspect aléatoire des plantages.
Et probablement aussi le fait qu'ils arrivent plus souvent quand la
machine est fortement chargée, je suppose (les plages occuppées en
mémoire doivent être plus fréquemment au dela des 32 bits, non ?).
Oh, ça, je n'oserais pas prétendre le contraire :-)
Je ne crois pas faire de casts de pointeurs en int ou trucs de ce genre
dans mon code, mais je ne jurerais pas que cela n'arrive jamais. Pour le
reste, j'ai malheureusement moins de marge de manoeuvre (mais de toute
façon, vu la taille du reste du code... :-( ).
Ah, je savais pas (j'ai pas souvent des kernel panic...) ! Je sais plus
si c'était le cas...
Mais ça marche même si X a complétement freezé le clavier aussi ?
Enfin bon, vu comme c'est chiant de tester ça (genre quand tu as enfin
réussi à trouver un exemple qui plante, ça veut dire qu'il faut rebooter
la machine... et donc personne d'autre ne peut l'utiliser pendant tout
le temps que je fais les tests...), et que j'ai autre chose à faire, je
sens que ça va pas avancer très vite, cette affaire.
Merci pour tes explications !
(**) et en plus, la hierarchie a réussi le chef d'oeuvre de changer
toutes les machines de prod, alors que nous, en R&D, on en a une seule
nouvelle (que tout le monde veut utiliser, donc). Ce qui veut dire que
les utilisateurs demandent des applis sur une config que nous n'avons
pas réellement dispo pour developper les applis. Grandiose...
Ouais, d'accord. Ça explique en effet l'aspect aléatoire des plantages.
Et probablement aussi le fait qu'ils arrivent plus souvent quand la
machine est fortement chargée, je suppose (les plages occuppées en
mémoire doivent être plus fréquemment au dela des 32 bits, non ?).
Oh, ça, je n'oserais pas prétendre le contraire :-)
Je ne crois pas faire de casts de pointeurs en int ou trucs de ce genre
dans mon code, mais je ne jurerais pas que cela n'arrive jamais. Pour le
reste, j'ai malheureusement moins de marge de manoeuvre (mais de toute
façon, vu la taille du reste du code... :-( ).
Ah, je savais pas (j'ai pas souvent des kernel panic...) ! Je sais plus
si c'était le cas...
Mais ça marche même si X a complétement freezé le clavier aussi ?
Enfin bon, vu comme c'est chiant de tester ça (genre quand tu as enfin
réussi à trouver un exemple qui plante, ça veut dire qu'il faut rebooter
la machine... et donc personne d'autre ne peut l'utiliser pendant tout
le temps que je fais les tests...), et que j'ai autre chose à faire, je
sens que ça va pas avancer très vite, cette affaire.
Merci pour tes explications !
Ah, je savais pas (j'ai pas souvent des kernel panic...) ! Je sais plus
si c'était le cas...
Mais ça marche même si X a complétement freezé le clavier aussi ?
Oui, X passe par le noyau pour controller le clavier... :)
Ah, je savais pas (j'ai pas souvent des kernel panic...) ! Je sais plus
si c'était le cas...
Mais ça marche même si X a complétement freezé le clavier aussi ?
Oui, X passe par le noyau pour controller le clavier... :)
Ah, je savais pas (j'ai pas souvent des kernel panic...) ! Je sais plus
si c'était le cas...
Mais ça marche même si X a complétement freezé le clavier aussi ?
Oui, X passe par le noyau pour controller le clavier... :)
Par contre, un bug dans les modules dri, ca peut planter la machine et
c'est directement lie a X.
Par contre, un bug dans les modules dri, ca peut planter la machine et
c'est directement lie a X.
Par contre, un bug dans les modules dri, ca peut planter la machine et
c'est directement lie a X.