전형적인 케이스 차원 계측 분석 1-- 메모리 누수
시스템 동작 동안에, 메모리 누출이 더 일반적이지만, 각 바이트 수십 종종 측정 된 압력의 문제를 재현하기 위해 긴 시간을 필요 누수 유출 더 미묘한 일반 메모리의 현상을 재현하기 어려운 . 이 섹션에서는 문제 밖으로 압력 시험에서 가지고 사례를 제공하며 차원 계측 툴의 사용을 통해, 메모리 누출을 확인 분석.
1. 설명 :
XX 압력 측정 인터넷 488번째 통로를 연결하는 현상 AP 반복 덤프 기계 전력을
**
재현하기위한 2 단계 :
- 기기 인증에 접속되고, 온라인 상태를 유지 (유지 하트)
B .. 네트워크에서 안정된 연결을 끊기 (AP 오프 전력) 후
C 0.5 분 전력 회수 AP의 후
D. 장치 측 판정 온라인 장치가 있는지 로그인
문제 3. 예비 분석
압력 및 라우터 장치의 측정 과정없이 서비스 보낸 동작 사이클 재접속없이 리안 오프이다. 이 부분은 공급 업체 와이파이 드라이버 라이브러리를 호출합니다.
로그보기 문제의 관점에서 시스템 고장이 발생하고, 다음과 같이 존재는, 인쇄에 충분한 메모리의 전형적인되었습니다
(이것은 우리이다 로그인 시스템의 하나의 차원 측정 장치 측의 능력 , 메모리 사용량, 메모리 에러가 발생할 때 쉬운 위치에 대한 모든 출력) 
시스템 메모리 풀의 동적 메모리를 mallo 불충분 메모리로 인해, 이러한 현상의 이유는 일반적으로 두 가지 :
- A A 큰 메모리 할당의 지속적인 동작 부품 및 해제되지 않았다. 이 상황은 어렵다
- 메모리 누수 측정 된 압력의 설명에 따라 측정 된 압력은 슬로우 리크가 발생했습니다 며칠 동안 나타났다.
이 예비 분석, 우리는 시작할 것이다 PC의 차원 측정 도구 , 끝을 구문 분석 장치 로그에 나타납니다 가치있는 정보를 확인할 수 있습니다. 다른 문서에서 설명에 참여하는 차원 측정 장치를 사용합니다. 바로 여기
python core_dump.py log xx.elf차원 계측 툴은 이전 로그 메모리도 누수시 아래와 같이 통계 시스템 메모리 사용을 인쇄하는 장치의 출력단을 파싱 :
큰 순서 작은 메모리 할당 크기로 배치 된 모든 동적 메모리 할당 시스템 충돌 통계 여기 횟수, 각 행은 메모리 애플리케이션에인가되는 어드레스로부터 애플리케이션의 크기 malloc은 메모리를 포함 크기, 위치 및 한 눈에, 신청자의 코드 등을 포함 할 수있다.
우리는 마지막 줄의 그림에서 보면 특이점을 발견 (즉, 시스템 메모리의 구성 요소의 대부분을 차지하고있다) : 시스템이 여전히 982 타이머가가, 70K + 시스템 메모리를 점유 할 때 , 이것은 확실히 문제입니다!
4. 빠른 반복되는 문제
빠른 위치 버그 문제가 매우 중요한 단계입니다 재현.
압력 측정 과정은 라우터 5 분 간격으로 떨어져있는 바와 같이, 장시간 동안, 우리는이 현상을 재현 테스트 케이스의 구조를 재생하려고. 이전 분석에서, 압력 측정 과정은 와이파이 드라이브 제조업체 만 관련이있다. 우리는이 과정을 시뮬레이션하기 위해 두 개의 공통 인터페이스 발견
hal_wifi_suspend_station ---- 라우터 분리 작업을, 기본 공급 업체 연결 해제 와이파이 호출
netmgr_reconnect_wifi을 ---- 작동 할 수있는 라우터를 연결, 제조업체들은 연결하는 와이파이의 바닥을 호출합니다
우리는 다음과 같이 테스트 케이스 코드가 구축했습니다 :
while (1) {
krhino_mm_overview(NULL); /*重点关注这一行*/
aos_msleep(5000);
hal_wifi_suspend_station(NULL);
netmgr_reconnect_wifi();
}즉 : 시스템 전원에 필요한 네트워크 초기화, 사이클 5 초 일시 중단 순환 압력 측정을 시작하고 다시 연결 한 후
while 루프의 첫 번째 줄에 있습니다 :
krhino_mm_overview(NULL);이 인터페이스는 외부 API 디버깅 인터페이스의 한 차원 측정 , 관련 통계의 인쇄 힙.
이러한 인터페이스는 책 출판과 치수 측정 디버깅 API 인터페이스를 신속하게 문제를 찾을 수 있습니다 자주, 디버그 시간의 중요한 수단입니다
참조 https://yuque.antfin-inc.com/aliosthings/mr5i1t/wupvbn#994230b2
이 인터페이스는 (예를 들어) 아래에 도시되어 인쇄 :
========== Heap Info ==========
-----------------------------------------------------------
[HEAP]| TotalSz | FreeSz | UsedSz | MinFreeSz |
| 0x0004A838 | 0x00047E50 | 0x000029E8 | 0x00047E50 |
-----------------------------------------------------------
[POOL]| PoolSz | FreeSz | UsedSz | BlkSz |
| 0x00002000 | 0x00001E00 | 0x00000200 | 0x00000020 |
-----------------------------------------------------------상부 통계는 두 부분, 힙 POOL 나누어. 힙이 전체 통계입니다 POOL 힙의 일부입니다.
풀 HEAP과 차이가있을 때 사용자가 그
aos_malloc(size)시간이 크기 미만 32 바이트합니다 (k_config.h 항에 RHINO_CONFIG_MM_BLK_SIZE는 매크로에 의해 지정된) malloc이 메모리의 32 바이트가 POOL에 고정한다 할당이면, 메모리를 할당 달리 힙 메모리의 사용자 정의 된 크기를 할당한다.
HEAP 내용의 의미 :
- TotalSz, 힙의 전체 크기.
- FreeSz, 유휴 현재 힙 크기.
- UsedSz 힙의 전류량, 즉 UsedSz = TotalSz - FreeSz.
- MinFreeSz, 역사의 최소 여유 힙, 즉 TotalSz - 역사의 MinFreeSz 힙은 최대 사용합니다.
이상이이 정보를 사용할 수 있습니다 때 크게 부족한 메모리 힙의 유휴 문제가 발생할지 여부를 결정합니다.
돌아 가기 질문에, 테스트 케이스 후 실행 그림과 같이 네트워크 연결 후 시스템 메모리 사용량의 출력의 각주기 :
5. 위치 문제
가시 기반 메모리 시스템을 정지하고, 각각 연결하면 감소되고 소형화가 고정된다. 연결은 메모리 풀 누수의 결과로, 여유가 없을 때의 경우를 중단하는 것은 더 빨리 발생하거나 나중에 메모리가 부족할 때 이러한 상황은 안정적인 메모리 누수가 발생 제조 업체 WIFI 드라이브가 malloc에 메모리입니다.
초기 로그, 시스템 crach 시간 (그것은 메모리가 부족할 때)에서 982 시스템 타이머가 해제되지 않고있다, 그래서 우리는 타이머의 사용에 초점을 맞 춥니 다. 제조 업체는 (문제가 매우 고통스러운 때마다 한 위치의 원인 인) 소스 코드를 제공하지 않기 때문에, 위 인쇄 디버깅 코드에 직접 추가 할 수 없습니다. 다음과 같이 플러스 인쇄 커널 타이머, 결과는 다음과 같습니다
연결 :
매달다, 중지하다, 뜨게하다:
당신은 연결시 타이머가 다섯 번 만들어 볼 수 있지만 일시 중단 할 때 만 네 번을 삭제 매우 명확 수 있습니다!
여기에 문제를 찾으려면 문제가 명확하게 근본 원인이있다 : 타이머 조금 놓습니다. 제조사에 피드백 한 후, 신속하게 해결.
6. 요약
여기 AliOS 것들 차원 측정 기능의 여러 측면과 함께 :
- 종단 도킹 장치 메모리 예외 처리, 첫 충돌 지점 중 인쇄
- PC 측 치수 측정 도구는 충돌 로그 해석 장치의 끝, 임계치를 감소
- 이 API 인터페이스를 사용하여 치수 측정,이 책은 디버그 도구에서 수행된다.