Valgrind
Ubuntu Online, Fedora Online, Windows 온라인 에뮬레이터 또는 MAC OS 온라인 에뮬레이터와 같은 여러 무료 온라인 워크스테이션 중 하나를 사용하여 OnWorks 무료 호스팅 공급자에서 실행할 수 있는 valgrind 명령입니다.
프로그램:
이름
valgrind - 프로그램 디버깅 및 프로파일링을 위한 도구 세트
개요
Valgrind [valgrind 옵션] [귀하의 프로그램] [귀하의 프로그램 옵션]
기술
발그린드 Linux 실행 파일의 디버깅 및 프로파일링을 위한 유연한 프로그램입니다. 그것은 구성
소프트웨어에서 합성 CPU를 제공하는 코어와 일련의 디버깅 및
프로파일링 도구. 아키텍처는 모듈식이므로 새 도구를 쉽게 만들고
기존 구조를 방해하지 않고
아래에 설명된 옵션 중 일부는 모든 Valgrind 도구에서 작동하고 일부는
몇 개 또는 하나. MEMCHECK OPTIONS 섹션과 그 아래 섹션에서는 도구별 설명을 설명합니다.
옵션을 제공합니다.
이 매뉴얼 페이지는 기본적인 사용법과 옵션만을 다루고 있습니다. 보다 종합적인 정보는
시스템의 HTML 문서를 참조하십시오.
$INSTALL/share/doc/valgrind/html/index.html 또는 온라인:
http://www.valgrind.org/docs/manual/index.html.
수단 SELECTION 옵션
가장 중요한 단일 옵션.
--도구= [기본: 멤체크]
라는 Valgrind 도구를 실행합니다. 도구 이름예: memcheck, cachegrind, callgrind, helgrind,
drd, 대산괴, 라키, 없음, exp-sgcheck, exp-bbv, exp-dhat 등
BASIC 옵션
이러한 옵션은 모든 도구에서 작동합니다.
-h --도움
코어 및 선택한 도구 모두에 대한 모든 옵션에 대한 도움말을 표시합니다. 옵션인 경우
반복되는 것은 주는 것과 같습니다. --help-디버그.
--help-디버그
과 동일 --도움, 그러나 일반적으로 사용되는 디버깅 옵션도 나열합니다.
Valgrind의 개발자.
--번역
Valgrind 코어의 버전 번호를 표시합니다. 도구는 자체 버전을 가질 수 있습니다.
숫자. 코어가 실행될 때만 도구가 실행되도록 하는 체계가 있습니다.
버전은 그들이 작업하는 것으로 알려진 버전입니다. 발생할 가능성을 최소화하기 위해 수행되었습니다.
도구 대 코어 버전 비호환성으로 인해 발생하는 이상한 문제.
-q, --조용한
자동으로 실행하고 오류 메시지만 인쇄합니다. 회귀를 실행하는 경우 유용합니다.
테스트하거나 다른 자동화된 테스트 기계를 가지고 있습니다.
-v, --말 수가 많은
더 자세히 설명하십시오. 다음과 같은 프로그램의 다양한 측면에 대한 추가 정보를 제공합니다.
로드된 공유 개체, 사용된 억제, 계측 진행률
실행 엔진, 비정상적인 행동에 대한 경고. 옵션 반복
상세 수준을 높입니다.
--추적-어린이= [기본: 아니요]
활성화되면 Valgrind는 다음을 통해 시작된 하위 프로세스를 추적합니다. 임원 체계
부르다. 이는 다중 프로세스 프로그램에 필요합니다.
Valgrind는 포크 (그렇지 않으면 힘들겠지만,
이후 포크 프로세스의 동일한 복사본을 만듭니다), 그래서 이 옵션은 틀림없이 나쁘다
명명 된. 그러나 대부분의 자녀는 포크 전화 즉시 전화 임원 어쨌든.
--trace-children-skip=patt1,patt2,...
이 옵션은 다음과 같은 경우에만 효과가 있습니다. --추적-어린이=예 지정됩니다. 그것은 허용
일부 어린이는 건너뛸 수 있습니다. 이 옵션은 다음에 대해 쉼표로 구분된 패턴 목록을 사용합니다.
Valgrind가 추적해서는 안 되는 하위 실행 파일의 이름입니다. 패턴은
메타 문자를 포함합니까? 및 *는 일반적인 의미를 갖습니다.
이는 프로세스 트리에서 관심 없는 가지를 잘라내는 데 유용할 수 있습니다.
Valgrind에서 실행하십시오. 하지만 사용시 주의가 필요합니다. Valgrind가 추적을 건너뛸 때
실행 파일로 전환하면 해당 실행 파일 추적을 건너뛸 뿐만 아니라
해당 실행 파일의 하위 프로세스를 추적합니다. 즉, 플래그가 표시되지 않습니다.
지정된 실행 파일에서 추적을 중지하기만 하면 됩니다.
지정된 실행 파일을 기반으로 하는 전체 프로세스 하위 트리.
--trace-children-skip-by-arg=patt1,patt2,...
이것은 --추적-어린이 건너뛰기, 한 가지 차이점이 있습니다.
자식 프로세스를 추적할지 여부는 자식에 대한 인수를 검사하여 결정됩니다.
실행 파일의 이름이 아니라 프로세스입니다.
--child-silent-after-fork= [기본: 아니요]
활성화되면 Valgrind는 자식에 대한 디버깅 또는 로깅 출력을 표시하지 않습니다.
에서 발생하는 프로세스 포크 부르다. 이것은 출력을 덜 혼란스럽게 만들 수 있습니다.
더 오해의 소지가 있음) 자식을 생성하는 프로세스를 처리할 때. 그것은 특히
와 함께 유용 --추적-어린이=. 이 옵션을 사용하는 것도 강력합니다.
XML 출력을 요청하는 경우 권장(--xml=예), 그렇지 않으면 XML이
자녀와 부모가 뒤섞일 수 있으며 이는 일반적으로 쓸모 없게 만듭니다.
--vgdb= [기본: 예]
Valgrind는 "gdbserver" 기능을 제공합니다. --vgdb=예 or --vgdb=가득 is
지정된. 이를 통해 외부 GNU GDB 디버거가 프로그램을 제어하고 디버깅할 수 있습니다.
Valgrind에서 실행할 때. --vgdb=가득 상당한 성능 오버헤드가 발생하지만
더 정확한 중단점과 감시점을 제공합니다. 다음을 사용하여 프로그램 디버깅을 참조하십시오.
자세한 설명은 Valgrind의 gdbserver 및 GDB를 참조하십시오.
포함된 gdbserver가 활성화되었지만 현재 사용 중인 gdb가 없는 경우 vgdb는
명령줄 유틸리티는 셸에서 Valgrind로 "모니터 명령"을 보낼 수 있습니다. 그만큼
Valgrind 코어는 일련의 Valgrind 모니터 명령을 제공합니다. 도구는 선택적으로
도구별 모니터 명령을 제공합니다. 이 명령은 도구별
장.
--vgdb-오류= [기본: 999999999]
Valgrind gdbserver가 다음과 같이 활성화된 경우 이 옵션을 사용합니다. --vgdb=예 or --vgdb=가득.
오류를 보고하는 도구는 고정되기 전에 "숫자" 오류가 보고될 때까지 기다립니다.
프로그램을 실행하고 GDB와 연결하기를 기다립니다. XNUMX의 값이 나온다
프로그램이 실행되기 전에 gdbserver가 시작됩니다. 이것은
일반적으로 실행 전에 GDB 중단점을 삽입하는 데 사용되며 도구에서도 작동합니다.
Massif와 같이 오류를 보고하지 않는
--vgdb-정지-at= [기본: 없음]
Valgrind gdbserver가 다음과 같이 활성화된 경우 이 옵션을 사용합니다. --vgdb=예 or --vgdb=가득.
이후 각 오류에 대해 Valgrind gdbserver가 호출됩니다. --vgdb-오류 되었습니다
보고했다. Valgrind gdbserver를 추가로 호출하도록 요청할 수 있습니다.
다음 방법 중 하나로 지정된 이벤트:
· 하나 이상의 쉼표로 구분된 목록 시작 출구 발그린다벡시트.
가치 시작 출구 발그린다벡시트 gdbserver를 호출하도록 각각 표시
프로그램이 실행되기 전, 프로그램의 마지막 명령 후, on
Valgrind 비정상적인 종료(예: 내부 오류, 메모리 부족 등).
참고 : 시작 그리고 --vgdb-오류=0 둘 다 Valgrind gdbserver가 호출되도록 합니다.
프로그램이 실행되기 전에. 그만큼 --vgdb-오류=0 또한 귀하의
모든 후속 오류에서 중지하도록 프로그램합니다.
· 모든 전체 세트를 지정합니다. 그것은
--vgdb-stop-at=시작, 종료, valgrindabexit.
· 없음 빈 세트의 경우.
--트랙-fds= [기본: 아니요]
활성화되면 Valgrind는 종료 시 또는 종료 시 열린 파일 설명자 목록을 인쇄합니다.
요청, gdbserver 모니터 명령을 통해 v.info open_fds. 각 파일과 함께
디스크립터는 파일이 열린 위치와 세부 정보에 대한 스택 역추적을 인쇄합니다.
파일 이름 또는 소켓 세부 정보와 같은 파일 설명자와 관련됩니다.
--타임스탬프= [기본: 아니요]
활성화되면 각 메시지 앞에 경과된 wallclock 표시가 표시됩니다.
일, 시, 분, 초 및 밀리초로 표시되는 시작 이후 시간입니다.
--로그-fd= [기본: 2, 표준 오류]
Valgrind가 모든 메시지를 지정된 파일로 보내도록 지정합니다.
기술자. 기본값 2는 표준 오류 채널(stderr)입니다. 이 문제가 발생할 수 있습니다.
Valgrind의 출력은 클라이언트 자체의 stderr 사용을 방해합니다.
클라이언트가 stderr로 보내는 모든 출력과 인터리브됩니다.
--로그 파일=
Valgrind가 모든 메시지를 지정된 파일로 보내도록 지정합니다. 만약
파일 이름이 비어 있으면 중단됩니다. 세 가지 특수 형식 지정자가 있습니다.
파일 이름에 사용할 수 있습니다.
%p 현재 프로세스 ID로 대체됩니다. 이것은 프로그램에 매우 유용합니다.
여러 프로세스를 호출합니다. 경고: 사용하는 경우 --추적-어린이=예 그리고 당신의 프로그램
여러 프로세스를 호출하거나 나중에 exec를 호출하지 않고 프로그램 포크를 호출하고
이 지정자를 사용하지 않습니다(또는 %q 아래 지정자), 모든 것의 Valgrind 출력
이러한 프로세스는 하나의 파일로 이동하고 뒤죽박죽이거나 불완전할 수 있습니다.
%q{FOO} 환경 변수의 내용으로 대체됩니다. FOO. 경우 {푸}
부품의 형식이 잘못되면 중단됩니다. 이 지정자는 거의 필요하지 않지만 매우
특정 상황에서 유용합니다(예: MPI 프로그램을 실행할 때). 아이디어는 당신이
작업의 각 프로세스에 대해 다르게 설정될 변수를 지정합니다.
예 BPROC_RANK 또는 MPI 설정에 적용 가능한 모든 것. 명명된 경우
환경 변수가 설정되지 않으면 중단됩니다. 일부 쉘에서는 {
그리고 } 문자는 백슬래시로 이스케이프해야 할 수 있습니다.
%% 다음으로 대체됩니다. %.
경우 % 뒤에 다른 문자가 오면 중단됩니다.
파일 이름이 상대 파일 이름을 지정하면 프로그램의 이니셜에 넣습니다.
작업 디렉토리 : 프로그램이 시작되었을 때의 현재 디렉토리입니다.
포크 후 또는 exec 후 실행. 절대 파일 이름을 지정하는 경우(예:
'/'로 시작) 거기에 넣습니다.
--로그 소켓=
Valgrind가 지정된 포트로 모든 메시지를 보내도록 지정합니다.
지정된 IP 주소. 포트는 생략할 수 있으며 이 경우 포트 1500이 사용됩니다. 만약
지정된 소켓에 연결할 수 없습니다. Valgrind는 쓰기로 돌아갑니다.
표준 오류(stderr)로 출력합니다. 이 옵션은
valgrind-listener 프로그램과 함께. 자세한 내용은 다음을 참조하십시오.
설명서의 해설.
오류 관련 옵션
이러한 옵션은 오류를 보고할 수 있는 모든 도구(예: Memcheck)에서 사용되지만
캐시그라인드.
--xml= [기본: 아니요]
활성화되면 출력의 중요한 부분(예: 도구 오류 메시지)이
일반 텍스트가 아닌 XML 형식입니다. 또한 XML 출력은
일반 텍스트 출력과 다른 출력 채널. 따라서, 당신은 또한 하나를 사용해야합니다
of --xml-fd, --xml 파일 or --xml-소켓 XML을 보낼 위치를 지정합니다.
덜 중요한 메시지는 여전히 일반 텍스트로 인쇄되지만 XML
출력 및 일반 텍스트 출력은 서로 다른 출력 채널로 전송됩니다(
일반 텍스트 출력은 여전히 다음에 의해 제어됩니다. --log-fd, --로그 파일 그리고 --로그 소켓)
이것은 문제를 일으키지 않아야 합니다.
이 옵션은 Valgrind의 출력을
GUI 프런트 엔드와 같은 입력. 현재 이 옵션은 Memcheck, Helgrind,
DRD 및 SG체크. 출력 형식은 파일에 지정됩니다.
Valgrind 4용 소스 트리의 docs/internals/xml-output-protocol3.5.0.txt 또는
나중에.
XML 출력을 요청할 때 통과할 GUI에 권장되는 옵션은 다음과 같습니다. --xml=예
XML 출력을 활성화하려면 --xml 파일 XML 출력을 (아마도 GUI 선택)
파일 --로그 파일 일반 텍스트 출력을 두 번째 GUI 선택 파일로 보내려면
--child-silent-after-fork=예및 -q 일반 텍스트 출력을 위험으로 제한
Valgrind 자체에서 생성한 오류 메시지입니다. 예를 들어, 지정된 읽기 실패
억제 파일은 중요한 오류 메시지로 간주됩니다. 이와 같이 성공적인
텍스트 출력 파일을 실행하면 비어 있습니다. 그러나 비어 있지 않으면 다음을 포함합니다.
GUI 사용자가 알아야 할 중요한 정보.
--xml-fd= [기본: - 1, 장애가있는]
Valgrind가 XML 출력을 지정된 파일 설명자로 보내도록 지정합니다.
와 함께 사용해야 합니다. --xml=예.
--xml 파일=
Valgrind가 XML 출력을 지정된 파일로 보내도록 지정합니다. 반드시
와 함께 사용 --xml=예. 어떤 %p or %q 파일 이름에 나타나는 시퀀스
에 대한 것과 정확히 동일한 방식으로 확장됩니다. --로그 파일. 설명을 참조하십시오
of --로그 파일 를 참조하세요
--xml-소켓=
Valgrind가 XML 출력을 지정된 시간에 지정된 포트로 보내도록 지정합니다.
IP 주소. 와 함께 사용해야 합니다. --xml=예. 논거의 형식은
에서 사용하는 것과 동일 --로그 소켓. 설명 참조 --로그 소켓 더 나아가서
세부.
--xml-사용자-설명=
XML 출력 시작 부분에 추가 사용자 설명 문자열을 포함합니다. 경우에만 작동
--xml=예 지정됨; 그렇지 않으면 무시됩니다.
--demangle= [기본: 예]
C++ 이름의 자동 디맹글링(디코딩)을 활성화/비활성화합니다. 기본적으로 활성화됩니다. 언제
활성화되면 Valgrind는 인코딩된 C++ 이름을 다시 무언가로 변환하려고 시도합니다.
원작에 가까워진다. 디맹글러는 g++ 버전 2.X에 의해 맹글링된 기호를 처리합니다.
3.X 및 4.X.
디맹글링에 대한 중요한 사실은 억제에 언급된 함수 이름입니다.
파일은 맹글링된 형식이어야 합니다. Valgrind는 다음과 같은 경우 함수 이름을 demangle하지 않습니다.
적용 가능한 억제를 검색합니다. 그렇지 않으면 억제가 발생하기 때문입니다.
파일 내용은 Valgrind의 디맹글링 기계 상태에 따라 달라지며 속도도 느립니다.
다운 억제 매칭.
--번호 호출자= [기본: 12]
프로그램을 식별하는 스택 추적에 표시되는 최대 항목 수를 지정합니다.
위치. 오류는 상위 XNUMX개 기능 위치만 사용하여 일반화됩니다.
(현재 함수의 위치 및 직접 호출자 XNUMX명의 위치). 그래서 이거
보고된 총 오류 수에는 영향을 미치지 않습니다.
최대값은 500입니다. 설정이 높을수록 Valgrind가
조금 더 느리고 더 많은 메모리를 사용하지만 작업할 때 유용할 수 있습니다.
깊게 중첩된 호출 체인이 있는 프로그램.
--unw-stack-scan-thresh= [기본: 0] , --unw-stack-scan-frames= [기본:
5]
스택 스캔 지원은 ARM 대상에서만 사용할 수 있습니다.
이러한 플래그는 스택 스캔을 통한 스택 해제를 활성화하고 제어합니다. 때 정상적인
스택 풀기 메커니즘 -- 드워프 CFI 레코드 사용 및 다음 프레임 포인터
-- 실패, 스택 스캔이 스택 추적을 복구할 수 있습니다.
스택 스캐닝은 부정확하고 휴리스틱한 메커니즘으로
잘못된 결과이거나 전혀 없습니다. 비상시에만 사용해야 하며 평상시에는
풀기는 실패하지만 그럼에도 불구하고 스택 추적을 갖는 것이 중요합니다.
스택 스캐닝은 간단한 기술입니다. 언와인더는 스택에서 단어를 읽고
반환 주소인지 확인하여 반환 주소가 될 수 있는 항목을 추측하려고 시도합니다.
ARM 또는 Thumb 호출 명령어 바로 뒤를 가리킵니다. 그렇다면 단어가 추가됩니다.
백트레이스.
주요 위험은 함수 호출이 리턴 주소를 남기고 리턴할 때 발생합니다.
노출되고 새 함수가 호출되지만 새 함수는 이전 함수를 덮어쓰지 않습니다.
주소. 그 결과 역추적에 함수에 대한 항목이 포함될 수 있습니다.
이미 반환되어 매우 혼란스럽습니다.
이 구현의 두 번째 제한 사항은 페이지(4KB,
일반적으로) 시작 스택 포인터를 포함합니다. 스택 프레임이 크면 이
추적에 몇 개만(또는 전혀) 표시되지 않을 수 있습니다. 또한, 당신이
운이 좋지 않고 포함하는 페이지의 끝 근처에 초기 스택 포인터가 있습니다.
스캔은 모든 흥미로운 프레임을 놓칠 수 있습니다.
기본적으로 스택 스캔은 비활성화되어 있습니다. 일반적인 사용 사례는
그렇지 않으면 스택 추적이 매우 짧습니다. 따라서 활성화하려면 다음을 사용하십시오.
--unw-stack-scan-thresh=숫자. 이는 Valgrind가 스택 스캐닝을 사용하여 다음을 수행하도록 요청합니다.
숫자보다 적은 수의 프레임을 포함하는 스택 추적을 "확장"합니다.
스택 스캐닝이 발생하면 최대 프레임 수만 생성됩니다.
--unw-stack-scan-frames에 의해 지정됩니다. 일반적으로 스택 스캐닝은 많은
이 값은 기본적으로 낮은 값(5)으로 설정됩니다. 어떠한 경우에도
--num-callers로 지정된 값보다 큰 스택 추적이 생성됩니다.
--오류 제한= [기본: 예]
활성화되면 Valgrind는 총 10,000,000개 또는 1,000개 이후 오류 보고를 중지합니다.
다른, 본 적이 있다. 이것은 오류 추적 기계를 중지하기 위한 것입니다.
오류가 많은 프로그램에서 엄청난 성능 오버헤드가 됩니다.
--오류 종료 코드= [기본: 0]
Valgrind가 다음에서 오류를 보고한 경우 반환할 대체 종료 코드를 지정합니다.
달리다. 기본값(XNUMX)으로 설정하면 Valgrind의 반환 값은 항상
시뮬레이션 중인 프로세스의 반환 값입니다. XNUMX이 아닌 값으로 설정하면
Valgrind가 오류를 감지하면 값이 대신 반환됩니다. 이것은 사용에 유용합니다
테스트를 쉽게 감지할 수 있으므로 자동 테스트 스위트의 일부인 Valgrind
반환 코드를 검사하여 Valgrind가 오류를 보고한 사례.
--오류 마커= , [기본: 없음]
오류가 일반 텍스트로 출력되는 경우(즉, XML이 사용되지 않음), --오류 마커 지시하다
다음을 포함하는 라인 출력 시작하다 (end) 각 오류 전(후) 문자열입니다.
이러한 마커 라인은 오류 검색 및/또는 오류 추출을 용이하게 합니다.
프로그램 출력과 혼합된 valgrind 오류가 포함된 출력 파일.
빈 마커가 허용됩니다. 따라서 시작(또는 끝) 마커만 사용하는 것은
수.
--signill-진단= [기본: 예]
잘못된 명령 진단 인쇄를 활성화/비활성화합니다. 기본적으로 활성화되어 있지만
기본적으로 비활성화됨 --조용한 주어진다. 기본값은 항상 명시적으로
이 옵션을 제공하여 재정의합니다.
활성화되면 언제든지 몇 가지 진단과 함께 경고 메시지가 인쇄됩니다.
Valgrind가 디코딩하거나 번역할 수 없는 명령이 발생하기 전에
프로그램에 SIGILL 신호가 주어집니다. 종종 불법적인 명령은 시스템의 버그를 나타냅니다.
Valgrind의 특정 명령에 대한 프로그램 또는 누락된 지원. 하지만 일부
프로그램은 누락되었을 수 있는 명령을 의도적으로 실행하려고 시도하고 트랩합니다.
프로세서 기능을 감지하는 SIGILL 신호. 이 플래그를 사용하면 다음을 수행할 수 있습니다.
그렇지 않으면 이러한 경우에 얻을 수 있는 진단 출력을 피하십시오.
--show-below-main= [기본: 아니요]
기본적으로 오류에 대한 스택 추적은 아래에 나타나는 함수를 표시하지 않습니다. 본관
대부분의 경우 흥미롭지 않은 C 라이브러리 항목 및/또는 gobbledygook이기 때문입니다.
또는 본관 스택 추적에 없으면 스택 추적이 표시되지 않습니다.
아래의 모든 기능 본관-glibc와 같은 기능 __libc_start_main.
또한, 경우 본관-유사 함수가 추적에 존재하면 다음과 같이 정규화됩니다.
(아래에 기본), 출력을 보다 결정적으로 만들기 위해.
이 옵션이 활성화되면 모든 스택 추적 항목이 표시되고 본관-처럼
기능은 정규화되지 않습니다.
--전체 경로 이후= [기본: 하지 표시 경로]
기본적으로 Valgrind는 스택 추적에 파일 이름만 표시하지만 전체 경로는 표시하지 않습니다.
소스 파일. 소스가 있는 대규모 프로젝트에서 Valgrind를 사용할 때
여러 개의 다른 디렉토리가 있으면 불편할 수 있습니다. --fullpath-이후 를 제공합니다
이 문제에 대한 유연한 솔루션. 이 옵션이 있으면 각 경로
다음과 같은 중요한 주의 사항과 함께 소스 파일이 표시됩니다. 현 발견된다
경로, 다음을 포함하는 경로 현 생략된 경우 경로가 표시됩니다.
수정되지 않은. 참고 현 경로의 접두사일 필요는 없습니다.
예를 들어 /home/janedoe/blah/src/foo/bar/xyzzy.c라는 파일을 생각해 보십시오. 지정
--fullpath-after=/home/janedoe/blah/src/ Valgrind가 이름을 다음과 같이 표시하게 합니다.
foo/bar/xyzzy.c.
문자열이 접두사가 될 필요가 없기 때문에 --fullpath-after=src/ 생산할 것이다
동일한 출력. 이것은 경로에 임의의 시스템 생성이 포함된 경우에 유용합니다.
문자. 예를 들어 /my/build/dir/C32A1B47/blah/src/foo/xyzzy 경로는 다음과 같을 수 있습니다.
다음을 사용하여 foo/xyzzy로 가지치기 --fullpath-after=/blah/src/.
단순히 전체 경로를 보려면 빈 문자열을 지정하십시오.
--전체 경로 이후=. 이것은 특별한 경우가 아니라 단지
위의 규칙.
마지막으로 --fullpath-이후 여러 번. 그것의 출현은 원인
Valgrind는 전체 경로를 생성하고 위의 필터링 규칙을 적용하도록 전환합니다. 각
생성된 경로는 모든 경로와 비교됩니다. --fullpath-이후-지정된 문자열,
주문 지정. 일치하는 첫 번째 문자열로 인해 경로가 다음과 같이 잘립니다.
전술 한 바와. 일치하는 항목이 없으면 전체 경로가 표시됩니다. 이것은 절단을 용이하게합니다
관련되지 않은 여러 디렉토리에서 소스를 가져올 때 접두사.
--extra-debuginfo-path= [기본: 정의되지 않은 그리고 미사용]
기본적으로 Valgrind는 다음과 같은 디버그 개체에 대해 잘 알려진 여러 경로에서 검색합니다.
/usr/lib/디버그/.
그러나 디버그 개체를
모바일 장치에서 Valgrind를 실행할 때 외부 저장소와 같은 임의의 위치
제한된 로컬 스토리지. 또 다른 예는 당신이 가지고 있지 않은 상황일 수 있습니다.
실행 중인 시스템에 디버그 개체 패키지를 설치할 수 있는 권한
Valgrind.
이러한 시나리오에서는 다음을 위한 추가 최종 위치로 절대 경로를 제공할 수 있습니다.
Valgrind는 다음을 지정하여 디버그 개체를 검색합니다.
--extra-debuginfo-path=/path/to/debug/객체. 주어진 경로는
검색된 개체의 절대 경로 이름입니다. 예를 들어 Valgrind가 다음을 찾고 있는 경우
/w/x/y/zz.so에 대한 debuginfo 및 --추가-디버그 정보-경로=/a/b/c 지정됩니다.
/a/b/c/w/x/y/zz.so에서 디버그 개체를 찾습니다.
이 플래그는 한 번만 지정해야 합니다. 여러 번 지정하는 경우에만
마지막 인스턴스가 영광입니다.
--debuginfo-server=ipaddr:포트 [기본: 정의되지 않은 그리고 미사용]
이것은 버전 3.9.0에 도입된 새로운 실험적 기능입니다.
일부 시나리오에서는
다른 기계. 이 플래그를 사용하면 Valgrind는 다음에서 실행 중인 debuginfo 서버를 쿼리합니다.
로컬에서 debuginfo 개체를 찾을 수 없는 경우 포트 포트에서 ipaddr 및 수신 대기
파일 시스템.
debuginfo 서버는 포트 포트에서 TCP 연결을 수락해야 합니다. debuginfo 서버는
소스 파일 auxprogs/valgrind-di-server.c에 포함되어 있습니다. 다음에서만 게재됩니다.
시작되는 디렉토리. 포트는 다음과 같은 경우 클라이언트와 서버 모두에서 기본적으로 1500입니다.
명시되지 않은.
Valgrind가 debuginfo 서버를 사용하여 /w/x/y/zz.so에 대한 debuginfo를 찾는 경우
경로 이름 구성 요소를 제거하고 서버에서 zz.so만 요청합니다. 그 안으로
turn은 현재 작업 디렉토리에서만 일치하는 debuginfo 개체를 찾습니다.
debuginfo 데이터는 Valgrind에서 요청한 대로 작은 조각(8KB)으로 전송됩니다.
각 블록은 전송 시간을 줄이기 위해 LZO를 사용하여 압축됩니다. 구현에는
단일 단계 802.11g(WiFi) 네트워크 링크에서 최고의 성능을 발휘하도록 조정되었습니다.
GNU debuglink CRC를 사용하여 일치하는 기본 개체와 디버그 개체를 확인합니다.
scheme, debuginfo 서버를 사용하는 경우에도 수행됩니다. 이러한 검사를 비활성화하려면
--allow-mismatched-debuginfo=yes도 지정해야 합니다.
기본적으로 Valgrind 빌드 시스템은 대상에 대해 valgrind-di-server를 빌드합니다.
거의 확실하게 원하는 것이 아닌 플랫폼입니다. 지금까지 우리는 할 수 없었습니다
빌드 플랫폼용으로 빌드하기 위해 automake/autoconf를 얻는 방법을 알아보십시오. 네가 원한다면
그것을 사용하려면 맨 위에 표시된 명령을 사용하여 수동으로 다시 컴파일해야 합니다.
auxprogs/valgrind-di-server.c.
--allow-mismatched-debuginfo=no|예 [아니]
별도의 debuginfo 개체에서 debuginfo를 읽을 때 Valgrind는 기본적으로 다음을 확인합니다.
GNU debuglink 메커니즘을 사용하여 기본 및 debuginfo 개체가 일치하는지 확인합니다. 이것
오래된 debuginfo 개체에서 debuginfo를 읽지 않도록 보장합니다.
또한 불일치로 인해 Valgrind가 충돌하지 않도록 합니다.
이 검사는 --allow-mismatched-debuginfo=yes를 사용하여 무시할 수 있습니다. 이것은
debuginfo 및 기본 개체가 적절한 방식으로 분할되지 않은 경우에 유용합니다. BE
그러나 이것을 사용할 때 주의하십시오: 모든 일관성 검사를 비활성화하고 Valgrind
기본 개체와 debuginfo 개체가 일치하지 않으면 충돌이 발생하는 것으로 관찰되었습니다.
--억제= [기본: $PREFIX/lib/valgrind/default.supp]
억제할 오류 설명을 읽을 추가 파일을 지정합니다. 당신은 할 수있다
최대 100개의 추가 억제 파일을 사용합니다.
--gen 억제= [기본: 아니요]
설정시 예, Valgrind는 모든 오류가 표시된 후 일시 중지하고 다음 줄을 인쇄합니다.
---- 인쇄 억제 ? --- [반환/N/n/Y/y/C/c] ----
누르면 레트및 N 레트 or n 레트, Valgrind가 a를 인쇄하지 않고 실행을 계속하게 합니다.
이 오류에 대한 억제.
누르면 Y 레트 or y 레트 Valgrind가 이 오류에 대한 억제를 작성하도록 합니다. 당신은 할 수 있습니다
그런 다음 삭제에 대해 듣고 싶지 않다면 잘라내어 억제 파일에 붙여넣으십시오.
앞으로 오류.
설정시 모든, Valgrind는 보고된 모든 오류에 대해
사용자에게 쿼리합니다.
이 옵션은 C++ 프로그램에서 특히 유용합니다.
필요에 따라 맹글링된 이름으로 억제합니다.
인쇄된 억제는 가능한 한 구체적입니다. 당신은 일반적으로 원할 수 있습니다
함수 이름에 와일드카드를 추가하고 프레임 수준
와일드 카드. 와일드카드 기능은 강력하면서도 유연하며 약간의
신중하게 편집하면 다음을 사용하여 관련 오류 전체를 억제할 수 있습니다.
단지 몇 가지 억제.
때로는 두 개의 다른 오류가 동일한 억제에 의해 억제되는 경우가 있습니다.
Valgrind는 억제를 두 번 이상 출력하지만 하나만 있으면 됩니다.
억제 파일에 복사합니다(하나 이상 있어도 문제가 발생하지 않음). 또한,
억제 이름은 다음과 같이 지정됩니다. ; 이름은 하지 않는다
정말 중요합니다. -v 사용된 억제를 모두 출력하는 옵션
기록.
--입력-fd= [기본: 0, 표준입력]
사용시 --gen-suppressions=예, Valgrind는 키보드 입력을 읽기 위해 중지합니다.
각 오류가 발생할 때 귀하로부터. 기본적으로 표준 입력(stdin)에서 읽습니다.
이는 stdin을 닫는 프로그램에 문제가 됩니다. 이 옵션을 사용하면 다음을 지정할 수 있습니다.
입력을 읽을 대체 파일 설명자.
--dsymutil=아니요|예 [예]
이 옵션은 Mac OS X에서 Valgrind를 실행할 때만 관련이 있습니다.
Mac OS X은 지연된 디버그 정보(debuginfo) 연결 체계를 사용합니다. 반대할 때
debuginfo를 포함하는 파일은 .dylib 또는 실행 파일에 링크되며, debuginfo는
최종 파일에 복사되지 않습니다. 대신 다음을 통해 debuginfo를 수동으로 연결해야 합니다.
실행 파일 또는 .dylib에서 시스템 제공 유틸리티인 dsymutil 실행. 그만큼
결과적으로 결합된 debuginfo는 실행 파일과 함께 디렉토리에 배치됩니다.
.dylib이지만 확장자는 .dSYM입니다.
와 --dsymutil=아니오, Valgrind는 .dSYM 디렉토리가
누락되었거나 존재하지만 연결된 실행 파일과 일치하지 않는 것 같습니다.
.dylib, 아마도 오래되었기 때문일 것입니다. 이 경우 Valgrind는 다음을 인쇄합니다.
경고 메시지가 표시되지만 더 이상 조치를 취하지 마십시오.
와 --dsymutil=예, Valgrind는 이러한 경우 dsymutil을 다음과 같이 자동으로 실행합니다.
debuginfo를 최신 상태로 유지하는 데 필요합니다. 모든 실용적인 목적을 위해 항상
사용 --dsymutil=예그러면 dsymutil을 수동으로 또는 일부로 실행할 필요가 없습니다.
Valgrind가 필요에 따라 실행하기 때문에 애플리케이션 빌드 시스템의
Valgrind는 실행 파일이나 라이브러리에서 dsymutil을 실행하려고 시도하지 않습니다. / usr /,
/ 빈 /, / sbin /, /고르다/, /sw/, /System/, /Library/ 또는 /Applications/
그런 상황에서는 항상 실패합니다. 이러한 디버그 정보 때문에 둘 다 실패합니다.
사전 설치된 시스템 구성 요소는 어디에서도 사용할 수 없으며
해당 디렉토리에 쓰기 권한이 필요합니다.
사용할 때주의하십시오 --dsymutil=예, 기존 .dSYM을 유발하므로
자동으로 삭제되고 다시 생성되는 디렉토리. 또한 dsymutil이 매우
천천히, 때로는 과도하게.
--최대 스택프레임= [기본: 2000000]
스택 프레임의 최대 크기입니다. 스택포인터가 이만큼 움직인다면
그런 다음 Valgrind는 프로그램이 다른 스택으로 전환한다고 가정합니다.
프로그램에 큰 스택 할당 배열이 있는 경우 이 옵션을 사용해야 할 수 있습니다.
Valgrind는 프로그램의 스택 포인터를 추적합니다. 이상으로 변경된 경우
임계값 양, Valgrind는 프로그램이 다른 스택으로 전환한다고 가정하고
Memcheck는 다음보다 작은 스택 포인터 변경의 경우와 다르게 동작합니다.
한계점. 일반적으로 이 휴리스틱은 잘 작동합니다. 그러나 프로그램에서 많은 양을 할당하는 경우
스택에 구조가 있는 경우 이 휴리스틱은 속고 Memcheck는 이후에
다수의 잘못된 스택 액세스를 보고합니다. 이 옵션을 사용하면
다른 값에 대한 임계값.
Valgrind의 디버그 출력이 다음과 같이 지시하는 경우에만 이 옵션의 사용을 고려해야 합니다.
그렇게 하세요. 이 경우 지정해야 하는 새 임계값을 알려줍니다.
일반적으로 스택에 큰 구조를 할당하는 것은 나쁜 생각입니다.
특히 메모리가 제한된 시스템에서 스택 공간이 부족해지기 쉽습니다.
각각 작은 스택으로 많은 수의 스레드를 지원할 것으로 예상되며, 또한
Memcheck가 수행하는 오류 검사는 힙 할당 데이터에 더 효과적입니다.
스택 할당 데이터보다 이 옵션을 사용해야 하는 경우 다음을 수행할 수 있습니다.
스택이 아닌 힙에 할당하도록 코드를 다시 작성하는 것이 좋습니다.
--메인 스택 크기= [기본: 사용 current 'ulimit' 값]
기본 스레드의 스택 크기를 지정합니다.
메모리 관리를 단순화하기 위해 Valgrind는 기본 메모리에 필요한 모든 공간을 예약합니다.
시작 시 스레드의 스택. 즉, 필요한 스택 크기를 알아야 합니다.
시작.
기본적으로 Valgrind는 스택 크기 또는 16MB에 대해 현재 "ulimit" 값을 사용합니다.
더 낮은 것. 대부분의 경우 이것은 8~16MB 범위의 스택 크기를 제공합니다.
대부분의 애플리케이션에서 오버플로가 거의 발생하지 않습니다.
더 큰 총 스택 크기가 필요한 경우 다음을 사용하십시오. --메인 스택 크기 지정합니다. 설정만
필요한 것보다 훨씬 더 많은 공간(즉, 수백
필요한 것보다 많은 메가바이트) Valgrind의 메모리 할당자를 제한하고
Valgrind가 사용할 수 있는 총 메모리 양을 줄입니다. 이것은 정말
32비트 머신에서 중요합니다.
Linux에서는 최대 2GB 크기의 스택을 요청할 수 있습니다. Valgrind는
스택을 할당할 수 없는 경우 진단 메시지입니다.
--메인 스택 크기 프로그램의 초기 스레드에 대한 스택 크기에만 영향을 미칩니다. 그것은 가지고있다
Valgrind가 스레드 스택을 할당하지 않기 때문에 스레드 스택의 크기에 영향을 미치지 않습니다.
둘 다 사용해야 할 수도 있습니다. --메인 스택 크기 그리고 --최대 스택프레임 함께. 그것은
이해하는 것이 중요합니다 --메인 스택 크기 최대 총 스택 크기를 설정합니다.
...하는 동안 --최대 스택프레임 하나의 스택 프레임의 가장 큰 크기를 지정합니다. 당신은
해결해야 --메인 스택 크기 자신을 위한 가치(일반적으로
응용 프로그램 세그먼트 오류). 그러나 Valgrind는 필요한 정보를 알려줄 것입니다. --최대 스택프레임 크기,
필요하다면.
에 대한 설명에서 더 논의된 바와 같이 --최대 스택프레임, 큰 요구 사항
스택은 잠재적인 이식성 문제의 징후입니다. 모두 배치하는 것이 가장 좋습니다.
힙 할당 메모리의 대용량 데이터.
--최대 스레드= [기본: 500]
기본적으로 Valgrind는 최대 500개의 스레드를 처리할 수 있습니다. 가끔 그 숫자가 너무
작은. 다른 제한을 제공하려면 이 옵션을 사용하십시오. 예: --max-threads=3000.
MALLOC() 관련 옵션
자체 버전의 malloc을 사용하는 도구(예: Memcheck, Massif, Helgrind, DRD)의 경우
다음 옵션이 적용됩니다.
--정렬= [기본: 8 or 16, 따라 on 전에, 플랫폼]
기본적으로 Valgrind의 Malloc, 리얼록등, 시작 주소가 다음과 같은 블록을 반환합니다.
8바이트 정렬 또는 16바이트 정렬(값은 플랫폼에 따라 다르며
플랫폼 기본값). 이 옵션을 사용하면 다른 정렬을 지정할 수 있습니다. 그만큼
제공된 값은 기본값보다 크거나 같고, 작거나 같아야 합니다.
4096이고 XNUMX의 거듭제곱이어야 합니다.
--레드존 크기= [기본: 따라 on 전에, 도구]
Valgrind의 말록, 재 할당, 등, 각 힙 블록 앞뒤에 패딩 블록을 추가합니다.
실행 중인 프로그램에 의해 할당됩니다. 이러한 패딩 블록을 레드존이라고 합니다. 그만큼
레드존 크기의 기본값은 도구에 따라 다릅니다. 예를 들어 Memcheck는 다음을 추가합니다.
클라이언트가 할당한 각 블록 전후에 최소 16바이트를 보호합니다.
이를 통해 최대 16바이트의 블록 언더런 또는 오버런을 감지할 수 있습니다.
레드존 크기를 늘리면 더 먼 거리의 오버런을 감지할 수 있습니다.
그러나 Valgrind가 사용하는 메모리 양은 증가합니다. 레드존 크기를 줄이면
Valgrind에 필요한 메모리를 줄이지만 탐지 가능성도 줄어듭니다.
오버/언더런이므로 권장하지 않습니다.
드문 옵션
이러한 옵션은 Valgrind의 특정 모호한 작업에 영향을 미치므로 모든 도구에 적용됩니다.
핵심. 대부분의 사람들은 사용할 필요가 없습니다.
--smc-체크= [기본: 파일이 아닌 파일 을 통한 x86/amd64/s390x,
스택 을 통한 other 아치]
이 옵션은 Valgrind의 자체 수정 코드 감지를 제어합니다. 확인이 없으면
완료, 프로그램이 일부 코드를 실행한 다음 새 코드로 덮어쓰고
새 코드를 실행하면 Valgrind는 계속해서 번역을 실행합니다.
이전 코드. 이로 인해 잘못된 동작 및/또는 충돌이 발생할 수 있습니다.
"최신" 아키텍처의 경우 -- x86, amd64 또는 s390x가 아닌 모든 것 -- 기본값
is 스택. 이는 올바른 프로그램이 재설정을 위해 명시적인 조치를 취해야 하기 때문입니다.
코드 수정 후 DI 캐시 일관성. Valgrind는 그러한 사항을 관찰하고 존중합니다.
자체 수정 코드가 XNUMX으로 투명하게 처리되는 결과
추가 비용.
x86, amd64 및 s390x의 경우 프로그램에서 다음을 하드웨어에 알릴 필요가 없습니다.
필수 DI 일관성 동기화. 따라서 기본값은 파일이 아닌 파일,
익명(파일 지원되지 않음) mmap'd 영역으로 코드를 생성하는 일반적인 경우.
사용 가능한 네 가지 설정의 의미는 다음과 같습니다. 감지되지 않음(없음),
스택에서 자체 수정 코드 감지(GCC에서 중첩을 구현하는 데 사용됨)
기능) (스택), 모든 곳에서 자체 수정 코드를 감지합니다(모든), 감지
파일 지원 매핑을 제외한 모든 곳에서 자체 수정 코드(파일이 아닌 파일).
함께 실행 모든 Valgrind가 눈에 띄게 느려집니다. 함께 실행 없음 드물게
대부분의 프로그램에서 동적으로 생성되는 코드가 거의 없기 때문에 작업 속도가 빨라집니다.
The VALGRIND_DISCARD_TRANSLATIONS 클라이언트 요청은 --smc-체크=모두
그리고 --smc-check=모든 파일이 아닌 파일 더 많은 프로그래머 노력이 필요하지만 Valgrind
번역이 필요한 시점을 정확하게 알려줌으로써 프로그램을 더 빠르게 실행할 수 있습니다.
다시 만들었습니다.
--smc-check=모든 파일이 아닌 파일 저렴하지만 더 제한된 버전을 제공합니다.
--smc-체크=모두. 출처가 아닌 모든 번역에 확인을 추가합니다.
파일 지원 메모리 매핑. 코드를 생성하는 일반적인 애플리케이션(예: JIT)
웹 브라우저에서 익명 mmaped 영역에 코드를 생성하는 반면 "고정" 코드는
브라우저는 항상 파일 지원 매핑에 있습니다. --smc-check=모든 파일이 아닌 파일 소요
이 관찰의 장점은 확인의 오버헤드를 코드로 제한하는 것입니다.
JIT가 생성될 가능성이 높습니다.
--읽기-인라인-정보= [기본: 참조 이하]
활성화되면 Valgrind는 DWARF3에서 인라인된 함수 호출에 대한 정보를 읽습니다.
디버그 정보. 이렇게 하면 Valgrind 시작 속도가 느려지고 더 많은 메모리를 사용하게 됩니다(일반적으로
각각의 인라인 코드 조각, 함수 이름을 위한 6단어 및 공백), 그러나 결과는
더 설명적인 스택 트레이스에서. 3.10.0 릴리스의 경우 이 기능이 활성화됩니다.
기본적으로 Linux, Android 및 Solaris 대상 및 도구에만 해당
멤체크, 헬그린드, DRD. 다음은 일부 스택 추적의 예입니다.
--read-inline-info=아니오:
==15380== 조건부 점프 또는 이동은 초기화되지 않은 값에 따라 달라집니다.
==15380== 0x80484EA에서: 메인(inlinfo.c:6)
== 15380 ==
==15380== 조건부 점프 또는 이동은 초기화되지 않은 값에 따라 달라집니다.
==15380== 0x8048550에서: fun_noninline(inlinfo.c:6)
==15380== 0x804850E: 메인(inlinfo.c:34)
== 15380 ==
==15380== 조건부 점프 또는 이동은 초기화되지 않은 값에 따라 달라집니다.
==15380== 0x8048520에서: 메인(inlinfo.c:6)
그리고 여기에 같은 오류가 있습니다. --읽기-인라인-정보=예:
==15377== 조건부 점프 또는 이동은 초기화되지 않은 값에 따라 달라집니다.
==15377== 0x80484EA에서: fun_d(inlinfo.c:6)
==15377== 0x80484EA에 의해: fun_c (inlinfo.c:14)
==15377== 0x80484EA에 의해: fun_b (inlinfo.c:20)
==15377== 0x80484EA에 의해: fun_a (inlinfo.c:26)
==15377== 0x80484EA에 의해: 메인(inlinfo.c:33)
== 15377 ==
==15377== 조건부 점프 또는 이동은 초기화되지 않은 값에 따라 달라집니다.
==15377== 0x8048550에서: fun_d(inlinfo.c:6)
==15377== 0x8048550: fun_noninline(inlinfo.c:41)
==15377== 0x804850E: 메인(inlinfo.c:34)
== 15377 ==
==15377== 조건부 점프 또는 이동은 초기화되지 않은 값에 따라 달라집니다.
==15377== 0x8048520에서: fun_d(inlinfo.c:6)
==15377== 0x8048520: 메인(inlinfo.c:35)
--읽기-var-정보= [기본: 아니요]
활성화되면 Valgrind는 다음에서 변수 유형 및 위치에 대한 정보를 읽습니다.
DWARF3 디버그 정보. 이렇게 하면 Valgrind 시작 속도가 크게 느려지고
훨씬 더 많은 메모리를 사용할 수 있는 도구(Memcheck,
Helgrind, DRD) 더 정확한 오류 메시지가 나타날 수 있습니다. 예를 들면 다음과 같습니다.
Memcheck에서 발행한 몇 가지 표준 오류:
==15363== 클라이언트 확인 요청 중 초기화되지 않은 바이트 발견
==15363== 0x80484A9에서: 크락(varinfo1.c:28)
==15363== 0x8048544: 메인(varinfo1.c:55)
==15363== 주소 0x80497f7은 데이터 기호 "global_i7" 내부의 2바이트입니다.
== 15363 ==
==15363== 클라이언트 확인 요청 중 초기화되지 않은 바이트 발견
==15363== 0x80484A9에서: 크락(varinfo1.c:28)
==15363== 0x8048550: 메인(varinfo1.c:56)
==15363== 주소 0xbea0d0cc는 스레드 1의 스택에 있습니다.
==15363== 메인(varinfo1.c:1)에 의해 생성된 프레임 #45에서
그리고 여기에 같은 오류가 있습니다. --read-var-info=예:
==15370== 클라이언트 확인 요청 중 초기화되지 않은 바이트 발견
==15370== 0x80484A9에서: 크락(varinfo1.c:28)
==15370== 0x8048544: 메인(varinfo1.c:55)
==15370== 위치 0x80497f7은 global_i0[2] 내부의 7바이트입니다.
==15370== varinfo1.c:41에 선언된 전역 변수
== 15370 ==
==15370== 클라이언트 확인 요청 중 초기화되지 않은 바이트 발견
==15370== 0x80484A9에서: 크락(varinfo1.c:28)
==15370== 0x8048550: 메인(varinfo1.c:56)
==15370== 위치 0xbeb4a0cc는 로컬 변수 "local" 내부의 0바이트입니다.
==15370== 스레드 1의 프레임 #46에서 varinfo1.c:1에 선언됨
--vgdb-폴= [기본: 5000]
메인 루프의 일부로 Valgrind 스케줄러는 일부 활동이 있는지 확인하기 위해 폴링합니다.
(예: 외부 명령 또는 gdb의 일부 입력)은 gdbserver에서 처리해야 합니다.
이 활동 폴링은 주어진 수의 기본 블록을 실행한 후에 수행됩니다(또는
주어진 기본 블록 수보다 약간 더 많음). 이 설문조사는 매우 저렴하므로
기본값은 비교적 낮게 설정되어 있습니다. vgdb인 경우 이 값을 더 줄일 수 있습니다.
모든 스레드가 (대부분의
시간) 시스템 호출에서 차단됩니다.
--vgdb-shadow-registers=아니요|예 [기본: 아니요]
활성화되면 gdbserver는 Valgrind 섀도우 레지스터를 GDB에 노출합니다. 이것으로,
Valgrind 섀도우 레지스터의 값은 GDB를 사용하여 검사하거나 변경할 수 있습니다.
섀도우 레지스터 노출은 GDB 버전 7.1 이상에서만 작동합니다.
--vgdb-접두사= [기본: /tmp/vgdb-파이프]
gdb/vgdb와 통신하기 위해 Valgrind gdbserver는 3개의 파일(2개의 명명된 FIFO
및 mmap 공유 메모리 파일). 접두사 옵션은 디렉터리와 접두사를 제어합니다.
이러한 파일의 생성을 위해.
--실행-libc-freeres= [기본: 예]
이 옵션은 Linux에서 Valgrind를 실행할 때만 관련이 있습니다.
GNU C 라이브러리(libc.so), 모든 프로그램에서 사용하는 메모리를 할당할 수 있습니다.
자체 용도. 일반적으로 프로그램이 종료될 때 해당 메모리를 해제하지 않아도 됩니다.
Linux 커널은 모든 프로세스 리소스를 회수할 때
어쨌든 프로세스가 종료되므로 속도가 느려질 것입니다.
glibc 작성자는 이 동작이 Valgrind와 같은 누출 검사기를 유발한다는 것을 깨달았습니다.
종료 시 누수 검사가 수행될 때 glibc의 누수를 잘못 보고합니다. 피하기 위해
이를 위해 그들은 다음과 같은 루틴을 제공했습니다. __libc_freeres 특히 glibc 릴리스를 만들기 위해
할당된 모든 메모리. 따라서 Memcheck는 실행을 시도합니다. __libc_freeres 출구에서.
불행하게도 glibc의 매우 오래된 일부 버전에서는 __libc_freeres 충분히
세분화 오류를 일으키는 버그. 이것은 Red Hat 7.1에서 특히 두드러졌습니다.
따라서 이 옵션은 실행을 금지하기 위해 제공됩니다. __libc_freeres. 경우
프로그램이 Valgrind에서 제대로 실행되는 것 같지만 종료 시 segfaults가 발생할 수 있습니다.
--run-libc-freeres=아니요 잘못 보고할 가능성이 있지만 이를 수정합니다.
libc.so에서 공간 누수.
--sim-힌트=힌트1,힌트2,...
시뮬레이트된 동작을 약간 수정하는 기타 힌트를 Valgrind에 전달합니다.
이상한 기능의 시뮬레이션을 돕기 위해 비표준 또는 위험한 방법. 에 의해
기본적으로 힌트가 활성화되지 않습니다. 주의하여 사용하십시오! 현재 알려진 힌트는 다음과 같습니다.
· lax-ioctls: ioctl 처리에 대해 매우 느슨해집니다. 유일한 가정은 크기입니다.
맞다. 쓸 때 전체 버퍼를 초기화할 필요가 없습니다.
이것이 없으면 이상한 ioctl이 많은 일부 장치 드라이버를 사용하여
명령이 매우 귀찮아집니다.
· 퓨즈 호환: 차단할 수 있는 특정 시스템 호출에 대한 특수 처리 사용
FUSE 파일 시스템에서. 이는 Valgrind를 실행할 때 필요할 수 있습니다.
하나의 스레드를 사용하여 FUSE 파일 시스템을 관리하는 다중 스레드 프로그램 및
해당 파일 시스템에 액세스하는 다른 스레드.
· 외부 활성화: 실행 중인 프로그램이 실행될 때 필요한 특수 마법을 활성화합니다.
자체 Valgrind.
· 내부 접두사 없음: 접두사 인쇄 비활성화 > 각 stdout 또는 stderr 앞에
외부 Valgrind에 의해 실행되는 내부 Valgrind의 출력 라인. 이것은 유용하다
외부/내부 설정에서 Valgrind 회귀 테스트를 실행할 때. 참고
접두사 > 항상 내부 디버그 로깅 행 앞에 인쇄됩니다.
· no-nptl-pthread-스택캐시: 이 힌트는 Valgrind를 실행할 때만 관련이 있습니다.
리눅스.
GNU glibc pthread 라이브러리(libpthread.so), pthread 프로그램에서 사용하는
pthread 스택의 캐시를 유지합니다. pthread가 종료되면 사용된 메모리
pthread 스택 및 일부 스레드 로컬 스토리지 관련 데이터 구조는
항상 직접 공개합니다. 이 메모리는 캐시에 보관(특정 크기까지),
새 스레드가 시작되면 재사용됩니다.
이 캐시로 인해 helgrind 도구는 일부 오탐 경쟁 조건을 보고합니다.
helgrind가 내부 glibc를 이해하지 못하기 때문에 이 캐시된 메모리의 오류
캐시 동기화 프리미티브. 따라서 helgrind를 사용할 때 캐시 비활성화
특히 스레드를 사용할 때 오탐 경쟁 조건을 피하는 데 도움이 됩니다.
로컬 저장 변수(예: __실 한정자).
memcheck 도구를 사용할 때 캐시를 비활성화하면 glibc에서 사용하는 메모리가 보장됩니다.
__thread 변수를 처리하는 것은 스레드가 종료될 때 직접 해제됩니다.
참고: Valgrind는 glibc 스택의 일부 내부 지식을 사용하여 캐시를 비활성화합니다.
캐시 구현 및 pthread의 디버그 정보를 검사하여
도서관. 따라서 이 기술은 다소 취약하며 모든 glibc에서 작동하지 않을 수 있습니다.
버전. 이것은 다양한 glibc 버전(예:
2.11, 2.16, 2.18) 다양한 플랫폼에서.
· 느슨한 문: (Solaris에만 해당) 도어 시스템 호출 처리에 대해 매우 느슨합니다.
인식할 수 없는 도어 파일 설명자. 전체 버퍼가 필요하지 않습니다.
작성할 때 초기화됩니다. 이것이 없으면 사용하는 프로그램 libdoor(3LIB) 기능
완전히 독점적인 의미 체계를 사용하면 많은 수의 오 탐지가 보고될 수 있습니다.
--공정한 일정= [기본: 아니요]
The --공정한 일정 옵션은 Valgrind가 직렬화하는 데 사용하는 잠금 메커니즘을 제어합니다.
스레드 실행. 잠금 메커니즘은 스레드가 예약되는 방식을 제어합니다.
다른 설정은 공정성과 성능 사이에 다른 절충점을 제공합니다. 을 위한
Valgrind 스레드 직렬화 체계 및 이것이 다음에 미치는 영향에 대한 자세한 내용
성능 및 스레드 스케줄링은 스케줄링 및 다중 스레드 성능을 참조하십시오.
· 가치 --fair-sched=예 공정한 스케줄러를 활성화합니다. 한마디로 여러개라면
스레드를 실행할 준비가 되면 스레드는 라운드 로빈 방식으로 예약됩니다.
이 메커니즘은 모든 플랫폼 또는 Linux 버전에서 사용할 수 없습니다. 그렇지 않다면
사용 가능, 사용 --fair-sched=예 Valgrind가 오류와 함께 종료됩니다.
이 설정은
예를 들어 Valgrind의 웹 브라우저와 같은 대화형 다중 스레드 프로그램입니다.
· 가치 --fair-sched=시도 플랫폼에서 사용 가능한 경우 공정 일정을 활성화합니다.
그렇지 않으면 자동으로 --fair-sched=아니오.
· 가치 --fair-sched=아니오 공정성을 보장하지 않는 스케줄러를 활성화합니다.
실행할 준비가 된 스레드 사이에 있지만 일반적으로 가장 높은 성능을 제공합니다.
--커널-변형=변형1,변형2,...
기본 커널의 사소한 변형에서 발생하는 시스템 호출 및 ioctl을 처리합니다.
이 플랫폼. 이것은 해킹된 커널에서 실행하거나 커널 모듈과 함께 실행하는 데 유용합니다.
예를 들어 비표준 ioctl을 지원합니다. 주의하여 사용하십시오. 당신이하지 않으면
이 옵션이 무엇인지 이해하면 거의 확실하게 필요하지 않습니다. 현재
알려진 변형은 다음과 같습니다.
· bproc: 지원 sys_broc x86에서 시스템 호출. 이것은 BProc에서 실행하기 위한 것입니다.
때때로 빌드에 사용되는 표준 Linux의 사소한 변형입니다.
클러스터.
· 안드로이드-no-hw-tls: ARM용 Android 에뮬레이터의 일부 버전은
하드웨어 TLS(스레드 로컬 상태) 등록 및 Valgrind가 시작 시 충돌합니다. 사용
이 변형은 TLS에 대한 소프트웨어 지원을 선택합니다.
· 안드로이드-gpu-sgx5xx: 전용 ioctl 처리를 지원하는 데 사용합니다.
Android 기기의 PowerVR SGX 5XX 시리즈 GPU. 이것을 선택하지 않으면
안정성 문제를 일으킬 수 있지만 Memcheck에서 잘못된 오류를 보고할 수 있습니다.
프로그램은 GPU 관련 ioctl을 수행합니다.
· 안드로이드-gpu-adreno3xx: 유사하게, 소유권 처리를 지원하는 데 사용합니다.
Android 장치의 Qualcomm Adreno 3XX 시리즈 GPU용 ioctls.
--병합-재귀-프레임= [기본: 0]
예를 들어 균형 이진 트리 구현과 같은 일부 재귀 알고리즘은 다음을 생성합니다.
각각 호출 주기를 포함하는 다양한 스택 추적. 주기는 다음과 같이 정의됩니다.
XNUMX개 이상의 다른 프로그램 카운터로 분리된 두 개의 동일한 프로그램 카운터 값
가치. 그런 다음 Valgrind는 이러한 모든 스택 추적을 저장하기 위해 많은 메모리를 사용할 수 있습니다. 이것은
이러한 스택 추적에 반복적으로 흥미롭지 않은 내용이 포함되어 있다는 점을 고려하면 메모리 사용이 좋지 않습니다.
함수와 같은 더 흥미로운 정보 대신 재귀 호출
재귀 호출을 시작했습니다.
옵션 --병합-재귀-프레임= Valgrind가 감지하고 병합하도록 지시합니다.
크기가 최대인 재귀 호출 주기 프레임. 그러한 주기가 있을 때
감지되면 Valgrind는 스택 추적의 주기를 고유한 프로그램 카운터로 기록합니다.
값 0(기본값)은 재귀 호출 병합을 유발하지 않습니다. 값 1은
간단한 재귀 알고리즘의 스택 추적(예: 계승 구현)
무너질 것. 일반적으로 생성된 스택 추적을 축소하려면 값 2가 필요합니다.
이진 트리, 빠른 정렬 등과 같은 재귀 알고리즘에 의해. 더 높은 값은
더 복잡한 재귀 알고리즘에 필요합니다.
참고: 재귀 호출은 프로그램 카운터 값 분석을 통해 감지됩니다. 그들은 아니다
함수 이름을 보면 감지됩니다.
--num-transtab-sectors= [기본: 6 을 통한 Android 플랫폼, 16 을 통한 모든 기타]
Valgrind는 프로그램의 기계 코드를 작은 조각으로 변환하고 계측합니다.
(기본 블록). 번역은 분할된 번역 캐시에 저장됩니다.
여러 섹션(섹터)으로 캐시가 가득 차면 해당 섹터가
가장 오래된 번역은 비워지고 재사용됩니다. 이러한 오래된 번역이 다시 필요한 경우,
Valgrind는 해당 기계 코드를 다시 번역하고 다시 계측해야 합니다.
값비싼. 프로그램의 "실행 명령" 작업 세트가 크면 증가
섹터 수는 섹터 수를 줄임으로써 성능을 향상시킬 수 있습니다.
재번역이 필요합니다. 섹터는 필요에 따라 할당됩니다. 일단 할당되면 섹터는 다음을 수행할 수 있습니다.
해제되지 않으며 도구와 값에 따라 상당한 공간을 차지합니다.
of --avg-transtab-항목 크기 (Memcheck의 경우 섹터당 약 40MB). 옵션 사용
--통계=예 섹터에서 사용하는 메모리에 대한 정확한 정보를 얻기 위해
섹터 할당 및 재활용.
--avg-transtab-entry-size= [기본: 0, 의미 사용 수단 제공 기본]
변환된 기본 블록의 평균 크기입니다. 이 평균 크기는 치수를 측정하는 데 사용됩니다.
섹터의 크기. 각 도구는 사용할 기본값을 제공합니다. 이 기본값인 경우
너무 작으면 번역 섹터가 너무 빨리 가득 찰 것입니다. 이 기본값인 경우
값이 너무 크면 번역 섹터 메모리의 상당 부분이 사용되지 않습니다.
기본 블록 변환의 평균 크기는 도구에 따라 다르며
도구 옵션에 따라 달라집니다. 예를 들어, memcheck 옵션 --track-origins=예 증가
기본 블록 번역의 크기. 사용 --avg-transtab-항목 크기 튜닝하기 위해
메모리를 확보하거나 너무 많은 재변환을 피하기 위해 섹터 크기.
--aspace-minaddr= [기본: 따라 on 전에, 플랫폼]
일부 시스템 라이브러리와의 잠재적인 충돌을 피하기 위해 Valgrind는
아래 주소 공간 --aspace-minaddr 값, 라이브러리의 경우 예약 유지
특히 이 영역의 메모리를 요청합니다. 따라서 일부 "비관적" 값이 추측됩니다.
플랫폼에 따라 Valgrind에 의해. Linux에서 기본적으로 Valgrind는
일반적으로 이 전체 영역에 충돌이 없더라도 처음 64MB입니다. 당신이 사용할 수있는
옵션 --aspace-minaddr 메모리가 부족한 응용 프로그램이 혜택을 받도록
이 낮은 메모리를 더 많이 사용합니다. 반면에 갈등이 발생하면 증가합니다.
aspace-minaddr 값으로 해결할 수 있습니다. 갈등은 일반적으로 다음과 같이 나타납니다.
주소 공간의 낮은 범위에서 mmap 실패. 제공된 주소는 페이지여야 합니다.
정렬되고 0x1000(4KB)보다 크거나 같아야 합니다. 귀하의 기본값을 찾으려면
valgrind -d -d date 2>&1 | grep -i minaddr. 가치
0x10000(64KB) 미만은 일부 배포판에서 문제를 일으키는 것으로 알려져 있습니다.
--valgrind-stacksize= [기본: 1MB]
각 스레드에 대해 Valgrind에는 자체 '개인' 스택이 필요합니다. 이들의 기본 크기
스택은 대부분 크기가 정해져 있으므로 대부분의 경우 충분합니다. 경우에
크기가 너무 작으면 Valgrind가 segfault합니다. segfaulting 전에 경고가 표시될 수 있습니다.
한계에 접근할 때 Valgrind에 의해 생성됩니다.
옵션을 사용 --valgrind-스택 크기 그러한 (있을 법하지 않은) 경고가 생성되는 경우 또는
Valgrind는 분할 위반으로 사망합니다. 이러한 세분화 위반은
거대한 C++ 기호를 디맹글링할 때 표시됩니다.
응용 프로그램이 많은 스레드를 사용하고 많은 메모리가 필요한 경우 약간의 이점을 얻을 수 있습니다.
옵션을 사용하여 이러한 Valgrind 스택의 크기를 줄임으로써 메모리
--valgrind-스택 크기.
--show-emwarns= [기본: 아니요]
활성화되면 Valgrind는 특정 경우에 CPU 에뮬레이션에 대한 경고를 표시합니다.
이들은 일반적으로 흥미롭지 않습니다.
--require-text-symbol=:sonnamepatt:fnnamepatt
soname이 일치하는 공유 객체가 소나메패트 프로세스에 로드됩니다.
내보내는 모든 텍스트 기호를 검사합니다. 일치하는 항목이 없으면 fnnamepatt, 인쇄
오류 메시지를 표시하고 실행을 중단합니다. 이를 통해 실행이
주어진 공유 객체가 특정 함수 이름을 포함하지 않는 한 계속되지 않습니다.
모두 소나메패트 그리고 fnnamepatt 평소 사용하여 쓸 수 있습니다 ? 그리고 * 와일드 카드. 을 위한
예: ":*libc.so*:foo?bar". 콜론 이외의 문자를 사용하여 구분할 수 있습니다.
두 패턴. 첫 번째 문자와 구분 기호만 중요합니다.
캐릭터는 동일합니다. 예를 들어 위의 예는 다음과 같이 작성할 수도 있습니다.
"Q*libc.so*Qfoo?bar". 배수
--필요-텍스트-기호 플래그가 허용되며, 이 경우 로드된 공유 객체
모든 프로세스에 대해 확인됩니다.
이것의 목적은 마크업된 라이브러리의 안정적인 사용을 지원하는 것입니다. 예를 들어,
GCC 버전이 있다고 가정합니다. libgomp.so 로 표기된
Helgrind를 지원하는 주석. 잘못로드하는 것은 너무 쉽고 혼란 스럽습니다.
주석이 없는 libgomp.so 응용 프로그램에. 아이디어는 다음과 같습니다.
예를 들어 표시된 라이브러리 annotated_for_helgrind_3_6, 그런 다음 플래그를 제공
--require-text-symbol=:*libgomp*so*:annotated_for_helgrind_3_6 그래서 언제 libgomp.so
로드되면 Valgrind는 기호 테이블을 스캔하고 기호가 없으면 실행이
표시되지 않은 라이브러리를 사용하여 자동으로 계속하는 대신 중단되었습니다. 참고
포탄이 위로 확장되는 것을 막기 위해 전체 플래그를 따옴표로 묶어야 합니다. * 그리고 ?
와일드 카드.
--soname-synonyms=syn1=패턴1,syn2=패턴2,...
공유 라이브러리가 로드되면 Valgrind는 라이브러리에서 다음과 같은 기능을 확인합니다.
교체하거나 포장해야 합니다. 예를 들어 Memcheck는 모든 malloc 관련
자체 버전의 함수(malloc, free, calloc, ...). 이러한 교체는
기본적으로 soname이 미리 정의된 soname과 일치하는 공유 라이브러리에서만 수행됩니다.
패턴(예: libc.so* 리눅스에서). 기본적으로 정적으로 대체가 수행되지 않습니다.
링크된 라이브러리 또는 tcmalloc과 같은 대체 라이브러리용. 경우에 따라
교체 허용 --soname-동의어 하나의 추가 동의어 패턴을 지정하려면
교체의 유연성.
현재 이 유연성은 다음을 사용하여 malloc 관련 기능에만 허용됩니다.
동의어 소말록. 이 동의어는 표준 교체를 수행하는 모든 도구에 사용할 수 있습니다.
malloc 관련 함수(예: memcheck, massif, drd, helgrind, exp-dhat,
특급-sgcheck).
· 대체 malloc 라이브러리: 대체에서 malloc 관련 기능을 대체합니다.
이름이 있는 라이브러리 mymalloclib.so, 옵션을 제공
--soname-synonyms=somalloc=mymalloclib.so. 패턴을 사용하여 여러 항목을 일치시킬 수 있습니다.
라이브러리 sonames. 예를 들어, --soname-synonyms=somalloc=*tcmalloc* 일치합니다
tcmalloc 라이브러리의 모든 변형 이름(네이티브, 디버그, 프로필, ...
tcmalloc 변형).
참고: elf 공유 라이브러리의 soname은 readelf를 사용하여 검색할 수 있습니다.
유용.
· 정적으로 연결된 라이브러리의 교체는 다음을 사용하여 수행됩니다. 없음 패턴입니다.
예를 들어 다음과 연결하면 libtcmalloc.a, memcheck는 다음과 같은 경우 제대로 작동합니다.
선택권을 주다 --soname-동의어=somalloc=NONE. NONE 패턴은
기본 실행 파일과 soname이 없는 공유 라이브러리를 일치시킵니다.
· JEMalloc이
기본 실행 파일, 사용 --soname-동의어=somalloc=NONE.
디버깅 발그린드 옵션
Valgrind 자체를 디버깅하기 위한 몇 가지 옵션도 있습니다. 당신은 그들을 사용할 필요가 없습니다
정상적인 상황에서. 목록을 보려면 다음을 사용하십시오. --help-디버그 옵션을 선택합니다.
멤체크 옵션
--누설 검사= [기본: 요약]
활성화되면 클라이언트 프로그램이 종료될 때 메모리 누수를 검색합니다. 로 설정한 경우
개요, 얼마나 많은 누출이 발생했는지 나타냅니다. 로 설정한 경우 가득 찬 or 예, 각 개별 누출
옵션에 지정된 대로 자세히 표시되거나 오류로 계산됩니다.
--누출 종류 표시 그리고 --누수 유형에 대한 오류.
--누수 해결= [기본: 높은]
누출 검사를 수행할 때 Memcheck가 다른 점을 고려하는 정도를 결정합니다.
여러 누출을 단일 데이터로 병합하기 위해 백트레이스가 동일합니다.
누출 보고서. 로 설정할 때 낮은, 처음 두 항목만 일치하면 됩니다. 언제 중, 사
항목이 일치해야 합니다. 언제 높은, 모든 항목이 일치해야 합니다.
하드코어 누수 디버깅의 경우 다음을 사용하고 싶을 것입니다. --누출 해상도=높음 함께
과 --번호 호출자=40 또는 그런 큰 숫자.
참고로 --누수 해결 설정은 Memcheck의 찾기 기능에 영향을 미치지 않습니다.
누출. 결과가 표시되는 방식만 변경됩니다.
--show-leak-kinds= [기본: 확정, 가능]
표시할 누출 종류를 지정합니다. 가득 찬 다음 방법 중 하나로 누수 검색:
· 하나 이상의 쉼표로 구분된 목록 명확한 간접적 인 가능한 도달 가능.
· 모든 전체 세트(모든 누출 종류)를 지정합니다. 그것은
--show-leak-kinds=확실, 간접, 가능, 도달 가능.
· 없음 빈 세트의 경우.
--오류에 대한 누출 종류= [기본: 확정, 가능]
오류로 계산할 누출 종류를 지정합니다. 가득 찬 누출 검색. 그만큼 is
유사하게 지정된 --누출 종류 표시
--누설 검사 휴리스틱스= [기본: 모두]
누수 검색 중에 사용할 누수 검사 휴리스틱 세트를 지정합니다. 그만큼
휴리스틱은 블록에 대한 내부 포인터가 블록으로 간주되도록 제어합니다.
도달 가능. 휴리스틱 세트는 다음 방법 중 하나로 지정됩니다.
· 하나 이상의 쉼표로 구분된 목록 표준 문자열 길이64 뉴어레이
다중 상속.
· 모든 전체 휴리스틱 세트를 활성화합니다. 그것은
--leak-check-heuristics=stdstring,length64,newarray,다중 상속.
· 없음 빈 세트의 경우.
이러한 휴리스틱은 생성된 객체의 레이아웃에 따라 다릅니다.
C++ 컴파일러. 일부 gcc 버전(예: 4.4 및 4.7)에서 테스트되었습니다. 그들
다른 C++ 컴파일러에서는 제대로 작동하지 않을 수 있습니다.
--연결 가능 표시= , --show-possibly-lost=
이러한 옵션은 표시할 누수 유형을 지정하는 다른 방법을 제공합니다.
· --show-도달 가능=아니오 --show-possibly-lost=예 에 해당하는
--show-leak-kinds=확실, 가능.
· --show-도달 가능=아니오 --show-possibly-lost=아니오 에 해당하는
--show-leak-kinds=확실.
· --show-도달 가능=예 에 해당하는 --show-leak-kinds=모두.
참고 --show-possibly-lost=아니오 경우에는 효과가 없습니다 --show-도달 가능=예 이 지정됩니다.
--undef-값-오류= [기본: 예]
Memcheck가 정의되지 않은 값 오류 사용을 보고하는지 여부를 제어합니다. 이것을 다음으로 설정 아니 if
정의되지 않은 값 오류를 보고 싶지 않습니다. 과속의 부작용도 있다.
위로 Memcheck 다소.
--추적 출처= [기본: 아니요]
Memcheck가 초기화되지 않은 값의 출처를 추적하는지 여부를 제어합니다. 기본적으로
즉, 초기화되지 않은 값이
위험한 방식으로 사용되면 초기화되지 않은 값이 어디에서 왔는지 알 수 없습니다.
에서. 이로 인해 종종 근본 문제를 추적하기가 어렵습니다.
설정시 예, Memcheck는 초기화되지 않은 모든 값의 출처를 추적합니다.
그런 다음 초기화되지 않은 값 오류가 보고되면 Memcheck는
가치의 기원. 원본은 다음 네 가지 위치 중 하나일 수 있습니다. 힙 블록,
스택 할당, 클라이언트 요청 또는 기타 기타 소스(예:
BRK).
힙 블록에서 시작된 초기화되지 않은 값의 경우 Memcheck는 블록이 어디에 있는지 보여줍니다.
할당되었습니다. 스택 할당에서 발생하는 초기화되지 않은 값의 경우 Memcheck
어떤 함수가 값을 할당했는지 알 수 있지만 그 이상은 아닙니다.
함수의 여는 중괄호의 소스 위치를 보여줍니다. 그래서 당신은
함수의 모든 지역 변수가 제대로 초기화되었는지 주의 깊게 확인하십시오.
성능 오버헤드: 원본 추적은 비용이 많이 듭니다. Memcheck의 속도를 절반으로 줄이고
최소 100MB, 가능하면 그 이상까지 메모리 사용을 늘립니다. 그럼에도 불구하고 그것은 할 수 있습니다
초기화되지 않은 오류의 근본 원인을 식별하는 데 필요한 노력을 크게 줄입니다.
값 오류, 더 많이 실행하더라도 종종 프로그래머 생산성 승리
천천히.
정확도: Memcheck는 오리진을 매우 정확하게 추적합니다. 매우 큰 공간과 시간을 피하기 위해
간접비, 일부 근사치가 만들어집니다. 가능성은 희박하지만,
Memcheck는 잘못된 출처를 보고하거나 출처를 식별할 수 없습니다.
참고로 조합 --track-origins=예 그리고 --undef-값-오류=아니요 is
무의미한. Memcheck는 시작 시 이 조합을 확인하고 거부합니다.
--부분 로드 확인= [기본: 예]
Memcheck가 32, 64, 128 및 256비트에서 자연스럽게 정렬된 로드를 처리하는 방법을 제어합니다.
일부 바이트는 주소 지정이 가능하고 다른 바이트는 주소 지정이 불가능한 주소입니다. 언제 예그런
로드는 주소 오류를 생성하지 않습니다. 대신, 불법에서 발생한 로드된 바이트
주소는 초기화되지 않은 것으로 표시되며 법적 주소에 해당하는 주소는
정상적인 방법으로 처리합니다.
인셀덤 공식 판매점인 아니, 부분적으로 잘못된 주소의 로드는 다음 주소의 로드와 동일하게 처리됩니다.
완전히 잘못된 주소: 잘못된 주소 오류가 발생하고 결과
바이트는 초기화된 것으로 표시됩니다.
이러한 방식으로 동작하는 코드는 ISO C/C++ 표준을 위반하는 것입니다.
파손된 것으로 간주해야 합니다. 가능하면 이러한 코드를 수정해야 합니다.
--비싼-정의-검사= [기본: 아니요]
Memcheck를 더 정확하면서도 더 비싸게 사용해야 하는지 여부를 제어합니다(시간
소비) 알고리즘을 사용하여 값의 정의를 확인할 수 있습니다. 기본 설정은
그렇게 하지 않으며 일반적으로 충분합니다. 그러나 고도로 최적화된 코드의 경우
valgrind는 때때로 잘못 불평할 수 있습니다. valgrind 호출
--비싼-정의-검사=예 도움이 되지만 성능 비용이 발생합니다. 실행 시간
25%의 저하가 관찰되었지만 추가 비용은
손에 응용 프로그램.
--keep-stacktraces=alloc|자유|할당 및 무료|할당 후 무료|없음 [기본:
할당 및 해제]
malloc'd 및/또는 free'd 블록에 대해 유지할 스택 추적을 제어합니다.
와 할당 후 무료, 할당 시간에 스택 추적이 기록되고 연결됩니다.
블록과 함께. 블록이 해제되면 두 번째 스택 추적이 기록되며 이
할당 스택 추적을 대체합니다. 결과적으로 관련 "사용 후 무료" 오류
이 블록은 블록이 해제된 위치에 대한 스택 추적만 표시할 수 있습니다.
와 할당 및 해제, 블록에 대한 할당 및 할당 해제 스택 추적
저장됩니다. 따라서 "무료 사용 후 사용" 오류는 두 가지 모두를 표시하며, 이로 인해 오류가 발생할 수 있습니다.
진단하기가 더 쉽습니다. 에 비해 할당 후 무료, 이 설정은 약간 증가합니다.
블록으로 사용되는 Valgrind의 메모리 사용에는 하나가 아닌 두 개의 참조가 포함됩니다.
와 할당, 할당 스택 추적만 기록(및 보고)됩니다. 와 함께 비어 있는,
할당 해제 스택 추적만 기록(및 보고)됩니다. 이 값은 다소
Valgrind의 메모리 및 CPU 사용량을 줄입니다. 오류에 따라 유용할 수 있습니다.
검색 중인 유형과 이를 분석하는 데 필요한 세부 수준. 을 위한
예를 들어, 메모리 누수 오류에만 관심이 있다면 기록하는 것으로 충분합니다.
할당 스택 추적.
와 없음, malloc 및 free 작업에 대한 스택 추적이 기록되지 않습니다. 당신의
프로그램이 많은 블록을 할당하거나 다양한 스택에서 할당/해제
이는 필요한 CPU 및/또는 메모리를 크게 줄일 수 있습니다. 물론 소수
힙 블록과 관련된 오류에 대한 세부 정보가 보고됩니다.
스택 추적이 기록되면 Valgrind는 메모리에 스택 추적을 유지합니다.
어떤 블록에서도 참조하지 않는 경우에도 마찬가지입니다. 일부 프로그램(예: 재귀
알고리즘) 엄청난 수의 스택 추적을 생성할 수 있습니다. Valgrind가 너무 많이 사용하는 경우
이러한 상황에서 옵션으로 필요한 메모리를 줄일 수 있습니다.
--keep-스택추적 및/또는 옵션에 더 작은 값을 사용하여 --발신자 수.
--프리리스트-볼륨= [기본: 20000000]
클라이언트 프로그램이 다음을 사용하여 메모리를 해제할 때 비어 있는 (C에서) 또는 삭제(C++), 해당 메모리
즉시 재할당할 수 없습니다. 대신 표시가 되어 있습니다
액세스할 수 없고 해제된 블록의 대기열에 배치됩니다. 연기하는 것이 목적
해제된 메모리가 다시 순환되는 지점이 가능합니다. 이것
Memcheck가 블록에 대한 유효하지 않은 액세스를 감지할 수 있는 가능성을 높입니다.
해방된 후 상당 기간 동안.
이 옵션은 대기열에 있는 블록의 최대 총 크기(바이트)를 지정합니다.
기본값은 XNUMX천만 바이트입니다. 이것을 늘리면 총 금액이 증가합니다.
Memcheck에서 사용하는 메모리의 양이지만 해제된 블록의 유효하지 않은 사용을 감지할 수 있습니다.
그렇지 않으면 감지되지 않습니다.
--프리리스트-빅-블록= [기본: 1000000]
해제된 블록의 대기열에서 블록을 재할당할 수 있도록 만들 때,
Memcheck는 크기가 크거나 같은 블록을 우선적으로 재순환합니다.
--freelist-빅-블록. 이렇게 하면 큰 블록을 해제(특히 해제)할 수 있습니다.
보다 큰 블록 --freelist-vol)는 즉시 재순환으로 이어지지 않습니다.
사용 가능한 목록의 모든(또는 많은) 작은 블록. 즉, 이 옵션은
"작은" 블록에 대한 댕글링 포인터를 발견할 가능성을 높입니다.
큰 블록이 해제될 때.
값을 0으로 설정하면 모든 블록이 FIFO 순서로 재순환됨을 의미합니다.
--해결 방법-gcc296-버그= [기본: 아니요]
활성화되면 스택 포인터 아래에서 약간의 거리를 읽고 쓴다고 가정합니다.
GCC 2.96의 버그로 인해 보고하지 않습니다. "작은 거리"는 256입니다.
기본적으로 바이트. GCC 2.96은 일부 고대 Linux의 기본 컴파일러입니다.
배포판(RedHat 7.X)이므로 이 옵션을 사용해야 할 수도 있습니다. 다음과 같은 경우 사용하지 마십시오.
실제 오류를 간과할 수 있으므로 그럴 필요가 없습니다. 더 나은 대안
이 버그가 수정된 최신 GCC를 사용하는 것입니다.
3비트에서 GCC 4.X 또는 32.X로 작업할 때 이 옵션을 사용해야 할 수도 있습니다.
파워PC 리눅스. 이는 GCC가 때때로 아래에 액세스하는 코드를 생성하기 때문입니다.
스택 포인터, 특히 부동 소수점에서 정수로/에서 변환하는 경우. 이것
32비트 PowerPC ELF 사양을 위반하는 것입니다.
액세스할 수 있는 스택 포인터 아래의 위치.
--show-mismatched-frees= [기본: 예]
활성화되면 Memcheck는 다음 기능을 사용하여 힙 블록이 할당 해제되었는지 확인합니다.
할당 기능과 일치합니다. 즉 기대한다. 비어 있는 할당 해제에 사용
에 의해 할당된 블록 Malloc, 삭제 에 의해 할당된 블록 및 지우다[] 을 통한
에 의해 할당된 블록 새로운[]. 불일치가 감지되면 오류가 보고됩니다. 이것은
일부 환경에서는 일치하지 않는 기능으로 해제하기 때문에 일반적으로 중요합니다.
충돌을 일으킬 수 있습니다.
그러나 이러한 불일치를 피할 수 없는 시나리오가 있습니다. 그 때
사용자는 구현을 제공합니다 /새로운[] 그 전화 Malloc 및 삭제/지우다[]
그 전화 비어 있는, 그리고 이러한 함수는 비대칭적으로 인라인됩니다. 예를 들어 상상해보십시오.
그 지우다[] 인라인되지만 새로운[] 아니다. 그 결과 Memcheck는 모든 것을 "본다"
지우다[] 전화를 직접 전화로 비어 있는, 프로그램 소스에 포함되어 있지 않은 경우에도
일치하지 않는 통화.
이로 인해 혼란스럽고 관련 없는 오류 보고서가 많이 발생합니다.
--show-mismatched-frees=아니오 이러한 검사를 비활성화합니다. 하는 것은 일반적으로 바람직하지 않습니다.
결과적으로 실제 오류를 놓칠 수 있으므로 비활성화하십시오.
--무시 범위=0xPP-0xQQ[,0xRR-0xSS]
이 옵션에 나열된 모든 범위(여러 범위를 지정하고 다음으로 구분할 수 있음)
쉼표)는 Memcheck의 주소 지정 가능성 검사에서 무시됩니다.
--malloc 채우기=
calloc이 아닌 malloc, new 등에 의해 할당된 블록을 지정된 값으로 채웁니다.
바이트. 모호한 메모리 손상 문제를 해결하려고 할 때 유용할 수 있습니다.
할당된 영역은 여전히 Memcheck에서 정의되지 않은 것으로 간주됩니다. 이 옵션은
내용에 영향을 미칩니다. 참고 --malloc 채우기 때 메모리 블록에 영향을 미치지 않습니다.
클라이언트 요청 VALGRIND_MEMPOOL_ALLOC에 대한 인수로 사용되거나
VALGRIND_MALLOCLIKE_BLOCK.
--자유 채우기=
free, delete 등으로 해제된 블록을 지정된 바이트 값으로 채웁니다. 이것은 될 수있다
모호한 메모리 손상 문제를 해결하려고 할 때 유용합니다. 해방된 지역은
여전히 Memcheck는 액세스에 유효하지 않은 것으로 간주합니다. 이 옵션은
내용물. 참고 --자유 채우기 다음과 같이 사용될 때 메모리 블록에 영향을 미치지 않습니다.
클라이언트 요청 VALGRIND_MEMPOOL_FREE 또는 VALGRIND_FREELIKE_BLOCK에 대한 인수입니다.
캐시그라인드 옵션
--I1= , , 사이즈>
레벨 1 명령어 캐시의 크기, 연관성 및 라인 크기를 지정합니다.
--D1= , , 사이즈>
레벨 1 데이터 캐시의 크기, 연관성 및 라인 크기를 지정합니다.
--LL= , , 사이즈>
마지막 수준 캐시의 크기, 연관성 및 라인 크기를 지정합니다.
--cache-sim=아니요|예 [예]
캐시 액세스 및 누락 횟수 수집을 활성화하거나 비활성화합니다.
--branch-sim=아니요|예 [아니]
분기 명령 및 잘못된 예측 횟수 수집을 활성화하거나 비활성화합니다. 에 의해
기본적으로 이것은 Cachegrind가 약 25% 느려지므로 비활성화되어 있습니다. 참고
당신은 지정할 수 없습니다 --cache-sim=아니요 그리고 --분기심=아니오 함께, 떠나는 것처럼
수집할 정보가 없는 Cachegrind.
--cachegrind-아웃-파일=
프로필 데이터를 기본 출력 파일이 아닌 파일에 씁니다.
cachegrind.out. . 그만큼 %p 그리고 %q 형식 지정자를 사용하여 프로세스를 포함할 수 있습니다.
ID 및/또는 이름의 환경 변수 내용(예:
핵심 옵션 --로그 파일.
콜그라인드 옵션
--callgrind-out-파일=
프로필 데이터를 기본 출력 파일이 아닌 파일에 씁니다.
callgrind.out. . 그만큼 %p 그리고 %q 형식 지정자를 사용하여 프로세스를 포함할 수 있습니다.
ID 및/또는 이름의 환경 변수 내용(예:
핵심 옵션 --로그 파일. 여러 덤프가 만들어지면 파일 이름이 수정됩니다.
더 나아가; 아래를 참조하십시오.
--덤프 라인= [기본: 예]
이는 이벤트 카운팅이 소스 라인 세분성에서 수행되어야 함을 지정합니다.
이것은 디버그 정보로 컴파일된 소스에 대한 소스 주석을 허용합니다.
(-g).
--덤프-instr= [기본: 아니요]
이것은 이벤트 카운팅이 명령어 단위로 수행되어야 함을 지정합니다.
이렇게 하면 어셈블리 코드 주석이 가능합니다. 현재 결과는 표시만 가능합니다.
KCachegrind에 의해.
--압축 문자열= [기본: 예]
이 옵션은 프로필 데이터의 출력 형식에 영향을 줍니다. 여부를 지정합니다.
문자열(파일 및 함수 이름)은 숫자로 식별해야 합니다. 이것은 축소
파일을 읽을 수 있지만 사람이 읽기가 더 어렵습니다(어떤 경우에도 권장되지 않음).
케이스).
--압축 위치= [기본: 예]
이 옵션은 프로필 데이터의 출력 형식에 영향을 줍니다. 여부를 지정합니다.
숫자 위치는 항상 절대값으로 지정되거나
이전 숫자에 비해. 이렇게 하면 파일 크기가 줄어듭니다.
--결합 덤프= [기본: 아니요]
활성화되면 여러 프로필 데이터 부분이 생성될 때 이러한 부분은
동일한 출력 파일에 추가됩니다. 권장하지 않습니다.
--덤프마다-bb= [기본: 0, 절대]
프로필 데이터 덤프 주기 계산 기본 블록. 덤프가 필요한지 여부만 확인
Valgrind의 내부 스케줄러가 실행될 때. 따라서 유용한 최소 설정은
약 100000. 카운트는 긴 덤프 기간을 가능하게 하는 64비트 값입니다.
--덤프 이전=
입장시 덤핑 기능.
--제로 이전=
진입 시 모든 비용 제로 기능.
--덤프 후=
떠날 때 덤프 기능.
--instr-atstart= [기본: 예]
Callgrind가 처음부터 시뮬레이션 및 프로파일링을 시작하도록 할지 여부를 지정합니다.
프로그램. no로 설정하면 Callgrind는 어떠한 정보도 수집할 수 없습니다.
통화를 포함하지만 기껏해야 약 4의 속도 저하가 있을 것입니다.
Valgrind 오버 헤드. 계측은 callgrind_control을 통해 대화식으로 활성화할 수 있습니다.
-온.
결과 호출 그래프에는 아마도 다음이 포함되지 않을 것입니다. 본관,하지만
계측이 활성화된 후 실행된 모든 기능을 포함합니다. 수단
프로그래밍 방식으로 활성화/비활성화할 수도 있습니다. Callgrind 포함 파일 callgrind.h를 참조하십시오.
매크로의 경우 소스 코드에서 사용해야 합니다.
캐시 시뮬레이션의 경우 계측을 켤 때 결과가 덜 정확합니다.
나중에 프로그램 실행에서 시뮬레이터가 그 순간 빈 캐시로 시작하기 때문입니다.
이 오류에 대처하려면 나중에 이벤트 수집을 켜십시오.
--수집 시작= [기본: 예]
프로필 실행 시작 시 이벤트 수집을 활성화할지 여부를 지정합니다.
프로그램의 일부만 보려면 두 가지 가능성이 있습니다.
1. 프로파일링하려는 프로그램 부분을 입력하기 전에 이벤트 카운터를 XNUMX으로 만들고 덤프합니다.
해당 프로그램 부분을 떠난 후 파일에 대한 이벤트 카운터.
2. 발생하는 이벤트 카운터만 보기 위해 필요에 따라 수집 상태를 켜거나 끕니다.
프로파일링하려는 프로그램 부분 내부에 있는 동안.
프로파일링하려는 프로그램 부분이 many인 경우 두 번째 옵션을 사용할 수 있습니다.
타임스. 옵션 1, 즉 많은 덤프를 생성하는 것은 여기서 실용적이지 않습니다.
컬렉션 상태는 옵션을 사용하여 지정된 함수의 시작 및 종료 시 토글될 수 있습니다.
--토글-수집. 이 옵션을 사용하는 경우 수집 상태는
시작. 의 사양에 유의하십시오. --토글-수집 암시적으로 설정
--수집 상태=아니오.
클라이언트 요청을 삽입하여 수집 상태를 전환할 수도 있습니다.
CALLGRIND_TOGGLE_COLLECT ; 필요한 코드 위치에서.
--토글-수집=
입장/퇴장 시 수집 전환 기능.
--수집-점프= [기본: 아니요]
이것은 (조건부) 점프에 대한 정보를 수집해야 하는지 여부를 지정합니다. 처럼
위에서 callgrind_annotate는 현재 데이터를 표시할 수 없습니다. 당신은 사용해야합니다
주석이 달린 코드에서 점프 화살표를 얻기 위한 KCachegrind.
--수집-시스템시간= [기본: 아니요]
시스템 호출 시간에 대한 정보를 수집해야 하는지 여부를 지정합니다.
--수집-버스= [기본: 아니요]
실행된 전역 버스 이벤트의 수를 수집해야 하는지 여부를 지정합니다.
이러한 이벤트에는 이벤트 유형 "Ge"가 사용됩니다.
--캐시 시뮬레이션= [기본: 아니요]
전체 캐시 시뮬레이션을 수행할지 여부를 지정하십시오. 기본적으로 명령 읽기만
액세스가 계산됩니다("Ir"). 캐시 시뮬레이션을 사용하면 추가 이벤트 카운터가
활성화됨: 명령어 읽기("I1mr"/"ILmr"), 데이터 읽기 액세스("Dr")에서 캐시 누락
및 관련 캐시 미스("D1mr"/"DLmr"), 데이터 쓰기 액세스("Dw") 및 관련 캐시
미스("D1mw"/"DLmw"). 자세한 내용은 Cachegrind: 캐시 및 분기를 참조하세요.
예측 프로파일러.
--분기심= [기본: 아니요]
분기 예측 시뮬레이션을 수행할지 여부를 지정합니다. 추가 이벤트 카운터는
enabled: 실행된 조건부 분기 및 관련 예측자 누락 수
("Bc"/"Bcm"), 실행된 간접 점프 및 점프 주소 예측기의 관련 미스
("비"/"빔").
헬그린드 옵션
--free-is-write=아니요|예 [기본: 아니요]
활성화되면(기본값 아님) Helgrind는 힙 메모리 해제를 마치
메모리는 해제 직전에 기록되었습니다. 이것은 메모리가 있는 레이스를 노출합니다.
한 스레드에 의해 참조되고 다른 스레드에 의해 해제되지만 관찰할 수 있는 것은 없습니다.
동기화 이벤트는 참조가 무료 이전에 발생하도록 합니다.
이 기능은 Valgrind 3.7.0의 새로운 기능이며 실험적인 것으로 간주됩니다. 그것은
사용자 지정 메모리 할당자와의 상호 작용이 아니기 때문에 기본적으로 활성화되지 않습니다.
현재 잘 이해됨. 사용자 피드백을 환영합니다.
--track-lockorders=아니요|예 [기본: 예]
활성화되면(기본값) Helgrind는 잠금 순서 일관성 검사를 수행합니다. 을 위한
일부 버그가 있는 프로그램에서는 보고된 많은 수의 잠금 순서 오류가
특히 레이스 오류에만 관심이 있는 경우에는 더욱 그렇습니다. 따라서 귀하는
잠금 순서 확인을 비활성화하는 것이 도움이 된다는 것을 알았습니다.
--history-level=없음|대략|전체 [기본: 가득한]
--역사 수준=전체 (기본값) Helgrind가 다음에 대한 충분한 정보를 수집합니다.
경주 보고서에서 두 개의 스택 추적을 생성할 수 있는 "이전" 액세스 - 둘 다 스택
현재 액세스에 대한 추적 및 이전의 충돌 액세스에 대한 추적. 에게
메모리 사용 제한, "이전" 액세스 스택 추적은 최대 8개 항목으로 제한됩니다.
경우에도 --발신자 수 값이 더 큽니다.
이러한 정보를 수집하는 것은 속도와 메모리 모두에서 비용이 많이 듭니다.
많은 스레드 간 동기화 이벤트(잠금, 잠금 해제 등)를 수행하는 프로그램.
이러한 정보가 없으면 인종의 근본 원인을 추적하기가 더 어렵습니다.
그럼에도 불구하고 단지 확인하려는 상황에서는 필요하지 않을 수 있습니다.
예를 들어, 인종의 회귀 테스트를 수행할 때 인종의 존재 또는 부재
이전에 레이스 프리 프로그램.
--역사 수준=없음 그 반대의 극단이다. 그것은 Helgrind가 어떤 것도 수집하지 못하게 합니다.
이전 액세스에 대한 정보. 이것은 훨씬 더 빠를 수 있습니다.
--역사 수준=전체.
--역사 수준=대략 이 두 극단 사이의 절충안을 제공합니다. 그것은 원인
나중에 액세스할 수 있는 전체 추적 및 대략적인 정보를 표시하는 Helgrind
이전 액세스에 대해. 이 대략적인 정보는 두 개의 스택으로 구성되며,
이전 액세스는 프로그램 지점 사이 어딘가에서 발생한 것으로 보장됩니다.
두 개의 스택으로 표시됩니다. 이것은 다음에 대한 정확한 스택을 표시하는 것만큼 유용하지 않습니다.
이전 액세스( --역사 수준=전체 하지만 없는 것보다는 낫고,
거의 빠르다 --역사 수준=없음.
--충돌-캐시-크기=N [기본: 1000000]
이 플래그는 --역사 수준=전체.
"이전" 충돌 액세스에 대한 정보는 제한된 크기의 캐시에 저장됩니다.
LRU 스타일 관리. 저장하는 것이 실용적이지 않기 때문에 필요합니다.
프로그램이 만든 모든 단일 메모리 액세스에 대한 스택 추적. 역사 정보
최근에 액세스하지 않은 위치는 주기적으로 폐기되어
은닉처.
이 옵션은 서로 다른 메모리 수 측면에서 캐시 크기를 제어합니다.
충돌하는 액세스 정보가 저장된 주소. 당신이 그것을 찾으면
Helgrind는 예상되는 XNUMX개가 아닌 XNUMX개의 스택으로 레이스 오류를 표시합니다.
스택, 이 값을 증가시키십시오.
최소값은 10,000이고 최대값은 30,000,000입니다(기본값의 XNUMX배).
값). 값을 1씩 늘리면 Helgrind의 메모리 요구 사항이 매우 증가합니다.
대략 100바이트이므로 최대값은 XNUMXGB 정도를 쉽게 추가로 사용할 수 있습니다.
메모리의.
--check-stack-refs=아니요|예 [기본: 예]
기본적으로 Helgrind는 프로그램이 만든 모든 데이터 메모리 액세스를 확인합니다. 이 플래그
스레드 스택(로컬 변수)에 대한 액세스 확인을 건너뛸 수 있습니다. 이것은 할 수 있습니다
성능은 향상되지만 스택 할당 데이터에서 경쟁이 누락되는 비용이 발생합니다.
--스레드 생성 무시= [기본: 아니요]
스레드 생성 중 모든 활동을 무시할지 여부를 제어합니다. 기본적으로
Solaris에서만 활성화됩니다. Solaris는 더 높은 처리량, 병렬 처리 및
보다 세밀한 잠금 비용으로 다른 운영 체제보다 확장성
활동. 예를 들어 스레드가 glibc에서 생성될 때
큰 잠금은 모든 스레드 설정에 사용됩니다. Solaris libc는 여러 세분화된 잠금을 사용합니다.
생성자 스레드는 가능한 한 빨리 활동을 재개합니다. 예를 들어
스택 및 TLS 설정 시퀀스를 생성된 스레드로 전송합니다. 이 상황은 Helgrind를 혼란스럽게 합니다.
작성자와 생성자 사이에 잘못된 순서가 있다고 가정하기 때문에
실; 따라서 응용 프로그램의 많은 유형의 경합 조건은
보고했다. 이러한 잘못된 순서 지정을 방지하기 위해 이 명령줄 옵션은 다음에 의해 yes로 설정됩니다.
솔라리스에서는 기본값입니다. 따라서 모든 활동(로드, 저장, 클라이언트 요청)은 무시됩니다.
동안:
· 작성자 스레드에서 pthread_create() 호출
· 생성된 스레드에서 스레드 생성 단계(스택 및 TLS 설정)
또한 스레드 생성 중에 할당된 새 메모리는 추적되지 않습니다. 즉, 경주 보고입니다.
거기에서 억제된다. DRD는 암시적으로 동일한 작업을 수행합니다. 이것은 필요하기 때문에
Solaris libc는 많은 객체를 캐시하고 다른 스레드에 재사용하며
Helgrind를 혼란스럽게 합니다.
DRD 옵션
--체크-스택-var= [기본: 아니요]
DRD가 스택 변수에서 데이터 경합을 감지하는지 여부를 제어합니다. 스택 변수 확인
대부분의 프로그램은 스택 변수를 공유하지 않기 때문에 기본적으로 비활성화되어 있습니다.
스레드.
--독점 임계값= [기본: 끄다]
mutex 또는 writer 잠금이 시간보다 오래 유지된 경우 오류 메시지를 인쇄합니다.
밀리초 단위로 지정됩니다. 이 옵션을 사용하면 잠금 경합을 감지할 수 있습니다.
--가입-목록-볼륨= [기본: 10]
한 스레드의 끝에 있는 명령문과 다른 스레드 사이에서 발생하는 데이터 경합
스레드가 종료된 직후 메모리 액세스 정보를 폐기하면 누락될 수 있습니다.
가입되었습니다. 이 옵션을 사용하면 조인된 스레드 메모리 수를 지정할 수 있습니다.
액세스 정보를 유지해야 합니다.
--첫 레이스 전용= [기본: 아니요]
메모리 위치에서 감지된 첫 번째 데이터 경합만 보고할지 여부
또는 메모리 위치에서 감지된 모든 데이터 경합.
--무료 쓰기= [기본: 아니요]
메모리 액세스와 메모리 해제 간의 경합을 보고할지 여부입니다. 이것을 활성화
옵션을 선택하면 DRD가 약간 느리게 실행될 수 있습니다. 노트:
· 다음을 사용하는 사용자 정의 메모리 할당자를 사용할 때 이 옵션을 활성화하지 마십시오.
VG_USERREQ__MALLOCLIKE_BLOCK 및 VG_USERREQ__FREELIKE_BLOCK
잘못된 양성 결과가 나타납니다.
· 참조 횟수 개체를 사용할 때는 이 옵션을 활성화하지 마십시오.
해당 코드에
ANNOTATE_HAPPENS_BEFORE 및 ANNOTATE_HAPPENS_AFTER. 예를 들어 다음의 출력을 참조하십시오.
예를 들어 다음 명령: valgrind --tool=drd --free-is-write=yes
drd/tests/annotate_smart_pointer.drd/테스트/annotate_smart_pointer.
--보고-신호-잠금 해제= [기본: 예]
통화를 보고할지 여부 pthread_cond_signal 그리고 pthread_cond_broadcast 어디
를 통해 신호와 관련된 뮤텍스 pthread_cond_wait or
pthread_cond_timed_wait신호가 전송되는 시점에 잠기지 않습니다. 신호 보내기
관련된 뮤텍스에 대한 잠금을 유지하지 않는 것은 일반적인 프로그래밍 오류로,
미묘한 경합 상태와 예측할 수 없는 동작을 유발합니다. 흔하지 않은 부분이 있습니다
그러나 동기화 패턴을 유지하지 않고 신호를 보내는 것이 안전한 경우
관련된 뮤텍스를 잠급니다.
--세그먼트 병합= [기본: 예]
세그먼트 병합을 제어합니다. 세그먼트 병합은 세그먼트의 메모리 사용량을 제한하는 알고리즘입니다.
데이터 경합 감지 알고리즘. 세그먼트 병합을 비활성화하면 정확도가 향상될 수 있습니다.
레이스 보고서에 표시되는 소위 '기타 세그먼트'는 아웃을 유발할 수도 있습니다.
메모리 오류.
--세그먼트-병합-간격= [기본: 10]
지정된 수의 새 세그먼트가 완료된 후에만 세그먼트 병합을 수행합니다.
만들어진. 이것은 다음 여부를 선택할 수 있는 고급 구성 옵션입니다.
낮은 값을 선택하여 DRD의 메모리 사용량을 최소화하거나
약간 더 높은 값을 선택합니다. 이 매개변수의 최적 값은 다음에 따라 다릅니다.
분석 중인 프로그램. 기본값은 대부분의 프로그램에서 잘 작동합니다.
--공유 임계값= [기본: 끄다]
판독기 잠금이 지정된 시간보다 오래 유지된 경우 오류 메시지를 인쇄합니다.
(밀리초 단위). 이 옵션을 사용하면 잠금 경합을 감지할 수 있습니다.
--show-confl-세그= [기본: 예]
레이스 보고서에서 충돌하는 세그먼트를 표시합니다. 이 정보는 찾는 데 도움이 될 수 있으므로
데이터 경합의 원인인 경우 이 옵션은 기본적으로 활성화되어 있습니다. 이 옵션을 비활성화하면
DRD의 출력이 더 콤팩트합니다.
--show-stack-usage= [기본: 아니요]
스레드 종료 시간에 스택 사용량을 인쇄합니다. 프로그램이 많은 수를 생성할 때
스레드에 할당된 가상 메모리의 양을 제한하는 것이 중요해집니다.
스레드 스택. 이 옵션을 사용하면 얼마나 많은 스택 메모리가 사용되었는지 관찰할 수 있습니다.
클라이언트 프로그램의 각 스레드에서 사용됩니다. 참고: DRD 도구 자체가 일부를 할당합니다.
클라이언트 스레드 스택의 임시 데이터. 이 임시 데이터에 필요한 공간
스택 메모리를 할당할 때 클라이언트 프로그램에 의해 할당되어야 하지만
DRD에서 보고한 스택 사용량에 포함됩니다.
--스레드 생성 무시= [기본: 아니요]
스레드 생성 중 모든 활동을 무시할지 여부를 제어합니다. 기본적으로
Solaris에서만 활성화됩니다. Solaris는 더 높은 처리량, 병렬 처리 및
보다 세밀한 잠금 비용으로 다른 운영 체제보다 확장성
활동. 예를 들어 스레드가 glibc에서 생성될 때
큰 잠금은 모든 스레드 설정에 사용됩니다. Solaris libc는 여러 세분화된 잠금을 사용합니다.
생성자 스레드는 가능한 한 빨리 활동을 재개합니다. 예를 들어
스택 및 TLS 설정 시퀀스를 생성된 스레드로 전송합니다. 이 상황은 DRD를 혼란스럽게 합니다.
생성자와 생성된 스레드 사이에 잘못된 순서가 있다고 가정합니다. 그리고
따라서 응용 프로그램의 많은 유형의 경쟁 조건이 보고되지 않습니다. 에게
이러한 잘못된 순서 지정을 방지하려면 이 명령줄 옵션은 기본적으로 yes로 설정됩니다.
솔라리스. 따라서 모든 활동(로드, 저장, 클라이언트 요청)은 다음 동안 무시됩니다.
· 작성자 스레드에서 pthread_create() 호출
· 생성된 스레드에서 스레드 생성 단계(스택 및 TLS 설정)
--추적 주소= [기본: 없음]
지정된 주소에 대한 모든 로드 및 저장 활동을 추적하십시오. 이 옵션은
두 번 이상 지정됩니다.
--ptrace-추가 = [기본: 없음]
지정된 주소에 대한 모든 로드 및 저장 활동을 추적하고 계속 수행합니다.
해당 주소의 메모리가 해제되고 재할당된 후.
--추적 할당= [기본: 아니요]
모든 메모리 할당 및 할당 해제를 추적합니다. 엄청난 양의 출력을 생성할 수 있습니다.
--트레이스-장벽= [기본: 아니요]
모든 장벽 활동을 추적합니다.
--추적 조건= [기본: 아니요]
모든 조건 변수 활동을 추적합니다.
--트레이스-포크-조인= [기본: 아니요]
모든 스레드 생성 및 모든 스레드 종료 이벤트를 추적합니다.
--추적-hb= [기본: 아니요]
ANNOTATE_HAPPENS_BEFORE(), ANNOTATE_HAPPENS_AFTER() 및
ANNOTATE_HAPPENS_DONE() 클라이언트 요청.
--추적-뮤텍스= [기본: 아니요]
모든 뮤텍스 활동을 추적합니다.
--추적-rwlock= [기본: 아니요]
모든 판독기-작성기 잠금 활동을 추적합니다.
--트레이스-세마포어= [기본: 아니요]
모든 세마포어 활동을 추적합니다.
마시프 옵션
--힙= [기본: 예]
힙 프로파일링을 수행해야 하는지 여부를 지정합니다.
--힙-관리자= [기본: 8]
힙 프로파일링이 활성화된 경우 블록당 관리 바이트 수를
사용. 다를 수 있으므로 평균값이어야 합니다. 예를 들어,
Linux에서 glibc가 사용하는 할당자는 블록당 4~15바이트가 필요합니다.
다양한 요인에 따라. 해당 할당자는 해제를 위한 관리 공간도 필요합니다.
하지만 Massif는 이를 설명할 수 없습니다.
--스택= [기본: 아니요]
스택 프로파일링을 수행해야 하는지 여부를 지정합니다. 이 옵션은 Massif를 느리게 합니다.
기본적으로 해제되어 있습니다. Massif는 메인 스택이
시작 시 크기 XNUMX. 이것은 사실이 아니지만 그렇지 않으면 정확하게 수행하기가 어렵습니다.
또한 XNUMX에서 시작하는 것이 메인 스택 부분의 크기를 더 잘 나타냅니다.
사용자 프로그램이 실제로 제어할 수 있습니다.
--힙으로서의 페이지= [기본: 아니요]
Massif에게 malloc'd 블록이 아닌 페이지 수준에서 메모리를 프로파일링하도록 지시합니다.
수준. 자세한 내용은 위를 참조하십시오.
--깊이= [기본: 30]
세부 스냅샷에 대해 기록된 할당 트리의 최대 깊이입니다. 그것을 증가
Massif를 다소 느리게 실행하고 더 많은 메모리를 사용하며 더 큰 출력을 생성합니다.
파일.
--할당-fn=
이 옵션으로 지정된 함수는 힙인 것처럼 처리됩니다.
와 같은 할당 기능 Malloc. 이는 래퍼 역할을 하는 함수에 유용합니다.
Malloc or , 흥미롭지 않은 정보로 할당 트리를 채울 수 있습니다.
이 옵션은 여러 이름을 지정하기 위해 명령줄에서 여러 번 지정할 수 있습니다.
기능.
명명된 함수는 최상위 항목인 경우에만 이러한 방식으로 처리됩니다.
스택 추적 또는 다른 함수 바로 아래에서 이 방식으로 처리됩니다. 예를 들어 다음과 같은 경우
기능 malloc1 감싸는 Malloc및 malloc2 감싸는 malloc1, 그냥 지정
--alloc-fn=malloc2 효과가 없습니다. 당신은 지정해야합니다 --alloc-fn=malloc1 as
잘. 조금 불편하긴 한데 그 이유는 할당 확인이
기능이 느리고 Massif가
일치하지 않는 항목을 발견하는 즉시 스택 추적 항목을
모든 항목을 통해 계속하십시오.
C++ 이름은 디글글링됩니다. 또한 오버로드된 C++ 이름은 작성해야 합니다.
전부. 셸에서 작은따옴표가 깨지는 것을 방지하기 위해 작은따옴표가 필요할 수 있습니다.
예 :
--alloc-fn='연산자 new(unsigned, std::nothrow_t const&)'
--무시-fn=
직접 힙 할당(예: Malloc, 등 또는 함수 호출
에 의해 명명된 --alloc-fn 옵션)은 이 옵션으로 지정된 함수에서 발생합니다.
무시하십시오. 이것은 주로 테스트 목적으로 유용합니다. 이 옵션은 지정할 수 있습니다
여러 기능의 이름을 지정하기 위해 명령줄에서 여러 번
모든 품종 리얼록 무시된 블록의 경우에도 무시됩니다. 리얼록 전화가
무시된 함수에서는 발생하지 않습니다. 이는 힙 크기가 음수일 가능성을 방지합니다.
무시된 블록이 축소된 경우 리얼록.
C++ 함수 이름 작성 규칙은 다음과 동일합니다. --alloc-fn 위.
--임계값= [기본: 1.0]
총 메모리 크기의 백분율로 표시되는 힙 할당의 중요도 임계값입니다.
이보다 적은 할당 트리 항목이 집계됩니다. 참고
이것은 동일한 이름의 ms_print 옵션과 함께 지정해야 합니다.
--피크 부정확성= [기본: 1.0]
Massif는 반드시 실제 글로벌 메모리 할당 피크를 기록하지는 않습니다. ~에 의해
기본적으로 전역 메모리 할당 크기가 최대값을 초과할 때만 피크를 기록합니다.
최소 1.0% 이전 피크. 지역 할당이 많을 수 있기 때문입니다.
도중에 최고점에 도달하고 모든 정점에 대한 자세한 스냅샷을 수행하는 데 비용이 많이 듭니다.
그 중 하나를 제외하고 모두 나중에 폐기되기 때문에 낭비입니다. 이 부정확성은 다음과 같을 수 있습니다.
이 옵션을 통해 변경(심지어 0.0%까지)하지만 Massif는
숫자는 XNUMX에 가까워집니다.
--시간-단위= [기본: i]
프로파일링에 사용되는 시간 단위입니다. 세 가지 가능성이 있습니다: 지침
실행 (i), 대부분의 경우에 적합합니다. 실제(벽시계) 시간(ms, 즉
밀리초), 때로는 유용합니다. 및 힙에 할당/할당 취소된 바이트
및/또는 스택(B), 매우 단기 실행 프로그램 및 테스트에 유용
다른 기계에서 가장 재현 가능하기 때문입니다.
--상세-주파수= [기본: 10]
자세한 스냅샷의 빈도. 와 함께 --상세-주파수=1, 모든 스냅샷이 상세합니다.
--최대-스냅샷= [기본: 100]
기록된 스냅샷의 최대 수입니다. N으로 설정하면 very를 제외한 모든 프로그램에 대해
짧은 실행 스냅샷의 경우 최종 스냅샷 수는 N/2에서 N 사이입니다.
--massif-아웃-파일= [기본: 대산괴.아웃.%p]
프로필 데이터를 기본 출력 파일이 아닌 파일에 씁니다.
대산괴. . 그만큼 %p 그리고 %q 형식 지정자를 사용하여 프로세스 ID를 포함할 수 있습니다.
및/또는 이름에 있는 환경 변수의 내용(예:
핵심 옵션 --로그 파일.
SGCHECK 옵션
현재 SGCheck 관련 명령줄 옵션은 없습니다.
BBV 옵션
--bb-아웃-파일= [기본: bb.out.%p]
이 옵션은 기본 블록 벡터 파일의 이름을 선택합니다. 그만큼 %p 그리고 %q 체재
지정자는 프로세스 ID 및/또는 환경의 내용을 포함하는 데 사용할 수 있습니다.
핵심 옵션의 경우와 같이 이름의 변수 --로그 파일.
--pc-출력-파일= [기본: pc.out.%p]
이 옵션은 PC 파일의 이름을 선택합니다. 이 파일에는 프로그램 카운터 주소가 들어 있습니다.
다양한 기본 블록에 대한 기능 이름 정보. 이것은 함께 사용할 수 있습니다
기본 블록 벡터 파일을 사용하여
명령이 중요합니다. 그만큼 %p 그리고 %q 형식 지정자를 사용하여 프로세스를 포함할 수 있습니다.
ID 및/또는 이름의 환경 변수 내용(예:
핵심 옵션 --로그 파일.
--간격-크기= [기본: 100000000]
이 옵션은 사용할 간격의 크기를 선택합니다. 기본값은 100억입니다.
일반적으로 사용되는 값입니다. 다른 크기를 사용할 수 있습니다. 더 작은
간격은 보다 세분화된 단계로 프로그램을 도울 수 있습니다. 그러나 더 작은 간격 크기
워밍업 효과로 인해 정확도 문제가 발생할 수 있습니다(다양한
아키텍처 기능은 초기화되지 않으며 몇 번의 작업이 필요합니다.
전체 시뮬레이션이 없는 상태로 "워밍업"하기 전에 지침
빨리 감기. 큰 간격 크기는 이를 완화하는 경향이 있습니다.)
--instr-count-only [기본: 아니요]
이 옵션은 도구에 명령 수 총계만 표시하고 표시하지 않도록 지시합니다.
실제 기본 블록 벡터 파일을 생성합니다. 이는 디버깅에 유용하며
큰 기본 블록 벡터를 생성하지 않고 명령어 카운트 정보 수집
파일.
하인 옵션
--기본-카운트= [기본: 예]
활성화되면 Lackey는 다음에 대한 다음 통계 및 정보를 인쇄합니다.
클라이언트 프로그램 실행:
1. 에서 지정한 함수 호출 횟수 --fn이름 옵션(기본값
메인)입니다. 프로그램에서 기호가 제거된 경우 개수는 항상
제로.
2. 만난 조건 분기의 수와 분기의 수와 비율
찍은 것.
3. 프로그램이 입력하고 완료한 수퍼블록의 수. 인해
JIT에서 수행한 최적화이므로 정확한 값이 아닙니다.
4. 게스트 수(x86, amd64, ppc 등) 명령어 및 IR 문
실행. IR은 Valgrind의 RISC와 같은 중간 표현입니다.
계측이 이루어집니다.
5. 이러한 계수 중 일부 사이의 비율.
6. 클라이언트 프로그램의 종료 코드.
--상세-카운트= [기본: 아니요]
활성화되면 Lackey는 로드, 저장 및 ALU 수를 포함하는 테이블을 인쇄합니다.
IR 유형으로 구분되는 운영. IR 유형은 IR로 식별됩니다.
이름("I1", "I8", ... "I128", "F32", "F64" 및 "V128").
--추적 메모리= [기본: 아니요]
활성화되면 Lackey는 거의 모든 메모리 액세스의 크기와 주소를 인쇄합니다.
프로그램. 자세한 내용은 lactey/lk_main.c 파일 상단의 주석을 참조하십시오.
출력 형식, 작동 방식 및 주소 추적의 부정확성에 대해 설명합니다. 메모
이 옵션은 엄청난 양의 출력을 생성합니다.
--추적-슈퍼블록= [기본: 아니요]
활성화되면 Lackey는 모든 수퍼블록의 주소를 출력합니다(단일 항목,
다중 종료, 코드의 선형 청크) 프로그램에 의해 실행됩니다. 이는 주로
Valgrind 개발자에 대한 관심. 파일 상단의 주석을 참조하십시오.
출력 형식에 대한 자세한 내용은 lactey/lk_main.c를 참조하십시오. 이 옵션은
많은 양의 출력.
--fnname= [기본: 기본]
다음과 같은 경우 통화가 계산되는 기능을 변경합니다. --기본-카운트=예 이 지정됩니다.
onworks.net 서비스를 사용하여 온라인에서 valgrind 사용
