Erreurs dans « kdevvalgrind.po »
du module kdev-valgrind.
Le fichier kdevvalgrind.po comporte :
- aucune violation de règles de traduction.
- 31 fautes d'orthographe.
Fautes d'orthographe :
Message n°28,
Original : | <html><head/><body><p>The maximum size of a stack frame. If the stack pointer moves by more than this amount then Valgrind will assume that the program is switching to a different stack.</p><p>You may need to use this option if your program has large stack-allocated arrays. Valgrind keeps track of your program's stack pointer. If it changes by more than the threshold amount, Valgrind assumes your program is switching to a different stack, and Memcheck behaves differently than it would for a stack pointer change smaller than the threshold. Usually this heuristic works well. However, if your program allocates large structures on the stack, this heuristic will be fooled, and Memcheck will subsequently report large numbers of invalid stack accesses. This option allows you to change the threshold to a different value.</p><p>You should only consider use of this option if Valgrind's debug output directs you to do so. In that case it will tell you the new threshold you should specify.</p><p>In general, allocating large structures on the stack is a bad idea, because you can easily run out of stack space, especially on systems with limited memory or which expect to support large numbers of threads each with a small stack, and also because the error checking performed by Memcheck is more effective for heap-allocated data than for stack-allocated data. If you have to use this option, you may wish to consider rewriting your code to allocate on the heap rather than on the stack.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>La taille maximale de la pile. Si le pointeur de pile se déplace de plus de cette quantité, alors Valgrind considérera que le programme bascule sur une autre pile.</p><p>Vous devriez utiliser cette option si votre programme possède des tableaux importants alloués dans la pile. Valgrind garde une trace du pointeur de pile de votre programme. Si celui-ci change de plus de la quantité définie comme seuil, Valgrind considère que le programme bascule sur une autre pile et le logiciel Memcheck se comporte différemment qu'il le devrait pour un changement de pointeur de pile restant sous le seuil de déclenchement. Généralement, cette logique sera contournée et Memcheck signalera en conséquence un grand nombre d'accès non valables à la pile. Cette option vous permet de modifier la valeur de déclenchement.</p><p> Vous devriez prendre en compte l'utilisation de cette option si la sortie de débogage de Valgrind vous demande de le faire. Dans ce cas, la nouvelle valeur de déclenchement vous sera indiquée par Valgrind.</p><p>En général, allouer dans la pile de grandes structures de données est déconseillé. En effet, vous pouvez vous retrouver facilement en débordement de pile, surtout pour les systèmes avec une quantité de mémoire limitée ou devant prendre en charge un grand nombre de process, chacun avec une pile limitée. Ainsi, la vérification réalisée par Memcheck est plus efficace pour les données allouées dans le tas local plutôt que celles allouées dans la pile. Si vous devez utiliser cette option, vous devriez envisager une ré-écriture de votre code pour une allocation dans le tas local et non dans la pile.</p></body></html> |
À la ligne 222
Rapporter un faux positif
Suggestions :
- « Process »
- « procès »
- « KProcess »
- « processus »
- « proses »
Message n°67,
Original : | <html><head/><body><p>Specify if you want to do branch prediction simulation. Further event counters are enabled: Number of executed conditional branches and related predictor misses ("Bc"/"Bcm"), executed indirect jumps and related misses of the jump address predictor ("Bi"/"Bim").</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Spécifier si vous voulez faire une simulation de prédiction de branche. D'autres compteurs d'évènements sont activés : nombre de branches conditionnelles exécutées et défauts de prédiction correspondants ("Bc" /"Bcm"), sauts indirects exécutés et défauts de saut correspondants du prédicteur d'adresse de saut ("Bi"/"Bim").</p></body></html> |
À la ligne 519
Rapporter un faux positif
Suggestions :
- « prédicateur »
- « prédicateurs »
- « réducteur »
- « producteur »
- « créditeur »
Message n°93,
Original : | <html><head/><body><p>Controls whether DRD detects data races on stack variables. Verifying stack variables is disabled by default because most programs do not share stack variables over threads.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle si le DRD détecte des accès concurrents aux données sur les variables locales. La vérification des variables de pile est désactivée par défaut car la plupart des programmes ne partagent pas leurs variables locales entre process.</p></body></html> |
À la ligne 710
Rapporter un faux positif
Suggestions :
- « Process »
- « procès »
- « KProcess »
- « processus »
- « proses »
Message n°97,
Original : | <html><head/><body><p>Whether to report races between accessing memory and freeing memory. Enabling this option may cause DRD to run slightly slower. Notes:</p><p>Don't enable this option when using custom memory allocators that use the <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__MALLOCLIKE_BLOCK</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__FREELIKE_BLOCK</span> because that would result in false positives. </p><p>Don't enable this option when using reference-counted objects because that will result in false positives, even when that code has been annotated properly with <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_BEFORE</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_AFTER</span>. See e.g. the output of the following command for an example: <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">valgrind --tool=drd --free-is-write=yes drd/tests/annotate_smart_pointer</span>.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Déterminer de signaler ou non les accès concurrents entre la mémoire en accès et en cours de libération. L'activation de cette option pourrait causer le ralentissement sensible de l'exécution de « DRD ». Remarques : </p> <p> Ne pas activer cette option lors de l'utilisation d'allocateurs de mémoire personnalisés utilisant le <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__MALLOCLIKE_BLOCK</span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__FREELIKE_BLOCK</span>. Cela pourrait conduire à des faux positifs.</p><p> Ne pas activer cette option lors de l'utilisation d'objets avec compteurs de références. En effet, cela pourra conduire à des faux positifs, même si le code a été annoté correctement avec <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_BEFORE</span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_AFTER</span>. Veuillez consulter par exemple, la sortie de la commande suivante : <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">valgrind --tool=drd --free-is-write=yes drd/tests/annotate_smart_pointer</span>.</p></body></html> |
À la ligne 750
Rapporter un faux positif
Suggestions :
- « Allocateurs »
- « d'allocataires »
- « allocateur »
- « d'allocataire »
- « d'applicateurs »
Message n°97,
Original : | <html><head/><body><p>Whether to report races between accessing memory and freeing memory. Enabling this option may cause DRD to run slightly slower. Notes:</p><p>Don't enable this option when using custom memory allocators that use the <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__MALLOCLIKE_BLOCK</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__FREELIKE_BLOCK</span> because that would result in false positives. </p><p>Don't enable this option when using reference-counted objects because that will result in false positives, even when that code has been annotated properly with <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_BEFORE</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_AFTER</span>. See e.g. the output of the following command for an example: <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">valgrind --tool=drd --free-is-write=yes drd/tests/annotate_smart_pointer</span>.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Déterminer de signaler ou non les accès concurrents entre la mémoire en accès et en cours de libération. L'activation de cette option pourrait causer le ralentissement sensible de l'exécution de « DRD ». Remarques : </p> <p> Ne pas activer cette option lors de l'utilisation d'allocateurs de mémoire personnalisés utilisant le <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__MALLOCLIKE_BLOCK</span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__FREELIKE_BLOCK</span>. Cela pourrait conduire à des faux positifs.</p><p> Ne pas activer cette option lors de l'utilisation d'objets avec compteurs de références. En effet, cela pourra conduire à des faux positifs, même si le code a été annoté correctement avec <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_BEFORE</span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_AFTER</span>. Veuillez consulter par exemple, la sortie de la commande suivante : <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">valgrind --tool=drd --free-is-write=yes drd/tests/annotate_smart_pointer</span>.</p></body></html> |
Message n°97,
Original : | <html><head/><body><p>Whether to report races between accessing memory and freeing memory. Enabling this option may cause DRD to run slightly slower. Notes:</p><p>Don't enable this option when using custom memory allocators that use the <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__MALLOCLIKE_BLOCK</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__FREELIKE_BLOCK</span> because that would result in false positives. </p><p>Don't enable this option when using reference-counted objects because that will result in false positives, even when that code has been annotated properly with <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_BEFORE</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_AFTER</span>. See e.g. the output of the following command for an example: <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">valgrind --tool=drd --free-is-write=yes drd/tests/annotate_smart_pointer</span>.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Déterminer de signaler ou non les accès concurrents entre la mémoire en accès et en cours de libération. L'activation de cette option pourrait causer le ralentissement sensible de l'exécution de « DRD ». Remarques : </p> <p> Ne pas activer cette option lors de l'utilisation d'allocateurs de mémoire personnalisés utilisant le <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__MALLOCLIKE_BLOCK</span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">VG_USERREQ__FREELIKE_BLOCK</span>. Cela pourrait conduire à des faux positifs.</p><p> Ne pas activer cette option lors de l'utilisation d'objets avec compteurs de références. En effet, cela pourra conduire à des faux positifs, même si le code a été annoté correctement avec <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_BEFORE</span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_AFTER</span>. Veuillez consulter par exemple, la sortie de la commande suivante : <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">valgrind --tool=drd --free-is-write=yes drd/tests/annotate_smart_pointer</span>.</p></body></html> |
Message n°99,
Original : | <html><head/><body><p>Whether to report calls to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_signal</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_broadcast</span> where the mutex associated with the signal through <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_wait</span> or <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_timed_wait</span> is not locked at the time the signal is sent. Sending a signal without holding a lock on the associated mutex is a common programming error which can cause subtle race conditions and unpredictable behavior. There exist some uncommon synchronization patterns however where it is safe to send a signal without holding a lock on the associated mutex.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Définit s'il faut signaler les appels à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_signal » </span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_broadcast » </span> lorsque le mutex associé au signal de <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_wait » </span> ou <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_timed_wait » </span> n'est pas verrouillé au moment où le signal est envoyé. L'envoi d'un signal sans effectuer un verrouillage du mutex correspondant est une erreur de programmation courante, pouvant causer des conditions subtiles d'accès concurrents et des comportements aléatoires. Il existe certains profils de synchronisation un peu exotiques cependant, où l'envoi d'un signal sans effectuer un verrouillage du mutex correspondant est sûr.</p></body></html> |
Message n°99,
Original : | <html><head/><body><p>Whether to report calls to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_signal</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_broadcast</span> where the mutex associated with the signal through <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_wait</span> or <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_timed_wait</span> is not locked at the time the signal is sent. Sending a signal without holding a lock on the associated mutex is a common programming error which can cause subtle race conditions and unpredictable behavior. There exist some uncommon synchronization patterns however where it is safe to send a signal without holding a lock on the associated mutex.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Définit s'il faut signaler les appels à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_signal » </span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_broadcast » </span> lorsque le mutex associé au signal de <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_wait » </span> ou <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_timed_wait » </span> n'est pas verrouillé au moment où le signal est envoyé. L'envoi d'un signal sans effectuer un verrouillage du mutex correspondant est une erreur de programmation courante, pouvant causer des conditions subtiles d'accès concurrents et des comportements aléatoires. Il existe certains profils de synchronisation un peu exotiques cependant, où l'envoi d'un signal sans effectuer un verrouillage du mutex correspondant est sûr.</p></body></html> |
Message n°99,
Original : | <html><head/><body><p>Whether to report calls to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_signal</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_broadcast</span> where the mutex associated with the signal through <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_wait</span> or <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">pthread_cond_timed_wait</span> is not locked at the time the signal is sent. Sending a signal without holding a lock on the associated mutex is a common programming error which can cause subtle race conditions and unpredictable behavior. There exist some uncommon synchronization patterns however where it is safe to send a signal without holding a lock on the associated mutex.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Définit s'il faut signaler les appels à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_signal » </span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_broadcast » </span> lorsque le mutex associé au signal de <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_wait » </span> ou <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « pthread_cond_timed_wait » </span> n'est pas verrouillé au moment où le signal est envoyé. L'envoi d'un signal sans effectuer un verrouillage du mutex correspondant est une erreur de programmation courante, pouvant causer des conditions subtiles d'accès concurrents et des comportements aléatoires. Il existe certains profils de synchronisation un peu exotiques cependant, où l'envoi d'un signal sans effectuer un verrouillage du mutex correspondant est sûr.</p></body></html> |
Message n°107,
Original : | <html><head/><body><p>Controls whether all activities during thread creation should be ignored. By default enabled only on Solaris. Solaris provides higher throughput, parallelism and scalability than other operating systems, at the cost of more fine-grained locking activity. This means for example that when a thread is created under glibc, just one big lock is used for all thread setup. Solaris libc uses several fine-grained locks and the creator thread resumes its activities as soon as possible, leaving for example stack and TLS setup sequence to the created thread. This situation confuses DRD as it assumes there is some false ordering in place between creator and created thread; and therefore many types of race conditions in the application would not be reported. To prevent such false ordering, this command line option is set to <span style=" font-family:'Monospace';">yes</span> by default on Solaris. All activity (loads, stores, client requests) is therefore ignored during:</p><p>* pthread_create() call in the creator thread </p><p>* thread creation phase (stack and TLS setup) in the created thread</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle si toutes les activités durant la création du process doivent être ignorées. Par défaut, cette option n'est activée que pour « Solaris ». Solaris met à disposition plus de capacités, de parallélisme et d'extensibilité que d'autres systèmes d'exploitation, au coût d'une activité de verrouillage plus finement adaptée. Ceci signifie par exemple que lorsqu'un processus est créé sous « glibc », un seul verrouillage de grande taille est utilisé pour le paramétrages de tous les processus. La bibliothèque « libc » de « Solaris » utilise plusieurs verrous très précis et le processus de création reprend ses activités dès que possible, en quittant par exemple, la séquence de paramétrage de la pile et du module « TLS ». Cette situation perturbe « DRD », qui considère qu'il y a un ordonnancement incorrect en cours, entre le créateur de processus et le processus créé. Ainsi, les types d'accès concurrents de l'application ne seront pas signalés. Pour prévenir ces ordonnancements incorrects, l'option en ligne de commandes est <span style=" font-family:'Monospace';">yes</span> par défaut pour Solaris. Toutes les activités (chargements, enregistrements, requêtes vers client) sont ainsi ignorés durant :</p><p>* l'appel à « pthread_create() » dans le processus créateur</p><p>* la phase de création du processus (paramétrage de la pile et de « TLS ») dans le processus créé.</p></body></html> |
À la ligne 857
Rapporter un faux positif
Suggestions :
- « Process »
- « procès »
- « KProcess »
- « processus »
- « proses »
Message n°107,
Original : | <html><head/><body><p>Controls whether all activities during thread creation should be ignored. By default enabled only on Solaris. Solaris provides higher throughput, parallelism and scalability than other operating systems, at the cost of more fine-grained locking activity. This means for example that when a thread is created under glibc, just one big lock is used for all thread setup. Solaris libc uses several fine-grained locks and the creator thread resumes its activities as soon as possible, leaving for example stack and TLS setup sequence to the created thread. This situation confuses DRD as it assumes there is some false ordering in place between creator and created thread; and therefore many types of race conditions in the application would not be reported. To prevent such false ordering, this command line option is set to <span style=" font-family:'Monospace';">yes</span> by default on Solaris. All activity (loads, stores, client requests) is therefore ignored during:</p><p>* pthread_create() call in the creator thread </p><p>* thread creation phase (stack and TLS setup) in the created thread</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle si toutes les activités durant la création du process doivent être ignorées. Par défaut, cette option n'est activée que pour « Solaris ». Solaris met à disposition plus de capacités, de parallélisme et d'extensibilité que d'autres systèmes d'exploitation, au coût d'une activité de verrouillage plus finement adaptée. Ceci signifie par exemple que lorsqu'un processus est créé sous « glibc », un seul verrouillage de grande taille est utilisé pour le paramétrages de tous les processus. La bibliothèque « libc » de « Solaris » utilise plusieurs verrous très précis et le processus de création reprend ses activités dès que possible, en quittant par exemple, la séquence de paramétrage de la pile et du module « TLS ». Cette situation perturbe « DRD », qui considère qu'il y a un ordonnancement incorrect en cours, entre le créateur de processus et le processus créé. Ainsi, les types d'accès concurrents de l'application ne seront pas signalés. Pour prévenir ces ordonnancements incorrects, l'option en ligne de commandes est <span style=" font-family:'Monospace';">yes</span> par défaut pour Solaris. Toutes les activités (chargements, enregistrements, requêtes vers client) sont ainsi ignorés durant :</p><p>* l'appel à « pthread_create() » dans le processus créateur</p><p>* la phase de création du processus (paramétrage de la pile et de « TLS ») dans le processus créé.</p></body></html> |
Message n°108,
Original : | Ignore thread creation |
---|---|
Traduction : | Ignorer la création de process |
À la ligne 874
Rapporter un faux positif
Suggestions :
- « Process »
- « procès »
- « KProcess »
- « processus »
- « proses »
Message n°121,
Original : | <html><head/><body><p>Trace all mutex activity.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Tracer toutes les activités des mutex.</p></body></html> |
Message n°122,
Original : | Trace mutex activity |
---|---|
Traduction : | Tracer une activité d'un mutex |
Message n°128,
Original : | DRD (Thread Error Detector) |
---|---|
Traduction : | DRD (Détecteur d'erreur de process) |
À la ligne 1061
Rapporter un faux positif
Suggestions :
- « Process »
- « procès »
- « KProcess »
- « processus »
- « proses »
Message n°139,
Original : | <html><head/><body><p>Controls whether all activities during thread creation should be ignored. By default enabled only on Solaris. Solaris provides higher throughput, parallelism and scalability than other operating systems, at the cost of more fine-grained locking activity. This means for example that when a thread is created under glibc, just one big lock is used for all thread setup. Solaris libc uses several fine-grained locks and the creator thread resumes its activities as soon as possible, leaving for example stack and TLS setup sequence to the created thread. This situation confuses Helgrind as it assumes there is some false ordering in place between creator and created thread; and therefore many types of race conditions in the application would not be reported. To prevent such false ordering, this command line option is set to yes by default on Solaris. All activity (loads, stores, client requests) is therefore ignored during:</p><p>* pthread_create() call in the creator thread</p><p>* thread creation phase (stack and TLS setup) in the created thread</p><p>Also new memory allocated during thread creation is untracked, that is race reporting is suppressed there. DRD does the same thing implicitly. This is necessary because Solaris libc caches many objects and reuses them for different threads and that confuses Helgrind.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle si toutes les activités durant la création du process doivent être ignorées. Par défaut, cette option n'est activée que pour « Solaris ». Solaris met à disposition plus de capacités, de parallélisme et d'extensibilité que d'autres systèmes d'exploitation, au coût d'une activité de verrouillage plus finement adaptée. Ceci signifie par exemple que lorsqu'un processus est créé sous « glibc », un seul verrouillage de grande taille est utilisé pour le paramétrages de tous les processus. La bibliothèque « libc » de « Solaris » utilise plusieurs verrous très précis et le processus de création reprend ses activités dès que possible, en quittant par exemple, la séquence de paramétrage de la pile et du module « TLS ». Cette situation perturbe « DRD », qui considère qu'il y a un ordonnancement incorrect en cours, entre le créateur de processus et le processus créé. Ainsi, les types d'accès concurrents de l'application ne seront pas signalés. Pour prévenir ces ordonnancements incorrects, l'option en ligne de commandes est « yes » par défaut pour Solaris. Toutes les activités (chargements, enregistrements, requêtes vers client) sont ainsi ignorés durant :</p><p>* l'appel à « pthread_create() » dans le processus créateur</p><p>* la phase de création du processus (paramétrage de la pile et de « TLS ») dans le processus créé.</p> <p> Ainsi, les nouvelles zones mémoire allouées durant la création du processus sont non tracées ce qui implique que les rapports d'accès concurrents sont supprimés. Le module « DRD » fait exactement la même chose implicitement. Ceci est nécessaire car la bibliothèque Solaris « libc » met de nombreux accès en cache et les réutilise pour différents processus, ce qui perturbe Helgrind. </p></body></html> |
À la ligne 1165
Rapporter un faux positif
Suggestions :
- « Process »
- « procès »
- « KProcess »
- « processus »
- « proses »
Message n°139,
Original : | <html><head/><body><p>Controls whether all activities during thread creation should be ignored. By default enabled only on Solaris. Solaris provides higher throughput, parallelism and scalability than other operating systems, at the cost of more fine-grained locking activity. This means for example that when a thread is created under glibc, just one big lock is used for all thread setup. Solaris libc uses several fine-grained locks and the creator thread resumes its activities as soon as possible, leaving for example stack and TLS setup sequence to the created thread. This situation confuses Helgrind as it assumes there is some false ordering in place between creator and created thread; and therefore many types of race conditions in the application would not be reported. To prevent such false ordering, this command line option is set to yes by default on Solaris. All activity (loads, stores, client requests) is therefore ignored during:</p><p>* pthread_create() call in the creator thread</p><p>* thread creation phase (stack and TLS setup) in the created thread</p><p>Also new memory allocated during thread creation is untracked, that is race reporting is suppressed there. DRD does the same thing implicitly. This is necessary because Solaris libc caches many objects and reuses them for different threads and that confuses Helgrind.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle si toutes les activités durant la création du process doivent être ignorées. Par défaut, cette option n'est activée que pour « Solaris ». Solaris met à disposition plus de capacités, de parallélisme et d'extensibilité que d'autres systèmes d'exploitation, au coût d'une activité de verrouillage plus finement adaptée. Ceci signifie par exemple que lorsqu'un processus est créé sous « glibc », un seul verrouillage de grande taille est utilisé pour le paramétrages de tous les processus. La bibliothèque « libc » de « Solaris » utilise plusieurs verrous très précis et le processus de création reprend ses activités dès que possible, en quittant par exemple, la séquence de paramétrage de la pile et du module « TLS ». Cette situation perturbe « DRD », qui considère qu'il y a un ordonnancement incorrect en cours, entre le créateur de processus et le processus créé. Ainsi, les types d'accès concurrents de l'application ne seront pas signalés. Pour prévenir ces ordonnancements incorrects, l'option en ligne de commandes est « yes » par défaut pour Solaris. Toutes les activités (chargements, enregistrements, requêtes vers client) sont ainsi ignorés durant :</p><p>* l'appel à « pthread_create() » dans le processus créateur</p><p>* la phase de création du processus (paramétrage de la pile et de « TLS ») dans le processus créé.</p> <p> Ainsi, les nouvelles zones mémoire allouées durant la création du processus sont non tracées ce qui implique que les rapports d'accès concurrents sont supprimés. Le module « DRD » fait exactement la même chose implicitement. Ceci est nécessaire car la bibliothèque Solaris « libc » met de nombreux accès en cache et les réutilise pour différents processus, ce qui perturbe Helgrind. </p></body></html> |
Message n°140,
Original : | <html><head/><body><p>When enabled (not the default), Helgrind treats freeing of heap memory as if the memory was written immediately before the free. This exposes races where memory is referenced by one thread, and freed by another, but there is no observable synchronization event to ensure that the reference happens before the free.</p><p>This functionality is new in Valgrind 3.7.0, and is regarded as experimental. It is not enabled by default because its interaction with custom memory allocators is not well understood at present. User feedback is welcomed.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Quand cette option est activée (ce qui n'est pas par défaut), Helgrind traite les libérations de la mémoire dans le tas local comme de la mémoire pouvant être ré-utilisée immédiatement après libération. Cela provoque des accès concurrents où la mémoire adressée par un processus et libérée par un autre. Mais, il n'y a pas d'évènement de synchronisation observable pour s'assurer que la référence arrive après la libération.</p><p>Cette fonctionnalité est nouvelle dans Valgrind 3.7.0 et est à considérer comme expérimental. Elle n'est pas activée par défaut car son interaction avec les allocateurs personnalisés de mémoire n'est pas bien compris actuellement. Les retours d'utilisateurs sont les bienvenus.</p></body></html> |
Message n°143,
Original : | Helgrind (Thread Error Detector) |
---|---|
Traduction : | Helgrind (Détecteur d'erreur de process) |
À la ligne 1212
Rapporter un faux positif
Suggestions :
- « Process »
- « procès »
- « KProcess »
- « processus »
- « proses »
Message n°188,
Original : | alloc |
---|---|
Traduction : | alloc |
À la ligne 1561
Rapporter un faux positif
Suggestions :
- « allô »
- « malloc »
- « allow »
- « al loc »
- « al-loc »
Message n°193,
Original : | <html><head/><body><p>When doing leak checking, determines how willing Memcheck is to consider different backtraces to be the same for the purposes of merging multiple leaks into a single leak report. When set to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">low</span>, only the first two entries need match. When <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">med</span>, four entries have to match. When <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">high</span>, all entries need to match.</p><p>For hardcore leak debugging, you probably want to use <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--leak-resolution=high</span> together with <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers=40</span> or some such large number.</p><p>Note that the <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--leak-resolution</span> setting does not affect Memcheck's ability to find leaks. It only changes how the results are presented.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>En réalisant une vérification de fuite mémoire, détermine comment Memcheck doit considérer les différentes traces de pile pour avoir le même traitement en fusionnant les fuites multiples dans un unique rapport de fuite mémoire. Quand cette option est positionnée à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">bas</span>, seules les deuxièmes entrées doivent correspondre. Quand cette option est positionnée à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">med</span>, quatre entrées doivent correspondre. Quand cette option est positionnée à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">haut</span>, toutes les entrées doivent correspondre.</p><p>Pour un débogage extrême de fuites mémoire, vous voudriez sûrement utiliser l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--leak-resolution=high</span> ensemble avec <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers=40</span> ou un quelque chose comme un grand nombre.</p><p>Veuillez noter que l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--leak-resolution</span> n'affecte pas la capacité de Memcheck à détecter des fuites mémoire. Cela ne change que la façon dont les résultats sont affichés.</p></body></html> |
Message n°199,
Original : | <html><head/><body><p>Controls which stack trace(s) to keep for malloc'd and/or free'd blocks. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, a stack trace is recorded at allocation time, and is associated with the block. When the block is freed, a second stack trace is recorded, and this replaces the allocation stack trace. As a result, any "use after free" errors relating to this block can only show a stack trace for where the block was freed. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-and-free</span>, both allocation and the deallocation stack traces for the block are stored. Hence a "use after free" error will show both, which may make the error easier to diagnose. Compared to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, this setting slightly increases Valgrind's memory use as the block contains two references instead of one. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc</span>, only the allocation stack trace is recorded (and reported). With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">free</span>, only the deallocation stack trace is recorded (and reported). These values somewhat decrease Valgrind's memory and cpu usage. They can be useful depending on the error types you are searching for and the level of detail you need to analyze them. For example, if you are only interested in memory leak errors, it is sufficient to record the allocation stack traces. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">none</span>, no stack traces are recorded for malloc and free operations. If your program allocates a lot of blocks and/or allocates/frees from many different stack traces, this can significantly decrease cpu and/or memory required. Of course, few details will be reported for errors related to heap blocks. </p><p>Note that once a stack trace is recorded, Valgrind keeps the stack trace in memory even if it is not referenced by any block. Some programs (for example, recursive algorithms) can generate a huge number of stack traces. If Valgrind uses too much memory in such circumstances, you can reduce the memory required with the options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> and/or by using a smaller value for the option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle quelles traces de piles conserver pour les blocs alloués par « malloc » et libérés par « free ». </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, une trace de pile est enregistrée au moment de l'allocation et est associée avec le bloc. Quand le bloc est libéré, une seconde trace de pile est enregistrée et elle remplace la trace d'allocation dans la pile. Comme résultat, toute erreur "Utilisation après libération" concernant ce bloc ne peut afficher qu'une trace de pile que suite à la libération du bloc. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-and-free » </span>, les deux traces d'allocation et de désallocation pour le bloc sont enregistrées. Par conséquent, une erreur "Utilisation après libération" sera affichée pour les deux évènements, ce qui peut rendre l'erreur plus facile à identifier. En comparaison de l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, ce paramétrage augmente légèrement l'utilisation mémoire de Valgrind puisque le bloc contient deux références au lieu d'une. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc » </span>, seule la trace de la pile d'allocations est enregistrée (et affichée. Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « free » </span>, seule la trace de pile de désallocation est enregistrée (et affichée). Ces valeurs diminuent quelque peu la consommation de mémoire et de puissance processeur à Valgrind. Ces options peuvent vous être utiles selon les types d'erreurs que vous recherchez et le niveau de détails dont vous avez besoin pour les analyser. Par exemple, si vous n'êtes intéressé que par les erreurs de fuites de mémoire, il est suffisant d'enregistrer les traces de pile d'allocation. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « none » </span>, aucune trace de pile n'est enregistrée pour les appels à « malloc » et à « free ». Si votre programme alloue beaucoup de blocs et / ou alloue / libère à partir de différentes traces de piles, ceci peut réduire significativement la consommation de mémoire et de puissance processeur nécessaires. Bien sûr, peu de détails seront fournis pour les erreurs concernant les blocs de tas local. </p> <p>Veuillez noter qu'une fois que la trace de pile est enregistrée, Valgrind conserve la trace de la pile en mémoire, même si elle n'est référencée par aucun bloc. Certains programmes (par exemple, les algorithmes récursifs) peuvent produire un nombre énorme de traces de pile. Si Valgrind utilise trop de mémoire en de tels circonstances, vous pouvez réduire la mémoire nécessaire avec les options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> et / ou en utilisant une valeur plus petite pour l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
À la ligne 1651
Rapporter un faux positif
Suggestions :
- « allô »
- « malloc »
- « allow »
- « al loc »
- « al-loc »
Message n°199,
Original : | <html><head/><body><p>Controls which stack trace(s) to keep for malloc'd and/or free'd blocks. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, a stack trace is recorded at allocation time, and is associated with the block. When the block is freed, a second stack trace is recorded, and this replaces the allocation stack trace. As a result, any "use after free" errors relating to this block can only show a stack trace for where the block was freed. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-and-free</span>, both allocation and the deallocation stack traces for the block are stored. Hence a "use after free" error will show both, which may make the error easier to diagnose. Compared to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, this setting slightly increases Valgrind's memory use as the block contains two references instead of one. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc</span>, only the allocation stack trace is recorded (and reported). With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">free</span>, only the deallocation stack trace is recorded (and reported). These values somewhat decrease Valgrind's memory and cpu usage. They can be useful depending on the error types you are searching for and the level of detail you need to analyze them. For example, if you are only interested in memory leak errors, it is sufficient to record the allocation stack traces. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">none</span>, no stack traces are recorded for malloc and free operations. If your program allocates a lot of blocks and/or allocates/frees from many different stack traces, this can significantly decrease cpu and/or memory required. Of course, few details will be reported for errors related to heap blocks. </p><p>Note that once a stack trace is recorded, Valgrind keeps the stack trace in memory even if it is not referenced by any block. Some programs (for example, recursive algorithms) can generate a huge number of stack traces. If Valgrind uses too much memory in such circumstances, you can reduce the memory required with the options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> and/or by using a smaller value for the option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle quelles traces de piles conserver pour les blocs alloués par « malloc » et libérés par « free ». </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, une trace de pile est enregistrée au moment de l'allocation et est associée avec le bloc. Quand le bloc est libéré, une seconde trace de pile est enregistrée et elle remplace la trace d'allocation dans la pile. Comme résultat, toute erreur "Utilisation après libération" concernant ce bloc ne peut afficher qu'une trace de pile que suite à la libération du bloc. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-and-free » </span>, les deux traces d'allocation et de désallocation pour le bloc sont enregistrées. Par conséquent, une erreur "Utilisation après libération" sera affichée pour les deux évènements, ce qui peut rendre l'erreur plus facile à identifier. En comparaison de l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, ce paramétrage augmente légèrement l'utilisation mémoire de Valgrind puisque le bloc contient deux références au lieu d'une. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc » </span>, seule la trace de la pile d'allocations est enregistrée (et affichée. Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « free » </span>, seule la trace de pile de désallocation est enregistrée (et affichée). Ces valeurs diminuent quelque peu la consommation de mémoire et de puissance processeur à Valgrind. Ces options peuvent vous être utiles selon les types d'erreurs que vous recherchez et le niveau de détails dont vous avez besoin pour les analyser. Par exemple, si vous n'êtes intéressé que par les erreurs de fuites de mémoire, il est suffisant d'enregistrer les traces de pile d'allocation. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « none » </span>, aucune trace de pile n'est enregistrée pour les appels à « malloc » et à « free ». Si votre programme alloue beaucoup de blocs et / ou alloue / libère à partir de différentes traces de piles, ceci peut réduire significativement la consommation de mémoire et de puissance processeur nécessaires. Bien sûr, peu de détails seront fournis pour les erreurs concernant les blocs de tas local. </p> <p>Veuillez noter qu'une fois que la trace de pile est enregistrée, Valgrind conserve la trace de la pile en mémoire, même si elle n'est référencée par aucun bloc. Certains programmes (par exemple, les algorithmes récursifs) peuvent produire un nombre énorme de traces de pile. Si Valgrind utilise trop de mémoire en de tels circonstances, vous pouvez réduire la mémoire nécessaire avec les options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> et / ou en utilisant une valeur plus petite pour l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
À la ligne 1651
Rapporter un faux positif
Suggestions :
- « allô »
- « malloc »
- « allow »
- « al loc »
- « al-loc »
Message n°199,
Original : | <html><head/><body><p>Controls which stack trace(s) to keep for malloc'd and/or free'd blocks. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, a stack trace is recorded at allocation time, and is associated with the block. When the block is freed, a second stack trace is recorded, and this replaces the allocation stack trace. As a result, any "use after free" errors relating to this block can only show a stack trace for where the block was freed. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-and-free</span>, both allocation and the deallocation stack traces for the block are stored. Hence a "use after free" error will show both, which may make the error easier to diagnose. Compared to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, this setting slightly increases Valgrind's memory use as the block contains two references instead of one. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc</span>, only the allocation stack trace is recorded (and reported). With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">free</span>, only the deallocation stack trace is recorded (and reported). These values somewhat decrease Valgrind's memory and cpu usage. They can be useful depending on the error types you are searching for and the level of detail you need to analyze them. For example, if you are only interested in memory leak errors, it is sufficient to record the allocation stack traces. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">none</span>, no stack traces are recorded for malloc and free operations. If your program allocates a lot of blocks and/or allocates/frees from many different stack traces, this can significantly decrease cpu and/or memory required. Of course, few details will be reported for errors related to heap blocks. </p><p>Note that once a stack trace is recorded, Valgrind keeps the stack trace in memory even if it is not referenced by any block. Some programs (for example, recursive algorithms) can generate a huge number of stack traces. If Valgrind uses too much memory in such circumstances, you can reduce the memory required with the options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> and/or by using a smaller value for the option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle quelles traces de piles conserver pour les blocs alloués par « malloc » et libérés par « free ». </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, une trace de pile est enregistrée au moment de l'allocation et est associée avec le bloc. Quand le bloc est libéré, une seconde trace de pile est enregistrée et elle remplace la trace d'allocation dans la pile. Comme résultat, toute erreur "Utilisation après libération" concernant ce bloc ne peut afficher qu'une trace de pile que suite à la libération du bloc. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-and-free » </span>, les deux traces d'allocation et de désallocation pour le bloc sont enregistrées. Par conséquent, une erreur "Utilisation après libération" sera affichée pour les deux évènements, ce qui peut rendre l'erreur plus facile à identifier. En comparaison de l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, ce paramétrage augmente légèrement l'utilisation mémoire de Valgrind puisque le bloc contient deux références au lieu d'une. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc » </span>, seule la trace de la pile d'allocations est enregistrée (et affichée. Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « free » </span>, seule la trace de pile de désallocation est enregistrée (et affichée). Ces valeurs diminuent quelque peu la consommation de mémoire et de puissance processeur à Valgrind. Ces options peuvent vous être utiles selon les types d'erreurs que vous recherchez et le niveau de détails dont vous avez besoin pour les analyser. Par exemple, si vous n'êtes intéressé que par les erreurs de fuites de mémoire, il est suffisant d'enregistrer les traces de pile d'allocation. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « none » </span>, aucune trace de pile n'est enregistrée pour les appels à « malloc » et à « free ». Si votre programme alloue beaucoup de blocs et / ou alloue / libère à partir de différentes traces de piles, ceci peut réduire significativement la consommation de mémoire et de puissance processeur nécessaires. Bien sûr, peu de détails seront fournis pour les erreurs concernant les blocs de tas local. </p> <p>Veuillez noter qu'une fois que la trace de pile est enregistrée, Valgrind conserve la trace de la pile en mémoire, même si elle n'est référencée par aucun bloc. Certains programmes (par exemple, les algorithmes récursifs) peuvent produire un nombre énorme de traces de pile. Si Valgrind utilise trop de mémoire en de tels circonstances, vous pouvez réduire la mémoire nécessaire avec les options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> et / ou en utilisant une valeur plus petite pour l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
À la ligne 1651
Rapporter un faux positif
Suggestions :
- « dés allocation »
- « dés-allocation »
- « d'allocation »
- « d'allocations »
- « dislocation »
Message n°199,
Original : | <html><head/><body><p>Controls which stack trace(s) to keep for malloc'd and/or free'd blocks. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, a stack trace is recorded at allocation time, and is associated with the block. When the block is freed, a second stack trace is recorded, and this replaces the allocation stack trace. As a result, any "use after free" errors relating to this block can only show a stack trace for where the block was freed. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-and-free</span>, both allocation and the deallocation stack traces for the block are stored. Hence a "use after free" error will show both, which may make the error easier to diagnose. Compared to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, this setting slightly increases Valgrind's memory use as the block contains two references instead of one. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc</span>, only the allocation stack trace is recorded (and reported). With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">free</span>, only the deallocation stack trace is recorded (and reported). These values somewhat decrease Valgrind's memory and cpu usage. They can be useful depending on the error types you are searching for and the level of detail you need to analyze them. For example, if you are only interested in memory leak errors, it is sufficient to record the allocation stack traces. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">none</span>, no stack traces are recorded for malloc and free operations. If your program allocates a lot of blocks and/or allocates/frees from many different stack traces, this can significantly decrease cpu and/or memory required. Of course, few details will be reported for errors related to heap blocks. </p><p>Note that once a stack trace is recorded, Valgrind keeps the stack trace in memory even if it is not referenced by any block. Some programs (for example, recursive algorithms) can generate a huge number of stack traces. If Valgrind uses too much memory in such circumstances, you can reduce the memory required with the options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> and/or by using a smaller value for the option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle quelles traces de piles conserver pour les blocs alloués par « malloc » et libérés par « free ». </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, une trace de pile est enregistrée au moment de l'allocation et est associée avec le bloc. Quand le bloc est libéré, une seconde trace de pile est enregistrée et elle remplace la trace d'allocation dans la pile. Comme résultat, toute erreur "Utilisation après libération" concernant ce bloc ne peut afficher qu'une trace de pile que suite à la libération du bloc. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-and-free » </span>, les deux traces d'allocation et de désallocation pour le bloc sont enregistrées. Par conséquent, une erreur "Utilisation après libération" sera affichée pour les deux évènements, ce qui peut rendre l'erreur plus facile à identifier. En comparaison de l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, ce paramétrage augmente légèrement l'utilisation mémoire de Valgrind puisque le bloc contient deux références au lieu d'une. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc » </span>, seule la trace de la pile d'allocations est enregistrée (et affichée. Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « free » </span>, seule la trace de pile de désallocation est enregistrée (et affichée). Ces valeurs diminuent quelque peu la consommation de mémoire et de puissance processeur à Valgrind. Ces options peuvent vous être utiles selon les types d'erreurs que vous recherchez et le niveau de détails dont vous avez besoin pour les analyser. Par exemple, si vous n'êtes intéressé que par les erreurs de fuites de mémoire, il est suffisant d'enregistrer les traces de pile d'allocation. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « none » </span>, aucune trace de pile n'est enregistrée pour les appels à « malloc » et à « free ». Si votre programme alloue beaucoup de blocs et / ou alloue / libère à partir de différentes traces de piles, ceci peut réduire significativement la consommation de mémoire et de puissance processeur nécessaires. Bien sûr, peu de détails seront fournis pour les erreurs concernant les blocs de tas local. </p> <p>Veuillez noter qu'une fois que la trace de pile est enregistrée, Valgrind conserve la trace de la pile en mémoire, même si elle n'est référencée par aucun bloc. Certains programmes (par exemple, les algorithmes récursifs) peuvent produire un nombre énorme de traces de pile. Si Valgrind utilise trop de mémoire en de tels circonstances, vous pouvez réduire la mémoire nécessaire avec les options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> et / ou en utilisant une valeur plus petite pour l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
À la ligne 1651
Rapporter un faux positif
Suggestions :
- « allô »
- « malloc »
- « allow »
- « al loc »
- « al-loc »
Message n°199,
Original : | <html><head/><body><p>Controls which stack trace(s) to keep for malloc'd and/or free'd blocks. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, a stack trace is recorded at allocation time, and is associated with the block. When the block is freed, a second stack trace is recorded, and this replaces the allocation stack trace. As a result, any "use after free" errors relating to this block can only show a stack trace for where the block was freed. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-and-free</span>, both allocation and the deallocation stack traces for the block are stored. Hence a "use after free" error will show both, which may make the error easier to diagnose. Compared to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, this setting slightly increases Valgrind's memory use as the block contains two references instead of one. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc</span>, only the allocation stack trace is recorded (and reported). With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">free</span>, only the deallocation stack trace is recorded (and reported). These values somewhat decrease Valgrind's memory and cpu usage. They can be useful depending on the error types you are searching for and the level of detail you need to analyze them. For example, if you are only interested in memory leak errors, it is sufficient to record the allocation stack traces. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">none</span>, no stack traces are recorded for malloc and free operations. If your program allocates a lot of blocks and/or allocates/frees from many different stack traces, this can significantly decrease cpu and/or memory required. Of course, few details will be reported for errors related to heap blocks. </p><p>Note that once a stack trace is recorded, Valgrind keeps the stack trace in memory even if it is not referenced by any block. Some programs (for example, recursive algorithms) can generate a huge number of stack traces. If Valgrind uses too much memory in such circumstances, you can reduce the memory required with the options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> and/or by using a smaller value for the option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle quelles traces de piles conserver pour les blocs alloués par « malloc » et libérés par « free ». </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, une trace de pile est enregistrée au moment de l'allocation et est associée avec le bloc. Quand le bloc est libéré, une seconde trace de pile est enregistrée et elle remplace la trace d'allocation dans la pile. Comme résultat, toute erreur "Utilisation après libération" concernant ce bloc ne peut afficher qu'une trace de pile que suite à la libération du bloc. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-and-free » </span>, les deux traces d'allocation et de désallocation pour le bloc sont enregistrées. Par conséquent, une erreur "Utilisation après libération" sera affichée pour les deux évènements, ce qui peut rendre l'erreur plus facile à identifier. En comparaison de l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, ce paramétrage augmente légèrement l'utilisation mémoire de Valgrind puisque le bloc contient deux références au lieu d'une. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc » </span>, seule la trace de la pile d'allocations est enregistrée (et affichée. Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « free » </span>, seule la trace de pile de désallocation est enregistrée (et affichée). Ces valeurs diminuent quelque peu la consommation de mémoire et de puissance processeur à Valgrind. Ces options peuvent vous être utiles selon les types d'erreurs que vous recherchez et le niveau de détails dont vous avez besoin pour les analyser. Par exemple, si vous n'êtes intéressé que par les erreurs de fuites de mémoire, il est suffisant d'enregistrer les traces de pile d'allocation. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « none » </span>, aucune trace de pile n'est enregistrée pour les appels à « malloc » et à « free ». Si votre programme alloue beaucoup de blocs et / ou alloue / libère à partir de différentes traces de piles, ceci peut réduire significativement la consommation de mémoire et de puissance processeur nécessaires. Bien sûr, peu de détails seront fournis pour les erreurs concernant les blocs de tas local. </p> <p>Veuillez noter qu'une fois que la trace de pile est enregistrée, Valgrind conserve la trace de la pile en mémoire, même si elle n'est référencée par aucun bloc. Certains programmes (par exemple, les algorithmes récursifs) peuvent produire un nombre énorme de traces de pile. Si Valgrind utilise trop de mémoire en de tels circonstances, vous pouvez réduire la mémoire nécessaire avec les options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> et / ou en utilisant une valeur plus petite pour l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
À la ligne 1651
Rapporter un faux positif
Suggestions :
- « allô »
- « malloc »
- « allow »
- « al loc »
- « al-loc »
Message n°199,
Original : | <html><head/><body><p>Controls which stack trace(s) to keep for malloc'd and/or free'd blocks. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, a stack trace is recorded at allocation time, and is associated with the block. When the block is freed, a second stack trace is recorded, and this replaces the allocation stack trace. As a result, any "use after free" errors relating to this block can only show a stack trace for where the block was freed. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-and-free</span>, both allocation and the deallocation stack traces for the block are stored. Hence a "use after free" error will show both, which may make the error easier to diagnose. Compared to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc-then-free</span>, this setting slightly increases Valgrind's memory use as the block contains two references instead of one. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">alloc</span>, only the allocation stack trace is recorded (and reported). With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">free</span>, only the deallocation stack trace is recorded (and reported). These values somewhat decrease Valgrind's memory and cpu usage. They can be useful depending on the error types you are searching for and the level of detail you need to analyze them. For example, if you are only interested in memory leak errors, it is sufficient to record the allocation stack traces. </p><p>With <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">none</span>, no stack traces are recorded for malloc and free operations. If your program allocates a lot of blocks and/or allocates/frees from many different stack traces, this can significantly decrease cpu and/or memory required. Of course, few details will be reported for errors related to heap blocks. </p><p>Note that once a stack trace is recorded, Valgrind keeps the stack trace in memory even if it is not referenced by any block. Some programs (for example, recursive algorithms) can generate a huge number of stack traces. If Valgrind uses too much memory in such circumstances, you can reduce the memory required with the options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> and/or by using a smaller value for the option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle quelles traces de piles conserver pour les blocs alloués par « malloc » et libérés par « free ». </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, une trace de pile est enregistrée au moment de l'allocation et est associée avec le bloc. Quand le bloc est libéré, une seconde trace de pile est enregistrée et elle remplace la trace d'allocation dans la pile. Comme résultat, toute erreur "Utilisation après libération" concernant ce bloc ne peut afficher qu'une trace de pile que suite à la libération du bloc. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-and-free » </span>, les deux traces d'allocation et de désallocation pour le bloc sont enregistrées. Par conséquent, une erreur "Utilisation après libération" sera affichée pour les deux évènements, ce qui peut rendre l'erreur plus facile à identifier. En comparaison de l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc-then-free » </span>, ce paramétrage augmente légèrement l'utilisation mémoire de Valgrind puisque le bloc contient deux références au lieu d'une. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « alloc » </span>, seule la trace de la pile d'allocations est enregistrée (et affichée. Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « free » </span>, seule la trace de pile de désallocation est enregistrée (et affichée). Ces valeurs diminuent quelque peu la consommation de mémoire et de puissance processeur à Valgrind. Ces options peuvent vous être utiles selon les types d'erreurs que vous recherchez et le niveau de détails dont vous avez besoin pour les analyser. Par exemple, si vous n'êtes intéressé que par les erreurs de fuites de mémoire, il est suffisant d'enregistrer les traces de pile d'allocation. </p><p>Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « none » </span>, aucune trace de pile n'est enregistrée pour les appels à « malloc » et à « free ». Si votre programme alloue beaucoup de blocs et / ou alloue / libère à partir de différentes traces de piles, ceci peut réduire significativement la consommation de mémoire et de puissance processeur nécessaires. Bien sûr, peu de détails seront fournis pour les erreurs concernant les blocs de tas local. </p> <p>Veuillez noter qu'une fois que la trace de pile est enregistrée, Valgrind conserve la trace de la pile en mémoire, même si elle n'est référencée par aucun bloc. Certains programmes (par exemple, les algorithmes récursifs) peuvent produire un nombre énorme de traces de pile. Si Valgrind utilise trop de mémoire en de tels circonstances, vous pouvez réduire la mémoire nécessaire avec les options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--keep-stacktraces</span> et / ou en utilisant une valeur plus petite pour l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--num-callers</span>. </p></body></html> |
À la ligne 1651
Rapporter un faux positif
Suggestions :
- « dés allocation »
- « dés-allocation »
- « d'allocation »
- « d'allocations »
- « dislocation »
Message n°206,
Original : | <html><head/><body><p>When enabled, Memcheck checks that heap blocks are deallocated using a function that matches the allocating function. That is, it expects <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">free</span> to be used to deallocate blocks allocated by <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">malloc</span>, <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">delete</span> for blocks allocated by <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">new</span>, and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">delete[]</span> for blocks allocated by <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">new[]</span>. If a mismatch is detected, an error is reported. This is in general important because in some environments, freeing with a non-matching function can cause crashes.</p><p>There is however a scenario where such mismatches cannot be avoided. That is when the user provides implementations of <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">new</span>/<span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">new[]</span> that call <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">malloc</span> and of <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">delete</span>/<span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">delete[]</span> that call <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">free</span>, and these functions are asymmetrically inlined. For example, imagine that <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">delete[]</span> is inlined but <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">new[]</span> is not. The result is that Memcheck "sees" all <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">delete[]</span> calls as direct calls to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">free</span>, even when the program source contains no mismatched calls.</p><p>This causes a lot of confusing and irrelevant error reports. <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--show-mismatched-frees=no</span> disables these checks. It is not generally advisable to disable them, though, because you may miss real errors as a result.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Quand cette option est activée, Memcheck vérifie que les blocs du tas local sont libérés en utilisant une fonction fonctionnant de façon similaire à la fonction d'allocation. Cela veut dire qu'elle suppose être <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">libre</span> d'être utilisée pour libérer des blocs alloués par <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « malloc » </span>, <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « delete » </span> pour les blocs alloués par <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">new</span>, et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">delete[]</span> pour les blocs alloués par <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « new [] » </span>. Si une incohérence est détectée, une erreur est signalée. En général, cette incohérence est importante car, dans certains environnements, une libération avec cette fonction de non vérification peut conduire à des plantages.</p><p>Cependant, ceci est un scénario où de telles incohérences ne peuvent être évitées. Ce cas se produit quand l'utilisateur propose des implémentations de <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « new » </span>/<span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « new [] » </span> appelant <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « malloc » </span> et de <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « delete » </span> / <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « delete [] »</span> appelant <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « free »</span> et ces fonctions sont intégrées de façon asymétrique. Par exemple, imaginez que la fonction <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « delete[] » </span> est intégrée mais que la fonction <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « new[] » </span> ne le soit pas. Le résultat est que Memcheck "voit" tous les appels à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « delete [] » </span> comme des appels directs à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;"> « free »</span>, même quand la source du programme ne contient aucun appel incohérent.</p><p> Ceci cause beaucoup de confusion et des rapports d'erreurs non pertinents. L'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--show-mismatched-frees=no</span> désactive ces vérifications. Cependant, il n'est pas souhaitable de les désactiver car vous pourriez alors passer à côté de véritables erreurs.</p></body></html> |
À la ligne 1740
Rapporter un faux positif
Suggestions :
- « implémentation »
- « implémentassions »
- « implémentions »
- « d'implémentation »
- « l'implémentation »
Message n°208,
Original : | <html><head/><body><p>Controls how Memcheck handles 32-, 64-, 128- and 256-bit naturally aligned loads from addresses for which some bytes are addressable and others are not. When <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">yes</span>, such loads do not produce an address error. Instead, loaded bytes originating from illegal addresses are marked as uninitialised, and those corresponding to legal addresses are handled in the normal way.</p><p>When <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">no</span>, loads from partially invalid addresses are treated the same as loads from completely invalid addresses: an illegal-address error is issued, and the resulting bytes are marked as initialised.</p><p>Note that code that behaves in this way is in violation of the ISO C/C++ standards, and should be considered broken. If at all possible, such code should be fixed.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle comment Memcheck gère les chargements classiquement alignés sur des frontières en 32-, 64-, 128- et 256-bits à partir d'adresses pour lesquels certains octets sont adressables et d'autres non. Avec l'option <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">yes</span>, de tels chargements ne génèrent pas d'erreur d'adressage. A la place, les origines des octets chargés à partir d'adresses illégales sont marqués comme non initialisés. Ceux, correspondant à des adresses autorisés sont gérés selon la façon normale.</p><p>Quand l'option est <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">no</span>, les chargements à partir d'adresses non valables sont traités comme les chargements venant d'adresses totalement illégales : une erreur « Adresse non valable » est générée et les octets concernés sont marqués comme initialisés.</p><p> Veuillez noter que le code se comportant de cette façon est en violation des standards « ISO C/C++ » et devrait être considéré comme erroné. Si possible, un tel code devrait être corrigé. </p></body></html> |
À la ligne 1764
Rapporter un faux positif
Suggestions :
- « adressable »
- « dessables »
- « dessablés »
- « adressages »
- « adressâmes »
Message n°210,
Original : | <html><head/><body><p>Controls whether Memcheck tracks the origin of uninitialised values. By default, it does not, which means that although it can tell you that an uninitialised value is being used in a dangerous way, it cannot tell you where the uninitialised value came from. This often makes it difficult to track down the root problem.</p><p>When set to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">yes</span>, Memcheck keeps track of the origins of all uninitialised values. Then, when an uninitialised value error is reported, Memcheck will try to show the origin of the value. An origin can be one of the following four places: a heap block, a stack allocation, a client request, or miscellaneous other sources (eg, a call to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">brk</span>).</p><p>For uninitialised values originating from a heap block, Memcheck shows where the block was allocated. For uninitialised values originating from a stack allocation, Memcheck can tell you which function allocated the value, but no more than that -- typically it shows you the source location of the opening brace of the function. So you should carefully check that all of the function's local variables are initialised properly. </p><p>Performance overhead: origin tracking is expensive. It halves Memcheck's speed and increases memory use by a minimum of 100MB, and possibly more. Nevertheless it can drastically reduce the effort required to identify the root cause of uninitialised value errors, and so is often a programmer productivity win, despite running more slowly. </p><p>Accuracy: Memcheck tracks origins quite accurately. To avoid very large space and time overheads, some approximations are made. It is possible, although unlikely, that Memcheck will report an incorrect origin, or not be able to identify any origin. </p><p>Note that the combination <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--track-origins=yes</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--undef-value-errors=no</span> is nonsensical. Memcheck checks for and rejects this combination at startup.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle si Memcheck doit ou non pister l'origine des variables non initialisées. Par défaut, il ne le fait pas, ce qui signifie que même s'il peut vous indiquer qu'une variable non initialisée est utilisée d'une façon dangereuse, il ne peut vous dire d'où cette variable non initialisée provient. Ceci rend souvent difficile la recherche de la cause racine.</p> <p>Quand l'option est positionnée à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">yes</span>, Memcheck conserve la trace des provenance de toutes les variables non initialisées. Alors, quand une erreur de valeur non initialisée est signalée, Memcheck essayera d'afficher l'origine de la variable. L'origine peut être une des quatre emplacements suivants : un bloc du tas local, une allocation dans la pile, une requête client ou diverses autres sources (i.e. un appel à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">brk</span>).</p><p> Pour les origines des variables non initialisées concernant le bloc de tas local, Memcheck affiche où le bloc a été alloué. Pour les origines des variables non initialisées concernant une allocation dans la pile, Memcheck peut vous indiquer quelle fonction a alloué la valeur mais rien de plus que cela -- classiquement, il vous indique l'emplacement source de la parenthèse ouvrante de la fonction. Ainsi, vous pouvez vérifier avec soin, que toutes les variables locales sont correctement initialisées. </p><p>Impact sur les performances : la recherche de l'origine est coûteux. cela réduit de moitié l'exécution de Memcheck et accroît l'utilisation mémoire de 100 Mo voir plus. Cependant, il peut réduire drastiquement l'effort nécessaire pour identifier la cause racine pour les erreurs de variables non initialisées. Ainsi, cela reste un gain de productivité pour le développeur même si l'exécution est très ralentie. </p><p>Précision : Memcheck piste les origines de façon assez précise. Pour éviter la perte de temps et de beaucoup d'espace mémoire, certaines approximations sont faites. Il est possible, bien que peu probable, que Memcheck indiquera une origine incorrecte ou ne sera pas capable d'identifier l'origine. </p><p>Veuillez noter que les options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--track-origins=yes</span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--undef-value-errors=no</span> sont sans intérêt. Memcheck les vérifie et rejette cette association au démarrage.</p></body></html> |
Message n°210,
Original : | <html><head/><body><p>Controls whether Memcheck tracks the origin of uninitialised values. By default, it does not, which means that although it can tell you that an uninitialised value is being used in a dangerous way, it cannot tell you where the uninitialised value came from. This often makes it difficult to track down the root problem.</p><p>When set to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">yes</span>, Memcheck keeps track of the origins of all uninitialised values. Then, when an uninitialised value error is reported, Memcheck will try to show the origin of the value. An origin can be one of the following four places: a heap block, a stack allocation, a client request, or miscellaneous other sources (eg, a call to <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">brk</span>).</p><p>For uninitialised values originating from a heap block, Memcheck shows where the block was allocated. For uninitialised values originating from a stack allocation, Memcheck can tell you which function allocated the value, but no more than that -- typically it shows you the source location of the opening brace of the function. So you should carefully check that all of the function's local variables are initialised properly. </p><p>Performance overhead: origin tracking is expensive. It halves Memcheck's speed and increases memory use by a minimum of 100MB, and possibly more. Nevertheless it can drastically reduce the effort required to identify the root cause of uninitialised value errors, and so is often a programmer productivity win, despite running more slowly. </p><p>Accuracy: Memcheck tracks origins quite accurately. To avoid very large space and time overheads, some approximations are made. It is possible, although unlikely, that Memcheck will report an incorrect origin, or not be able to identify any origin. </p><p>Note that the combination <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--track-origins=yes</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--undef-value-errors=no</span> is nonsensical. Memcheck checks for and rejects this combination at startup.</p></body></html> |
---|---|
Traduction : | <html><head/><body><p>Contrôle si Memcheck doit ou non pister l'origine des variables non initialisées. Par défaut, il ne le fait pas, ce qui signifie que même s'il peut vous indiquer qu'une variable non initialisée est utilisée d'une façon dangereuse, il ne peut vous dire d'où cette variable non initialisée provient. Ceci rend souvent difficile la recherche de la cause racine.</p> <p>Quand l'option est positionnée à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">yes</span>, Memcheck conserve la trace des provenance de toutes les variables non initialisées. Alors, quand une erreur de valeur non initialisée est signalée, Memcheck essayera d'afficher l'origine de la variable. L'origine peut être une des quatre emplacements suivants : un bloc du tas local, une allocation dans la pile, une requête client ou diverses autres sources (i.e. un appel à <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">brk</span>).</p><p> Pour les origines des variables non initialisées concernant le bloc de tas local, Memcheck affiche où le bloc a été alloué. Pour les origines des variables non initialisées concernant une allocation dans la pile, Memcheck peut vous indiquer quelle fonction a alloué la valeur mais rien de plus que cela -- classiquement, il vous indique l'emplacement source de la parenthèse ouvrante de la fonction. Ainsi, vous pouvez vérifier avec soin, que toutes les variables locales sont correctement initialisées. </p><p>Impact sur les performances : la recherche de l'origine est coûteux. cela réduit de moitié l'exécution de Memcheck et accroît l'utilisation mémoire de 100 Mo voir plus. Cependant, il peut réduire drastiquement l'effort nécessaire pour identifier la cause racine pour les erreurs de variables non initialisées. Ainsi, cela reste un gain de productivité pour le développeur même si l'exécution est très ralentie. </p><p>Précision : Memcheck piste les origines de façon assez précise. Pour éviter la perte de temps et de beaucoup d'espace mémoire, certaines approximations sont faites. Il est possible, bien que peu probable, que Memcheck indiquera une origine incorrecte ou ne sera pas capable d'identifier l'origine. </p><p>Veuillez noter que les options <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--track-origins=yes</span> et <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--undef-value-errors=no</span> sont sans intérêt. Memcheck les vérifie et rejette cette association au démarrage.</p></body></html> |
À la ligne 1788
Rapporter un faux positif
Suggestions :
- « drastique ment »
- « drastique-ment »
- « dramatiquement »
- « pratiquement »
- « rustiquement »
Dernière vérification : Sun Apr 21 21:18:30 2024 (actualisée une fois par semaine).