2010-07-12 23 views
4

valgrind signale les erreurs de mémoire non initialisée de code comme ceci:Est-ce que valgrind suit l'initialisation de la mémoire via les pilotes?

unsigned char buf[100]; 
struct driver_command cmd; 
cmd.len = sizeof(buf); 
cmd.buf = buf; 
ioctl(my_driver_fd, READ, &cmd); 

for(i = 0; i < sizeof(buf); i++) 
{ 
    foo(buf[i]); /* <<--- uninit use error from valgrind */ 
} 

Si je memset() buf avant l'appel du pilote, l'erreur disparaît.

Est-ce que valgrind peut détecter si le pilote Linux écrit correctement dans le tampon? (J'ai regardé le code du pilote, et il semble être correct, mais peut-être qu'il me manque quelque chose.)

Ou passe-t-il simplement l'appel du conducteur et n'a aucun moyen de savoir que le tampon a été écrit à l'intérieur le noyau?

Merci.

+1

À moins que l'ioctl ne memset (ou similaire) valgrind rapporte correctement ici. – ezpz

+0

@ezpz: Le pilote est censé écrire 100 octets dans buf ... l'ioctl est une manière maladroite de faire un read(). (Il y a plus de configuration impliquée pas affichée ici.) – bstpierre

+0

Ahh, j'ai raté le 'READ' la première fois. – ezpz

Répondre

7

Valgrind ne peut évidemment pas suivre l'exécution dans le noyau, mais il connaît la sémantique visible de la plupart des appels système. Mais ioctl est trop imprévisible. Si vous aviez codé votre pilote de façon à ce que ce soit un appel read, il serait correct. C'est une meilleure pratique de toute façon.

+0

Merci Zack, c'est à peu près ce que je pensais. Il y a un peu plus de contexte autour du code, et read() n'aurait pas beaucoup de sens. (Bien que ce ne soit pas mon pilote et je ne peux pas vraiment le changer.) – bstpierre

+3

Je voulais dire que vous pourriez inclure 'memcheck.h', puis utiliser' VALGRIND_MAKE_MEM_DEFINED' au lieu de 'memset'. Ce sera plus rapide. – zwol

+0

Bien! Merci encore. – bstpierre