Petite question de méthodologie. Lorsque vous avez un code assez
gros (qui a passé tous les tests unitaires avec succès) et qui sur
un couple architecture/OS précis plante avec une corruption du tas,
comment faites-vous pour isoler le problème ?
Je m'explique. J'ai un gros programme de calcul (qui fait des tas de
fork() et de pthread_create()). Ce programme a été développé puis testé
en long, en large et en travers sous Linux/amd64. Sous
Solaris/sparc64, il plante aléatoirement sur une violation d'accès
(libmalloc et libmtmalloc). En forçant l'utilisation de la libumem,
il échoue toujours avec une corruption du tas. Je pensais
tout d'abord à un sombre problème d'alignement qui faisait qu'un
tableau dépassait quelque part mais cela ne semble pas être le cas.
J'ai essayé de trouver dans quelle partie du programme cette
corruption avait lieu sans succès.
mdb ne m'est d'aucun secours (les différentes tâches sont
synchronisées par des signaux et mdb gère ça très mal). En fait,
l'utilisation de mbd fait que le programme entre dans des deadlocks.
Malgré cela, je me suis acharné et mdb ne m'a montré aucune écriture
illégale à l'adresse en question.
gdb me permet de faire une analyse post-mortem, mais sans me dire ce
qui a bien pu écraser ce bout de mémoire.
libumem provoque un plantage _toujours_ au même moment, mais je
n'arrive pas à voir vec libumem ce qui provoque ce plantage
(l'horodatage renvoyé par mdb ::umem_status n'existe pas dans le
fichier de transaction !).
Partant du principe que l'informatique est quelque chose de
reprodctible, j'ai fait tourner ce programme dans valgrind pas loin
d'une semaine sous Linux/amd64 et valgrind n'a renvoyé aucune erreur
(avec la libumem sous Solaris, ça merdoie dès le début). J'ai aussi
poussé le vice à compiler le programme sous Linux/sparc64 histoire
de confirmer ou d'infirmer le rapport entre le bug et le processeur.
Le programme a tourné là aussi plusieurs jours sans provoquer
d'erreur.
J'ai essayé plus tordu : electric fence, mais le programme en
question manipule énormément de données et il explose sur un "out of
memory".
En fait, mon problème est de savoir si mon code est fautif ou s'il
s'agit de la libpq de PostgreSQL voire de getaddrinfo() de Solaris
(le code plante dans __IPv6_malloc() appelé depuis getaddrinfo()
lui-même appelé depuis une fonction de la libpq.a alors que la pile
IPv6 n'est pas configurée sur le serveur en question).
Merci de vos avis,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Fri, 17 Dec 2010 17:05:59 +0000 (UTC), JKB écrivait :
Le Fri, 17 Dec 2010 15:41:47 +0000 (UTC), Marc écrivait :
JKB wrote:
Petite question de méthodologie. Lorsque vous avez un code assez gros (qui a passé tous les tests unitaires avec succès) et qui sur un couple architecture/OS précis plante avec une corruption du tas, comment faites-vous pour isoler le problème ?
En plus de ce qui est déjà fait, j'aurais sans doute essayé de faire tourner dans dbx avec check -all. Mais sans conviction.
Tiens, je vais essayer après la fin du purify en cours.
Mouarf...
Write to unallocated (wua) on thread 1: Attempting to write 8 bytes at address 0xffffffff7f500088 () stopped in _pthread_atfork at 0xffffffff5ad4b380 0xffffffff5ad4b380: _pthread_atfork+0x00a0: ba,a 0xffffffff5ab65b44 ! 0xffffffff5ab65b44
C'est d'autant plus marrant que cette fonction n'est pas appelée depuis mon code mais depuis une routine interne de la libc !
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Fri, 17 Dec 2010 17:05:59 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Le Fri, 17 Dec 2010 15:41:47 +0000 (UTC),
Marc <marc.glisse@gmail.com> écrivait :
JKB wrote:
Petite question de méthodologie. Lorsque vous avez un code assez
gros (qui a passé tous les tests unitaires avec succès) et qui sur
un couple architecture/OS précis plante avec une corruption du tas,
comment faites-vous pour isoler le problème ?
En plus de ce qui est déjà fait, j'aurais sans doute essayé de faire
tourner dans dbx avec check -all. Mais sans conviction.
Tiens, je vais essayer après la fin du purify en cours.
Mouarf...
Write to unallocated (wua) on thread 1:
Attempting to write 8 bytes at address 0xffffffff7f500088
t@1 (l@1) stopped in _pthread_atfork at 0xffffffff5ad4b380
0xffffffff5ad4b380: _pthread_atfork+0x00a0: ba,a
0xffffffff5ab65b44 ! 0xffffffff5ab65b44
C'est d'autant plus marrant que cette fonction n'est pas appelée
depuis mon code mais depuis une routine interne de la libc !
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Fri, 17 Dec 2010 17:05:59 +0000 (UTC), JKB écrivait :
Le Fri, 17 Dec 2010 15:41:47 +0000 (UTC), Marc écrivait :
JKB wrote:
Petite question de méthodologie. Lorsque vous avez un code assez gros (qui a passé tous les tests unitaires avec succès) et qui sur un couple architecture/OS précis plante avec une corruption du tas, comment faites-vous pour isoler le problème ?
En plus de ce qui est déjà fait, j'aurais sans doute essayé de faire tourner dans dbx avec check -all. Mais sans conviction.
Tiens, je vais essayer après la fin du purify en cours.
Mouarf...
Write to unallocated (wua) on thread 1: Attempting to write 8 bytes at address 0xffffffff7f500088 () stopped in _pthread_atfork at 0xffffffff5ad4b380 0xffffffff5ad4b380: _pthread_atfork+0x00a0: ba,a 0xffffffff5ab65b44 ! 0xffffffff5ab65b44
C'est d'autant plus marrant que cette fonction n'est pas appelée depuis mon code mais depuis une routine interne de la libc !
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le Sat, 18 Dec 2010 13:25:26 +0000 (UTC), JKB écrivait :
Le Fri, 17 Dec 2010 17:05:59 +0000 (UTC), JKB écrivait :
Le Fri, 17 Dec 2010 15:41:47 +0000 (UTC), Marc écrivait :
JKB wrote:
Petite question de méthodologie. Lorsque vous avez un code assez gros (qui a passé tous les tests unitaires avec succès) et qui sur un couple architecture/OS précis plante avec une corruption du tas, comment faites-vous pour isoler le problème ?
En plus de ce qui est déjà fait, j'aurais sans doute essayé de faire tourner dans dbx avec check -all. Mais sans conviction.
Tiens, je vais essayer après la fin du purify en cours.
Mouarf...
Write to unallocated (wua) on thread 1: Attempting to write 8 bytes at address 0xffffffff7f500088 () stopped in _pthread_atfork at 0xffffffff5ad4b380 0xffffffff5ad4b380: _pthread_atfork+0x00a0: ba,a 0xffffffff5ab65b44 ! 0xffffffff5ab65b44
C'est d'autant plus marrant que cette fonction n'est pas appelée depuis mon code mais depuis une routine interne de la libc !
J'oubliais :
Remouarf :
current thread: =>[1] _pthread_atfork(0xffffffff6a9116b0, 0xffffffff6a9119a0, 0xffffffff6a9119b0, 0xffffffff7f5001c0, 0x11263c, 0xffffffff5aef7f60), at 0xffffffff5ad4b31c [2] umem_startup(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8, 0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at 0xffffffff6a918648 [3] _init(0xffffffff7f7361b8, 0xffffffff7f738c58, 0x11a830, 0x0, 0xffffffff7f736c60, 0x861), at 0xffffffff6a91bf00 [4] call_init(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8, 0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at 0xffffffff7f618184 [5] setup(0x0, 0x2500602, 0x2500602, 0x47, 0xc10001, 0xffffffff7f736540), at 0xffffffff7f617660 [6] _setup(0xb00, 0xffffffff7ffff7f8, 0xffffffff7f605a20, 0x100000040, 0x0, 0xffffffffffffffff), at 0xffffffff7f626ee4 [7] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7f60aa58
Je _hais_ l'informatique ! La bibliothèque de debug est moisie...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Sat, 18 Dec 2010 13:25:26 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Le Fri, 17 Dec 2010 17:05:59 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Le Fri, 17 Dec 2010 15:41:47 +0000 (UTC),
Marc <marc.glisse@gmail.com> écrivait :
JKB wrote:
Petite question de méthodologie. Lorsque vous avez un code assez
gros (qui a passé tous les tests unitaires avec succès) et qui sur
un couple architecture/OS précis plante avec une corruption du tas,
comment faites-vous pour isoler le problème ?
En plus de ce qui est déjà fait, j'aurais sans doute essayé de faire
tourner dans dbx avec check -all. Mais sans conviction.
Tiens, je vais essayer après la fin du purify en cours.
Mouarf...
Write to unallocated (wua) on thread 1:
Attempting to write 8 bytes at address 0xffffffff7f500088
t@1 (l@1) stopped in _pthread_atfork at 0xffffffff5ad4b380
0xffffffff5ad4b380: _pthread_atfork+0x00a0: ba,a
0xffffffff5ab65b44 ! 0xffffffff5ab65b44
C'est d'autant plus marrant que cette fonction n'est pas appelée
depuis mon code mais depuis une routine interne de la libc !
J'oubliais :
Remouarf :
current thread: t@1
=>[1] _pthread_atfork(0xffffffff6a9116b0, 0xffffffff6a9119a0,
0xffffffff6a9119b0, 0xffffffff7f5001c0, 0x11263c, 0xffffffff5aef7f60),
at 0xffffffff5ad4b31c
[2] umem_startup(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8,
0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at
0xffffffff6a918648
[3] _init(0xffffffff7f7361b8, 0xffffffff7f738c58, 0x11a830, 0x0,
0xffffffff7f736c60, 0x861), at 0xffffffff6a91bf00
[4] call_init(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8,
0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at 0xffffffff7f618184
[5] setup(0x0, 0x2500602, 0x2500602, 0x47, 0xc10001,
0xffffffff7f736540), at 0xffffffff7f617660
[6] _setup(0xb00, 0xffffffff7ffff7f8, 0xffffffff7f605a20,
0x100000040, 0x0, 0xffffffffffffffff), at 0xffffffff7f626ee4
[7] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7f60aa58
Je _hais_ l'informatique ! La bibliothèque de debug est moisie...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Sat, 18 Dec 2010 13:25:26 +0000 (UTC), JKB écrivait :
Le Fri, 17 Dec 2010 17:05:59 +0000 (UTC), JKB écrivait :
Le Fri, 17 Dec 2010 15:41:47 +0000 (UTC), Marc écrivait :
JKB wrote:
Petite question de méthodologie. Lorsque vous avez un code assez gros (qui a passé tous les tests unitaires avec succès) et qui sur un couple architecture/OS précis plante avec une corruption du tas, comment faites-vous pour isoler le problème ?
En plus de ce qui est déjà fait, j'aurais sans doute essayé de faire tourner dans dbx avec check -all. Mais sans conviction.
Tiens, je vais essayer après la fin du purify en cours.
Mouarf...
Write to unallocated (wua) on thread 1: Attempting to write 8 bytes at address 0xffffffff7f500088 () stopped in _pthread_atfork at 0xffffffff5ad4b380 0xffffffff5ad4b380: _pthread_atfork+0x00a0: ba,a 0xffffffff5ab65b44 ! 0xffffffff5ab65b44
C'est d'autant plus marrant que cette fonction n'est pas appelée depuis mon code mais depuis une routine interne de la libc !
J'oubliais :
Remouarf :
current thread: =>[1] _pthread_atfork(0xffffffff6a9116b0, 0xffffffff6a9119a0, 0xffffffff6a9119b0, 0xffffffff7f5001c0, 0x11263c, 0xffffffff5aef7f60), at 0xffffffff5ad4b31c [2] umem_startup(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8, 0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at 0xffffffff6a918648 [3] _init(0xffffffff7f7361b8, 0xffffffff7f738c58, 0x11a830, 0x0, 0xffffffff7f736c60, 0x861), at 0xffffffff6a91bf00 [4] call_init(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8, 0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at 0xffffffff7f618184 [5] setup(0x0, 0x2500602, 0x2500602, 0x47, 0xc10001, 0xffffffff7f736540), at 0xffffffff7f617660 [6] _setup(0xb00, 0xffffffff7ffff7f8, 0xffffffff7f605a20, 0x100000040, 0x0, 0xffffffffffffffff), at 0xffffffff7f626ee4 [7] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7f60aa58
Je _hais_ l'informatique ! La bibliothèque de debug est moisie...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le Sat, 18 Dec 2010 13:31:55 +0000 (UTC), JKB écrivait :
Le Sat, 18 Dec 2010 13:25:26 +0000 (UTC), JKB écrivait :
Le Fri, 17 Dec 2010 17:05:59 +0000 (UTC), JKB écrivait :
Le Fri, 17 Dec 2010 15:41:47 +0000 (UTC), Marc écrivait :
JKB wrote:
Petite question de méthodologie. Lorsque vous avez un code assez gros (qui a passé tous les tests unitaires avec succès) et qui sur un couple architecture/OS précis plante avec une corruption du tas, comment faites-vous pour isoler le problème ?
En plus de ce qui est déjà fait, j'aurais sans doute essayé de faire tourner dans dbx avec check -all. Mais sans conviction.
Tiens, je vais essayer après la fin du purify en cours.
Mouarf...
Write to unallocated (wua) on thread 1: Attempting to write 8 bytes at address 0xffffffff7f500088 () stopped in _pthread_atfork at 0xffffffff5ad4b380 0xffffffff5ad4b380: _pthread_atfork+0x00a0: ba,a 0xffffffff5ab65b44 ! 0xffffffff5ab65b44
C'est d'autant plus marrant que cette fonction n'est pas appelée depuis mon code mais depuis une routine interne de la libc !
J'oubliais :
Remouarf :
current thread: =>[1] _pthread_atfork(0xffffffff6a9116b0, 0xffffffff6a9119a0, 0xffffffff6a9119b0, 0xffffffff7f5001c0, 0x11263c, 0xffffffff5aef7f60), at 0xffffffff5ad4b31c [2] umem_startup(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8, 0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at 0xffffffff6a918648 [3] _init(0xffffffff7f7361b8, 0xffffffff7f738c58, 0x11a830, 0x0, 0xffffffff7f736c60, 0x861), at 0xffffffff6a91bf00 [4] call_init(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8, 0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at 0xffffffff7f618184 [5] setup(0x0, 0x2500602, 0x2500602, 0x47, 0xc10001, 0xffffffff7f736540), at 0xffffffff7f617660 [6] _setup(0xb00, 0xffffffff7ffff7f8, 0xffffffff7f605a20, 0x100000040, 0x0, 0xffffffffffffffff), at 0xffffffff7f626ee4 [7] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7f60aa58
Je _hais_ l'informatique ! La bibliothèque de debug est moisie...
Et encore mieux :
Write to unallocated (wua) on thread 1: Attempting to write 1 byte at address 0x100ff6000 () stopped in vmem_create at 0xffffffff6a91b4b0 0xffffffff6a91b4b0: vmem_create+0x00cc: call _PROCEDURE_LINKAGE_TABLE_+0x780 [PLT] ! 0xffffffff6aa25680
dbx: internal error: signal SIGSEGV (no mapping at the fault address) dbx's coredump will appear in /tmp Fin anormale (core dumped)
On est toujours dans l'initialisation de la libumem et on n'a pas encore commencé à exécuter mon propre code.
Qu'est-ce qu'on se marre avec Solaris ;-)
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Sat, 18 Dec 2010 13:31:55 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Le Sat, 18 Dec 2010 13:25:26 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Le Fri, 17 Dec 2010 17:05:59 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Le Fri, 17 Dec 2010 15:41:47 +0000 (UTC),
Marc <marc.glisse@gmail.com> écrivait :
JKB wrote:
Petite question de méthodologie. Lorsque vous avez un code assez
gros (qui a passé tous les tests unitaires avec succès) et qui sur
un couple architecture/OS précis plante avec une corruption du tas,
comment faites-vous pour isoler le problème ?
En plus de ce qui est déjà fait, j'aurais sans doute essayé de faire
tourner dans dbx avec check -all. Mais sans conviction.
Tiens, je vais essayer après la fin du purify en cours.
Mouarf...
Write to unallocated (wua) on thread 1:
Attempting to write 8 bytes at address 0xffffffff7f500088
t@1 (l@1) stopped in _pthread_atfork at 0xffffffff5ad4b380
0xffffffff5ad4b380: _pthread_atfork+0x00a0: ba,a
0xffffffff5ab65b44 ! 0xffffffff5ab65b44
C'est d'autant plus marrant que cette fonction n'est pas appelée
depuis mon code mais depuis une routine interne de la libc !
J'oubliais :
Remouarf :
current thread: t@1
=>[1] _pthread_atfork(0xffffffff6a9116b0, 0xffffffff6a9119a0,
0xffffffff6a9119b0, 0xffffffff7f5001c0, 0x11263c, 0xffffffff5aef7f60),
at 0xffffffff5ad4b31c
[2] umem_startup(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8,
0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at
0xffffffff6a918648
[3] _init(0xffffffff7f7361b8, 0xffffffff7f738c58, 0x11a830, 0x0,
0xffffffff7f736c60, 0x861), at 0xffffffff6a91bf00
[4] call_init(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8,
0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at 0xffffffff7f618184
[5] setup(0x0, 0x2500602, 0x2500602, 0x47, 0xc10001,
0xffffffff7f736540), at 0xffffffff7f617660
[6] _setup(0xb00, 0xffffffff7ffff7f8, 0xffffffff7f605a20,
0x100000040, 0x0, 0xffffffffffffffff), at 0xffffffff7f626ee4
[7] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7f60aa58
Je _hais_ l'informatique ! La bibliothèque de debug est moisie...
Et encore mieux :
Write to unallocated (wua) on thread 1:
Attempting to write 1 byte at address 0x100ff6000
t@1 (l@1) stopped in vmem_create at 0xffffffff6a91b4b0
0xffffffff6a91b4b0: vmem_create+0x00cc: call
_PROCEDURE_LINKAGE_TABLE_+0x780 [PLT] ! 0xffffffff6aa25680
dbx: internal error: signal SIGSEGV (no mapping at the fault address)
dbx's coredump will appear in /tmp
Fin anormale (core dumped)
On est toujours dans l'initialisation de la libumem et on n'a pas
encore commencé à exécuter mon propre code.
Qu'est-ce qu'on se marre avec Solaris ;-)
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Sat, 18 Dec 2010 13:31:55 +0000 (UTC), JKB écrivait :
Le Sat, 18 Dec 2010 13:25:26 +0000 (UTC), JKB écrivait :
Le Fri, 17 Dec 2010 17:05:59 +0000 (UTC), JKB écrivait :
Le Fri, 17 Dec 2010 15:41:47 +0000 (UTC), Marc écrivait :
JKB wrote:
Petite question de méthodologie. Lorsque vous avez un code assez gros (qui a passé tous les tests unitaires avec succès) et qui sur un couple architecture/OS précis plante avec une corruption du tas, comment faites-vous pour isoler le problème ?
En plus de ce qui est déjà fait, j'aurais sans doute essayé de faire tourner dans dbx avec check -all. Mais sans conviction.
Tiens, je vais essayer après la fin du purify en cours.
Mouarf...
Write to unallocated (wua) on thread 1: Attempting to write 8 bytes at address 0xffffffff7f500088 () stopped in _pthread_atfork at 0xffffffff5ad4b380 0xffffffff5ad4b380: _pthread_atfork+0x00a0: ba,a 0xffffffff5ab65b44 ! 0xffffffff5ab65b44
C'est d'autant plus marrant que cette fonction n'est pas appelée depuis mon code mais depuis une routine interne de la libc !
J'oubliais :
Remouarf :
current thread: =>[1] _pthread_atfork(0xffffffff6a9116b0, 0xffffffff6a9119a0, 0xffffffff6a9119b0, 0xffffffff7f5001c0, 0x11263c, 0xffffffff5aef7f60), at 0xffffffff5ad4b31c [2] umem_startup(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8, 0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at 0xffffffff6a918648 [3] _init(0xffffffff7f7361b8, 0xffffffff7f738c58, 0x11a830, 0x0, 0xffffffff7f736c60, 0x861), at 0xffffffff6a91bf00 [4] call_init(0xffffffff7f736530, 0x1, 0xffffffff6a91bef8, 0xffdfffff, 0xffffffff7f736c60, 0xffffffffffffffff), at 0xffffffff7f618184 [5] setup(0x0, 0x2500602, 0x2500602, 0x47, 0xc10001, 0xffffffff7f736540), at 0xffffffff7f617660 [6] _setup(0xb00, 0xffffffff7ffff7f8, 0xffffffff7f605a20, 0x100000040, 0x0, 0xffffffffffffffff), at 0xffffffff7f626ee4 [7] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7f60aa58
Je _hais_ l'informatique ! La bibliothèque de debug est moisie...
Et encore mieux :
Write to unallocated (wua) on thread 1: Attempting to write 1 byte at address 0x100ff6000 () stopped in vmem_create at 0xffffffff6a91b4b0 0xffffffff6a91b4b0: vmem_create+0x00cc: call _PROCEDURE_LINKAGE_TABLE_+0x780 [PLT] ! 0xffffffff6aa25680
dbx: internal error: signal SIGSEGV (no mapping at the fault address) dbx's coredump will appear in /tmp Fin anormale (core dumped)
On est toujours dans l'initialisation de la libumem et on n'a pas encore commencé à exécuter mon propre code.
Qu'est-ce qu'on se marre avec Solaris ;-)
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
JKB
Le Fri, 17 Dec 2010 14:56:16 +0000 (UTC), Marc Boyer écrivait :
J'aimerai pas être à ta place. Je pense que mes compétences ont été dépassées.
Bonne chance,
Bon, je crois que j'ai quelques nouvelles rassurantes (mais ça m'a coûté une alimentation d'une U60 qui vient de me claquer dans les pattes... Passons...).
1/ Le problème ne se pose pas sous Solaris 10 (même révision) fonctionnant sur une U60. 2/ Le problème se pose sur une T1000 fonctionnant sous Solaris 10. 3/ Le problème n'apparaît qu'avec le programme compilé en 64 bits (en 32, ça passe). 4/ Le problème n'apparaît que lorsqu'aucune interface réseau n'est configurée en IPv6. 5/ Le problème n'apparaît pas sous la même version de Solaris mais pour x86/amd64. 6/ Le problème disparaît lorsque j'utilise l'implantation de getaddrinfo() issue d'eCS (j'ai eu la flemme de coder la mienne). 7/ Le problème disparaît en utilisant Solaris 11 Express.
Conclusion temporaire (parce que je teste encore) : 1/ il y a un truc bizarre dans le getaddrinfo() de la sparcv9/libc.so uniquement sur architecture sun4v. 2/ tous les debuggers de Solaris (dbx, mdb, watchmalloc et libumem avec les variables de debug positionnées) étant plus buggués que les programmes à débugguer, ils ne sont d'aucun secours (voire ils permettent de chercher le problème où il n'est pas). Seul purify semble s'en tirer mieux puisque c'est le seul outil qui n'a jamais râlé sur le code en question (seules deux fausses alarmes sont à déplorer). 3/ NE JAMAIS CHERCHER À UTILISER GETADDRINFO() SOUS SOLARIS 10 SPARC DANS UN CODE COMPILÉ EN 64 BITS LORSQUE LA PILE IPv6 EST INACTIVE !
Je vais copier cent fois la dernière phrase ;-)
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Fri, 17 Dec 2010 14:56:16 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
J'aimerai pas être à ta place.
Je pense que mes compétences ont été dépassées.
Bonne chance,
Bon, je crois que j'ai quelques nouvelles rassurantes (mais ça m'a
coûté une alimentation d'une U60 qui vient de me claquer dans les
pattes... Passons...).
1/ Le problème ne se pose pas sous Solaris 10 (même révision)
fonctionnant sur une U60.
2/ Le problème se pose sur une T1000 fonctionnant sous Solaris 10.
3/ Le problème n'apparaît qu'avec le programme compilé en 64 bits
(en 32, ça passe).
4/ Le problème n'apparaît que lorsqu'aucune interface réseau n'est
configurée en IPv6.
5/ Le problème n'apparaît pas sous la même version de Solaris mais
pour x86/amd64.
6/ Le problème disparaît lorsque j'utilise l'implantation de
getaddrinfo() issue d'eCS (j'ai eu la flemme de coder la mienne).
7/ Le problème disparaît en utilisant Solaris 11 Express.
Conclusion temporaire (parce que je teste encore) :
1/ il y a un truc bizarre dans le getaddrinfo() de la
sparcv9/libc.so uniquement sur architecture sun4v.
2/ tous les debuggers de Solaris (dbx, mdb, watchmalloc et libumem
avec les variables de debug positionnées) étant plus buggués que les
programmes à débugguer, ils ne sont d'aucun secours (voire ils
permettent de chercher le problème où il n'est pas). Seul purify
semble s'en tirer mieux puisque c'est le seul outil qui n'a jamais
râlé sur le code en question (seules deux fausses alarmes sont à
déplorer).
3/ NE JAMAIS CHERCHER À UTILISER GETADDRINFO() SOUS SOLARIS 10 SPARC
DANS UN CODE COMPILÉ EN 64 BITS LORSQUE LA PILE IPv6 EST INACTIVE !
Je vais copier cent fois la dernière phrase ;-)
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Fri, 17 Dec 2010 14:56:16 +0000 (UTC), Marc Boyer écrivait :
J'aimerai pas être à ta place. Je pense que mes compétences ont été dépassées.
Bonne chance,
Bon, je crois que j'ai quelques nouvelles rassurantes (mais ça m'a coûté une alimentation d'une U60 qui vient de me claquer dans les pattes... Passons...).
1/ Le problème ne se pose pas sous Solaris 10 (même révision) fonctionnant sur une U60. 2/ Le problème se pose sur une T1000 fonctionnant sous Solaris 10. 3/ Le problème n'apparaît qu'avec le programme compilé en 64 bits (en 32, ça passe). 4/ Le problème n'apparaît que lorsqu'aucune interface réseau n'est configurée en IPv6. 5/ Le problème n'apparaît pas sous la même version de Solaris mais pour x86/amd64. 6/ Le problème disparaît lorsque j'utilise l'implantation de getaddrinfo() issue d'eCS (j'ai eu la flemme de coder la mienne). 7/ Le problème disparaît en utilisant Solaris 11 Express.
Conclusion temporaire (parce que je teste encore) : 1/ il y a un truc bizarre dans le getaddrinfo() de la sparcv9/libc.so uniquement sur architecture sun4v. 2/ tous les debuggers de Solaris (dbx, mdb, watchmalloc et libumem avec les variables de debug positionnées) étant plus buggués que les programmes à débugguer, ils ne sont d'aucun secours (voire ils permettent de chercher le problème où il n'est pas). Seul purify semble s'en tirer mieux puisque c'est le seul outil qui n'a jamais râlé sur le code en question (seules deux fausses alarmes sont à déplorer). 3/ NE JAMAIS CHERCHER À UTILISER GETADDRINFO() SOUS SOLARIS 10 SPARC DANS UN CODE COMPILÉ EN 64 BITS LORSQUE LA PILE IPv6 EST INACTIVE !
Je vais copier cent fois la dernière phrase ;-)
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Xavier Roche
JKB a écrit :
2/ tous les debuggers de Solaris (dbx, mdb, watchmalloc et libumem avec les variables de debug positionnées) étant plus buggués que les programmes à débugguer
<rant solaris="on"> Haha le fameux dbx (on l'appelle affectueusement "daube-X") qui coredump au chargement de certains programmes, et qui ne charge pas les symboles par défaut (ce qui est une bonne idée, car une fois sur deux ça crashe aussi, surtout avec du code compilé avec gcc)
Dire que cette merde infecte indigne d'un projet d'étudiant de première année est livrée en standard ..
Il me semble cependant que gdb fonctionne un poil mieux, mais ce n'est pas garanti. (la difficulté étant de trouver les bons flags qui donneront un gdb fonctionnel - des soirées passionnantes en perspective)
La vrai solution sous sparc, en fait, c'est de ne pas l'utiliser: c'est buggé, c'est lent, c'est cher, bref on a l'impression de rouler dans une Traban des années 60 achetée au prix d'une Ferrari. Mais le commercial qui l'a vendue avait l'air tellement convaincant.. </rant>
3/ NE JAMAIS CHERCHER À UTILISER GETADDRINFO() SOUS SOLARIS 10 SPARC DANS UN CODE COMPILÉ EN 64 BITS LORSQUE LA PILE IPv6 EST INACTIVE !
Bon à savoir :) Merci en tout cas pour avoir débuggé sur ce vénérable ancêtre mourant, ça pourra m'être utile si je me penche dessus (ce qui devrait arriver un jour ou l'autre - chacun sa croix)
JKB a écrit :
2/ tous les debuggers de Solaris (dbx, mdb, watchmalloc et libumem
avec les variables de debug positionnées) étant plus buggués que les
programmes à débugguer
<rant solaris="on">
Haha le fameux dbx (on l'appelle affectueusement "daube-X") qui coredump
au chargement de certains programmes, et qui ne charge pas les symboles
par défaut (ce qui est une bonne idée, car une fois sur deux ça crashe
aussi, surtout avec du code compilé avec gcc)
Dire que cette merde infecte indigne d'un projet d'étudiant de première
année est livrée en standard ..
Il me semble cependant que gdb fonctionne un poil mieux, mais ce n'est
pas garanti. (la difficulté étant de trouver les bons flags qui
donneront un gdb fonctionnel - des soirées passionnantes en perspective)
La vrai solution sous sparc, en fait, c'est de ne pas l'utiliser: c'est
buggé, c'est lent, c'est cher, bref on a l'impression de rouler dans une
Traban des années 60 achetée au prix d'une Ferrari. Mais le commercial
qui l'a vendue avait l'air tellement convaincant..
</rant>
3/ NE JAMAIS CHERCHER À UTILISER GETADDRINFO() SOUS SOLARIS 10 SPARC
DANS UN CODE COMPILÉ EN 64 BITS LORSQUE LA PILE IPv6 EST INACTIVE !
Bon à savoir :) Merci en tout cas pour avoir débuggé sur ce vénérable
ancêtre mourant, ça pourra m'être utile si je me penche dessus (ce qui
devrait arriver un jour ou l'autre - chacun sa croix)
2/ tous les debuggers de Solaris (dbx, mdb, watchmalloc et libumem avec les variables de debug positionnées) étant plus buggués que les programmes à débugguer
<rant solaris="on"> Haha le fameux dbx (on l'appelle affectueusement "daube-X") qui coredump au chargement de certains programmes, et qui ne charge pas les symboles par défaut (ce qui est une bonne idée, car une fois sur deux ça crashe aussi, surtout avec du code compilé avec gcc)
Dire que cette merde infecte indigne d'un projet d'étudiant de première année est livrée en standard ..
Il me semble cependant que gdb fonctionne un poil mieux, mais ce n'est pas garanti. (la difficulté étant de trouver les bons flags qui donneront un gdb fonctionnel - des soirées passionnantes en perspective)
La vrai solution sous sparc, en fait, c'est de ne pas l'utiliser: c'est buggé, c'est lent, c'est cher, bref on a l'impression de rouler dans une Traban des années 60 achetée au prix d'une Ferrari. Mais le commercial qui l'a vendue avait l'air tellement convaincant.. </rant>
3/ NE JAMAIS CHERCHER À UTILISER GETADDRINFO() SOUS SOLARIS 10 SPARC DANS UN CODE COMPILÉ EN 64 BITS LORSQUE LA PILE IPv6 EST INACTIVE !
Bon à savoir :) Merci en tout cas pour avoir débuggé sur ce vénérable ancêtre mourant, ça pourra m'être utile si je me penche dessus (ce qui devrait arriver un jour ou l'autre - chacun sa croix)
JKB
Le Sat, 18 Dec 2010 23:06:15 +0100, Xavier Roche écrivait :
JKB a écrit :
2/ tous les debuggers de Solaris (dbx, mdb, watchmalloc et libumem avec les variables de debug positionnées) étant plus buggués que les programmes à débugguer
<rant solaris="on"> Haha le fameux dbx (on l'appelle affectueusement "daube-X") qui coredump au chargement de certains programmes, et qui ne charge pas les symboles par défaut (ce qui est une bonne idée, car une fois sur deux ça crashe aussi, surtout avec du code compilé avec gcc)
Dire que cette merde infecte indigne d'un projet d'étudiant de première année est livrée en standard ..
Euh... Il y a Java aussi, en standard... Poussez pas, je suis déjà dehors !
Il me semble cependant que gdb fonctionne un poil mieux, mais ce n'est pas garanti. (la difficulté étant de trouver les bons flags qui donneront un gdb fonctionnel - des soirées passionnantes en perspective)
J'ai un gdb qui fonctionne, mais il n'est pas capable de suivre un un accès à une zone mémoire (ou alors, j'ai raté un truc dans la doc, ce qui est possible...).
tchaikovski:[~/rpl/cvs/rpl/src] > gdb GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10". (gdb)
Le gros problème a été de le compiler pour débugguer du 64 bits ! Parce que les types de chez Sun filent toutes les bibliothèques pour un userland 32 bits et lorsqu'on regarde de près dans */lib/sparcv9, il en _manque_ ! Tout de suite, ça handicape pour les compilations d'outils en 64 bits !
La vrai solution sous sparc, en fait, c'est de ne pas l'utiliser: c'est buggé, c'est lent, c'est cher, bref on a l'impression de rouler dans une Traban des années 60 achetée au prix d'une Ferrari. Mais le commercial qui l'a vendue avait l'air tellement convaincant.. </rant>
Disons que ce qui m'intéressait, c'est le parallélisme de la bête et je partais du principe que Solaris était quand même fait pour cette archi. J'ai bien du Linux qui tourne sur certaines de ces machines, mais le système est un peu bancal (et il n'est pas toujours bon de remonter des bugs du noyau au type qui maintient le noyau sur Sparc). J'attends avec une certaine impatience que l'équipe de NetBSD se décide à écrire un port sun4v (le port pour UltraSPARC-III semble utilisable, et il paraît que le sparc supporte à nouveau les configurations Ross en SMP. C'est ma SS20 qui va être contente, elle qui est présentement en train de recompiler un NetBSD-current from scratch mais sur un seul processeur...).
3/ NE JAMAIS CHERCHER À UTILISER GETADDRINFO() SOUS SOLARIS 10 SPARC DANS UN CODE COMPILÉ EN 64 BITS LORSQUE LA PILE IPv6 EST INACTIVE !
Bon à savoir :) Merci en tout cas pour avoir débuggé sur ce vénérable ancêtre mourant, ça pourra m'être utile si je me penche dessus (ce qui devrait arriver un jour ou l'autre - chacun sa croix)
Bon courage. Autant j'aime assez Nexenta, autant je déteste Solaris. Je crois que depuis la version 2.5.1 (à moins que ce ne soit la 5.1), ce système ne fait de dégénérer. La chose la plus amusante est Solaris 8 avec /etc/init.d/networking restart qui panique, voire Solaris 9 sur une SS20 quadripro qui explose en vol dès que la charge augmente. Pas plus de deux processeurs avec Solaris 9 sur une SS20 (de toute façon, slowlaris les gère comme il peut, c'est-à-dire mal).
Bon, je regarde quand même ce qui se passe. J'en suis à 11486 mn de temps CPU sans explosion. Je pense que je tiens le bon bout...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Sat, 18 Dec 2010 23:06:15 +0100,
Xavier Roche <xroche@free.fr.NOSPAM.invalid> écrivait :
JKB a écrit :
2/ tous les debuggers de Solaris (dbx, mdb, watchmalloc et libumem
avec les variables de debug positionnées) étant plus buggués que les
programmes à débugguer
<rant solaris="on">
Haha le fameux dbx (on l'appelle affectueusement "daube-X") qui coredump
au chargement de certains programmes, et qui ne charge pas les symboles
par défaut (ce qui est une bonne idée, car une fois sur deux ça crashe
aussi, surtout avec du code compilé avec gcc)
Dire que cette merde infecte indigne d'un projet d'étudiant de première
année est livrée en standard ..
Euh... Il y a Java aussi, en standard... Poussez pas, je suis déjà
dehors !
Il me semble cependant que gdb fonctionne un poil mieux, mais ce n'est
pas garanti. (la difficulté étant de trouver les bons flags qui
donneront un gdb fonctionnel - des soirées passionnantes en perspective)
J'ai un gdb qui fonctionne, mais il n'est pas capable de suivre un
un accès à une zone mémoire (ou alors, j'ai raté un truc dans la
doc, ce qui est possible...).
tchaikovski:[~/rpl/cvs/rpl/src] > gdb
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10".
(gdb)
Le gros problème a été de le compiler pour débugguer du 64 bits !
Parce que les types de chez Sun filent toutes les bibliothèques
pour un userland 32 bits et lorsqu'on regarde de près dans
*/lib/sparcv9, il en _manque_ ! Tout de suite, ça handicape pour les
compilations d'outils en 64 bits !
La vrai solution sous sparc, en fait, c'est de ne pas l'utiliser: c'est
buggé, c'est lent, c'est cher, bref on a l'impression de rouler dans une
Traban des années 60 achetée au prix d'une Ferrari. Mais le commercial
qui l'a vendue avait l'air tellement convaincant..
</rant>
Disons que ce qui m'intéressait, c'est le parallélisme de la bête et
je partais du principe que Solaris était quand même fait pour cette archi.
J'ai bien du Linux qui tourne sur certaines de ces machines, mais le
système est un peu bancal (et il n'est pas toujours bon de remonter
des bugs du noyau au type qui maintient le noyau sur Sparc). J'attends
avec une certaine impatience que l'équipe de NetBSD se décide à écrire
un port sun4v (le port pour UltraSPARC-III semble utilisable, et il
paraît que le sparc supporte à nouveau les configurations Ross en
SMP. C'est ma SS20 qui va être contente, elle qui est présentement
en train de recompiler un NetBSD-current from scratch mais sur un
seul processeur...).
3/ NE JAMAIS CHERCHER À UTILISER GETADDRINFO() SOUS SOLARIS 10 SPARC
DANS UN CODE COMPILÉ EN 64 BITS LORSQUE LA PILE IPv6 EST INACTIVE !
Bon à savoir :) Merci en tout cas pour avoir débuggé sur ce vénérable
ancêtre mourant, ça pourra m'être utile si je me penche dessus (ce qui
devrait arriver un jour ou l'autre - chacun sa croix)
Bon courage. Autant j'aime assez Nexenta, autant je déteste Solaris.
Je crois que depuis la version 2.5.1 (à moins que ce ne soit la
5.1), ce système ne fait de dégénérer. La chose la plus amusante est
Solaris 8 avec /etc/init.d/networking restart qui panique, voire
Solaris 9 sur une SS20 quadripro qui explose en vol dès que la
charge augmente. Pas plus de deux processeurs avec Solaris 9 sur une
SS20 (de toute façon, slowlaris les gère comme il peut, c'est-à-dire
mal).
Bon, je regarde quand même ce qui se passe. J'en suis à
11486 mn de temps CPU sans explosion. Je pense que je tiens le bon
bout...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Sat, 18 Dec 2010 23:06:15 +0100, Xavier Roche écrivait :
JKB a écrit :
2/ tous les debuggers de Solaris (dbx, mdb, watchmalloc et libumem avec les variables de debug positionnées) étant plus buggués que les programmes à débugguer
<rant solaris="on"> Haha le fameux dbx (on l'appelle affectueusement "daube-X") qui coredump au chargement de certains programmes, et qui ne charge pas les symboles par défaut (ce qui est une bonne idée, car une fois sur deux ça crashe aussi, surtout avec du code compilé avec gcc)
Dire que cette merde infecte indigne d'un projet d'étudiant de première année est livrée en standard ..
Euh... Il y a Java aussi, en standard... Poussez pas, je suis déjà dehors !
Il me semble cependant que gdb fonctionne un poil mieux, mais ce n'est pas garanti. (la difficulté étant de trouver les bons flags qui donneront un gdb fonctionnel - des soirées passionnantes en perspective)
J'ai un gdb qui fonctionne, mais il n'est pas capable de suivre un un accès à une zone mémoire (ou alors, j'ai raté un truc dans la doc, ce qui est possible...).
tchaikovski:[~/rpl/cvs/rpl/src] > gdb GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10". (gdb)
Le gros problème a été de le compiler pour débugguer du 64 bits ! Parce que les types de chez Sun filent toutes les bibliothèques pour un userland 32 bits et lorsqu'on regarde de près dans */lib/sparcv9, il en _manque_ ! Tout de suite, ça handicape pour les compilations d'outils en 64 bits !
La vrai solution sous sparc, en fait, c'est de ne pas l'utiliser: c'est buggé, c'est lent, c'est cher, bref on a l'impression de rouler dans une Traban des années 60 achetée au prix d'une Ferrari. Mais le commercial qui l'a vendue avait l'air tellement convaincant.. </rant>
Disons que ce qui m'intéressait, c'est le parallélisme de la bête et je partais du principe que Solaris était quand même fait pour cette archi. J'ai bien du Linux qui tourne sur certaines de ces machines, mais le système est un peu bancal (et il n'est pas toujours bon de remonter des bugs du noyau au type qui maintient le noyau sur Sparc). J'attends avec une certaine impatience que l'équipe de NetBSD se décide à écrire un port sun4v (le port pour UltraSPARC-III semble utilisable, et il paraît que le sparc supporte à nouveau les configurations Ross en SMP. C'est ma SS20 qui va être contente, elle qui est présentement en train de recompiler un NetBSD-current from scratch mais sur un seul processeur...).
3/ NE JAMAIS CHERCHER À UTILISER GETADDRINFO() SOUS SOLARIS 10 SPARC DANS UN CODE COMPILÉ EN 64 BITS LORSQUE LA PILE IPv6 EST INACTIVE !
Bon à savoir :) Merci en tout cas pour avoir débuggé sur ce vénérable ancêtre mourant, ça pourra m'être utile si je me penche dessus (ce qui devrait arriver un jour ou l'autre - chacun sa croix)
Bon courage. Autant j'aime assez Nexenta, autant je déteste Solaris. Je crois que depuis la version 2.5.1 (à moins que ce ne soit la 5.1), ce système ne fait de dégénérer. La chose la plus amusante est Solaris 8 avec /etc/init.d/networking restart qui panique, voire Solaris 9 sur une SS20 quadripro qui explose en vol dès que la charge augmente. Pas plus de deux processeurs avec Solaris 9 sur une SS20 (de toute façon, slowlaris les gère comme il peut, c'est-à-dire mal).
Bon, je regarde quand même ce qui se passe. J'en suis à 11486 mn de temps CPU sans explosion. Je pense que je tiens le bon bout...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
