valgrind не распознает неправильную запись - PullRequest
Новая
       7

valgrind не распознает неправильную запись

0 голосов
/ 03 февраля 2019

Valgring не обнаруживает ошибки памяти.

Я использую valgrind 3.11, gcc 5.4.0 под Ubuntu и у меня неверный код в моей программе, как в примере.

Iпроанализировал эту программу, используя valgrind.Но valgrind не сообщает о каких-либо ошибках. 

  #include <string.h>
   int main(){
     int a[3];
     memcpy(a,"aaabbbcccdddeeefffggghhh", 24);
     return 0;
   }

Что не так с valgrind?

1 Ответ

0 голосов
/ 04 февраля 2019

valgrind не знает a , а не его размер, пока вы остаетесь в стеке, он не может обнаружить ошибку

Для сравнения,имея это: 

#include <string.h>
int main(){
  int * a = new int[3];
  memcpy(a,"aaabbbcccdddeeefffggghhh", 24);
  return 0;
}

valgrind может обнаружить ошибку, потому что он знает размер выделенного блока: 

pi@raspberrypi:/tmp $ valgrind ./a.out
==16164== Memcheck, a memory error detector
==16164== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16164== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16164== Command: ./a.out
==16164== 
==16164== Invalid write of size 8
==16164==    at 0x4865F44: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
==16164==  Address 0x4bc9f60 is 8 bytes inside a block of size 12 alloc'd
==16164==    at 0x48485F0: operator new[](unsigned int) (vg_replace_malloc.c:417)
==16164==    by 0x105A7: main (v.cc:3)
==16164== 
==16164== Invalid write of size 8
==16164==    at 0x4865F54: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
==16164==  Address 0x4bc9f68 is 4 bytes after a block of size 12 alloc'd
==16164==    at 0x48485F0: operator new[](unsigned int) (vg_replace_malloc.c:417)
==16164==    by 0x105A7: main (v.cc:3)
==16164== 
==16164== 
==16164== HEAP SUMMARY:
==16164==     in use at exit: 12 bytes in 1 blocks
==16164==   total heap usage: 2 allocs, 1 frees, 20,236 bytes allocated
==16164== 
==16164== LEAK SUMMARY:
==16164==    definitely lost: 12 bytes in 1 blocks
==16164==    indirectly lost: 0 bytes in 0 blocks
==16164==      possibly lost: 0 bytes in 0 blocks
==16164==    still reachable: 0 bytes in 0 blocks
==16164==         suppressed: 0 bytes in 0 blocks
==16164== Rerun with --leak-check=full to see details of leaked memory
==16164== 
==16164== For counts of detected and suppressed errors, rerun with: -v
==16164== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 3)
...