Salut,
Décidément c'est ma journée bouteilles à la mer.
Je viens de mettre à jour une FC 9 vers FC 11 et là, surprise j'ai un programme qui ne marche plus. Après un nettoyage complet des binaires, et une recompilation intégrale, le programme s'arrête dans un malloc et attend indéfiniment. Précisément l'attente se produit dans __lll_lock_wait_private() un machin écrit en assembleur de la libc. Le genre de truc que je ne sais pas lire. J'ai un peu de mal à imaginer ce qui peut produire ce genre de blocage. Quelqu'un a une idée ?
NB :
- il ne s'agit ni d'une allocation de taille nulle, ni d'une allocation de taille gigantesque. Juste un tout petit tableau...
- Le programme fonctionne normalement sur FC10, sur diverses versions d'ubuntu, etc.
Forum Programmation.c lowlevellock
23
oct.
2009
# Corruption lente?
Posté par maxix . Évalué à 2.
[^] # Re: Corruption lente?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# mtrace, ltrace, strace
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mtrace, ltrace, strace
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
La sortie de ltrace est la suivante (je garde un peu plus que le nécessaire mais tout de même pas la totalité) :
14:36:18.993572 printf("number of basis functions: nbss"... <unfinished ...>14:36:18.993731 SYS_write(1, "number of basis functions: nbss"..., 41number of basis functions: nbss = 1536
) = 41 <0.000019>
14:36:18.993923 <... printf resumed> ) = 41 <0.000226>
14:36:18.993972 malloc(2640 <unfinished ...>
14:36:18.994054 SYS_futex(0x3b0a169e80, 0, 2, 0, 0x3b09f330e1
Là le programme s'arrête(il s'agit du lowlevellock dont je parlais).
En lui envoyant un SIGINT on rajoute les lignes suivantes :
^C) = -512 <193.742098>14:39:30.736303 --- SIGINT (Interrupt) ---
14:39:30.736481 +++ killed by SIGINT +++
Je ne connaissais pas ltrace. Est-ce que cela vous semble apporter plus d'informations que le backtrace du debogueur ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: mtrace, ltrace, strace
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mtrace, ltrace, strace
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
#0 __lll_lock_wait_private ()at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
#1 0x0000003b09e7cc43 in _L_lock_9907 () at hooks.c:126
#2 0x0000003b09e7a8d7 in *__GI___libc_malloc (bytes=100) at malloc.c:3635
#3 0x0000003b09e6eea9 in _IO_vasprintf (result_ptr=0x7fffffffd8f8,
format=0x0, args=0x7fffffffd7e0) at vasprintf.c:52
#4 0x0000003b09e4fd08 in ___asprintf (string_ptr=0x3b0a169e80, format=0x0)
at asprintf.c:37
#5 0x0000003b09e2c2c3 in *__GI___assert_fail (
assertion=0x3b09f36388 "(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offs"...,
file=<value optimized out>, line=3074, function=0x3b09f333e4 "sYSMALLOc")
at assert.c:61
#6 0x0000003b09e78fdb in sYSMALLOc (av=<value optimized out>,
nb=<value optimized out>) at malloc.c:3071
#7 _int_malloc (av=<value optimized out>, nb=<value optimized out>)
at malloc.c:4702
#8 0x0000003b09e7a8e2 in *__GI___libc_malloc (bytes=2640) at malloc.c:3638
#9 0x000000000041908d in readInput (sprm=0x7fffffffe2f0) at readInput.c:61
#10 0x000000000043d428 in main () at dim.c:95
Mon problème c'est que j'ai beaucoup de mal à imaginer ce qui pourrait provoquer un comportement comme ça dans mon code. (Hors ça viens quasiment à coup sûre d'une bogue de mon code : j'imagine mal pouvoir démarrer complètement linux, l'environnement de bureau, gcc, etc, sans jamais avoir le même problème si l'erreur venait de la libc.)
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: mtrace, ltrace, stracej
Posté par Krunch (site web personnel) . Évalué à 2.
Je suspecte deux bugs :
- dans ton code qui a peté le heap bien avant ce malloc() ;
- dans malloc() parce qu'il ne devrait pas se réappeler sans tenir compte du futex qu'il a déjà.
Je crois que mon pic de Ballmer est à 8 bières.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mtrace, ltrace, stracej
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: mtrace, ltrace, stracej
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mtrace, ltrace, stracej
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.