Reprise du message précédent :
up

Je ne pense pas que le -march utilise vraiment les instructions supplémentaires, ou alors rarement. Par contre si tu as du code assembleur 3D Now... Dans tous les cas, une mauvaise instruction ça fait un SIGILL, pas un deadlock.

ben c'est fait pour, mais faut dire que gcc 3.3.4, c'est pas un monstre de vectorisation ...
 

ouais, en y réflechissant j'ai eu une illustration avec mplayer (compilé -march), qui au bout d'un moment perdait l'image, mais gardait le son. le process de l'image migrait et devait se prendre un SIGILL (quel noyau le gère alors, celui qui a accueilli le process ou celui qui l'a migré ? ). bon, c'est pas très grave comme problème, rien à voir avec les deadlocks que je me suis mangé ... Pour avoir une trace de l'erreur, y a un moyen ?
 
 

Avec OpenMosix, les signaux sont transmis, donc c'est sur la machine sur laquelle le process a été lancé que le SIGILL doit se manifester. Pour ce qui est d'avoir une trace, je dirais que la méthode classique est d'attacher un gdb ou d'envoyer un SIGSEGV à la main pour avoir un core dump.

 
je voulais dire une trace du deadlock  

Oui, bin tu attaches le gdb au processus deadlocké, comme ça tu vois ce qu'il est en train de faire.

tiens, jamais fait ce truc ... faut surement que le programme soit compilé avec les infos de débuggage non ?
En meme temps, y a 99/100 pour que le deadlock vienne du noyau 2.4.28 +patch openmosix. et le debuggage du noyau, heum heum !
 

A priori oui, il faut qu'il soit compilé en -g, mais même s'il est strippé, on peut obtenir des infos utiles sur la pile.
 
Et pour le déboguage du noyau, UML
Mais UML avec OpenMosix, comment dire... argh ?

kdb aussi pour le debuggage du noyau