2015-04-23 8 views
5

Poniższy kod nic nie robi, ale tajemnicą jest, dlaczego Dr Memory pomyślałaby, że istnieje unitialized read? Jakieś pomysły?Dr Pamięć i tajemniczy niezainicjowany odczyt

#include <memory> 

int main(int argc, const char* argv[]) 
{ 
    int aa[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; 

    std::unique_ptr<int[]> p {new int[10]}; 

    for (auto i = 0; i < 10; ++i) { 
     p[i] = aa[i]; 
    } 

    return 0; 
} // <-- Dr Memory says UNINITIALIZED READ here 

EDYCJA: Oto pełne szczegóły błędu.

Error #1: UNINITIALIZED READ: reading 0x0028ff20-0x0028ff24 4 byte(s) 
# 0 __mingw_glob        [src/main.cpp:14] 
# 1 _setargv         [src/main.cpp:14] 
# 2 __mingw_CRTStartup 
# 3 mainCRTStartup 
# 4 ntdll.dll!RtlInitializeExceptionChain +0x62  (0x772c8fe2 <ntdll.dll+0x38fe2>) 
# 5 ntdll.dll!RtlInitializeExceptionChain +0x35  (0x772c8fb5 <ntdll.dll+0x38fb5>) 
Note: @0:00:00.297 in thread 9780 
Note: instruction: cmp (%esi) $0x0040a11e 
+3

Czy ta "Pamięć o Dracie" naprawdę mówi tylko o lokalizacji? Nie ma nic o bloku, offsecie, stosie lub linii kodu w momencie próby odczytu itp ...? Jeśli nie, możesz sprawdzić swoją konkurencję ... –

+0

Zmodyfikowałem moje pytanie, aby dodać szczegóły, które dostarcza. –

+0

musisz podać prawidłowy deleter. Kod spróbuje "usunąć" dane, ale powinno "usunąć []". – stefan

Odpowiedz

1

Linia wskazany w funkcji main nie jest to linia, w którym wystąpił błąd. Błąd pojawił się w __mingw_glob, jak wskazuje śledzenie stosu, a to się zdarza przed jakikolwiek twój kod jest wywoływany. (Jest to funkcja, która rozwija znaki nazw plików przekazywane w wierszu poleceń, w systemie Linux zadanie to jest wykonywane przez powłokę, ale w systemie Windows jest to odpowiedzialność środowiska wykonawczego C).

Innymi słowy, występuje ono w mingw biblioteka. Prawdopodobnie jest to nieszkodliwy fałszywy alarm i powinieneś po prostu dodać wykluczenie.

Sugeruję, że prawdopodobnie Dr Memory błędnie zidentyfikował to jako niezainicjalizowane, ponieważ zostało zainicjowane przez system operacyjny przed uruchomieniem któregokolwiek z twoich kodów lub przez kod, który działał przed zainicjowaniem DrMemory, lub ponieważ zostało przekazane do wywołania systemowego który w rzeczywistości nie odczytuje pamięci, ale tylko ją zapisuje.

Dlaczego pokazuje nieprawidłową linię w swojej funkcji?

Debugery próbują domyślnie pokazać odpowiednie informacje. Ponieważ generalnie bardziej prawdopodobne jest to, że Twój kod jest błędny, a nie kod biblioteki, debugger pokaże najnowszą instancję twojego kodu na stosie wywołań. Na przykład, jeśli wystąpi błąd w specyficznych dla implementacji głębokościach wywołania do free, jest mało prawdopodobne, aby był to błędny kod biblioteki, więc zamiast tego Twój kod, który wywołuje free, zostanie zidentyfikowany jako prawdopodobny winowajca.

W twoim przypadku nie ma żadnego kodu na stosie wywołań, więc algorytm nie znajduje żadnego i pokazuje ci błędną lokalizację.