KDE en français
Erreurs dans « kdevvalgrind.po »
Corriger le fichier kdevvalgrind.poLe fichier kdevvalgrind.po comporte :
- aucune violation de règles de traduction.
- 16 fautes d'orthographe.
Fautes d'orthographe :
Message n°56,
| Original : | <html><head/><body><p>Enables or disables collection of branch instruction and misprediction counts. By default this is disabled as it slows Cachegrind down by approximately 25%. Note that you cannot specify <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--cache-sim=no</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--branch-sim=no</span> together, as that would leave Cachegrind with no information to collect.</p></body></html> |
|---|---|
| Traduction : | <html><head/><body><p>Active ou désactive le comptage des instructions de branchement et les compteurs d'erreurs de prédiction. Par défaut, celui-ci est désactivé, ce qui ralentit Cachegrind d'environ 25 %. Veuillez noter que vous ne pouvez pas spécifier <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--cache-sim=no</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">--branch-sim=no</span> ensemble, puisque vous ne pouvez pas laisser Cachegrind sans information sur quoi collecter.</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°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> |
Message n°119,
| Original : | <html><head/><body><p>Trace execution of the <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_BEFORE()</span>, <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_AFTER()</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_DONE()</span> client requests.</p></body></html> |
|---|---|
| Traduction : | <html><head/><body><p>Tracer l'exécution du client de requêtes <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_BEFORE()</span>, <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_AFTER()</span> and <span style=" font-family:'Monospace'; font-weight:600; font-style:italic;">ANNOTATE_HAPPENS_DONE()</span>.</p></body></html> |
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 |
À la ligne 1009
Rapporter un faux positif
Suggestions :
- « murex »
- « mutes »
- « mute »
- « tutex »
- « muter »
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°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> |
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élocalisation »
- « désalinisation »
- « désaliénation »
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élocalisation »
- « désalinisation »
- « désaliénation »
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> |
Dernière vérification : Tue Nov 5 08:01:36 2024 (actualisée une fois par semaine).
Retour