[super didReceiveMemoryWarning]을 (를) 호출하려고 할 때 오류가 발생했습니다

Question

재현 할 수없는 크래시 보고서를 수집 한 앱이 있습니다. 자체 메모리 경고를 처리 할 때 간단히 [super didReceiveMemoryWarning]을 호출하는 뷰 컨트롤러가 있습니다 (예,이 작업을 수행 할 필요는 없지만 현재 문제가있는 것은 아닙니다). 그것은 여기

와 충돌 purgeMemoryForReason을 호출하려고 UIViewController에 부모가 관련 추적 정보되면 :

Exception Type: SIGSEGV 
Exception Codes: SEGV_ACCERR at 0x90000008 
Crashed Thread: 0 

Thread 0 Crashed: 
0 libobjc.A.dylib      0x361dbf78 objc_msgSend + 16 
1 UIKit        0x31fbf499 -[UIViewController purgeMemoryForReason:] + 65 
2 MyApp        0x00016f0d -[AttributesViewController didReceiveMemoryWarning] (AttributesViewController.m:76) 
3 Foundation       0x30c5b4ff __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 19 
4 CoreFoundation      0x34d86547 ___CFXNotificationPost_block_invoke_0 + 71 
5 CoreFoundation      0x34d12097 _CFXNotificationPost + 1407 
6 Foundation       0x30bcf3eb -[NSNotificationCenter postNotificationName:object:userInfo:] + 67 
7 Foundation       0x30bd0c1b -[NSNotificationCenter postNotificationName:object:] + 31 
8 UIKit        0x31f8a271 -[UIApplication _performMemoryWarning] + 81 
9 UIKit        0x31f8a36b -[UIApplication _receivedMemoryNotification] + 175 
10 libdispatch.dylib     0x30de42e1 _dispatch_source_invoke + 517 
11 libdispatch.dylib     0x30de1b81 _dispatch_queue_invoke$VARIANT$mp + 53 
12 libdispatch.dylib     0x30de1ec1 _dispatch_main_queue_callback_4CF$VARIANT$mp + 157 
13 CoreFoundation      0x34d8d2ad __CFRunLoopRun + 1269 
14 CoreFoundation      0x34d104a5 CFRunLoopRunSpecific + 301 
15 CoreFoundation      0x34d1036d CFRunLoopRunInMode + 105 
16 GraphicsServices     0x3600c439 GSEventRunModal + 137 
17 UIKit        0x31e06e7d UIApplicationMain + 1081 
18 MyApp        0x0000243b main (main.m:15) 

나는 메모리가에 경고 트리거 횟수 내가 상관없이 오류를 재현 없지만, 수 있으면 좋겠다 내 테스트 장치 또는 시뮬레이터 나는 이것이 일어날 수 없습니다. 잠재적 인 문제를 지적한 정보를 찾지 못해서 내가 찾은 결과에 대한 도움을 주시면 감사하겠습니다. 감사!

편집 : 내가 언급 한 바와 같이, 내가 didReceiveMemoryWarning에 아무것도 아니에요 :

- (void) didReceiveMemoryWarning 
{ 
    [super didReceiveMemoryWarning]; 
} 

예, 나는이 작업을 수행 할 필요가 없습니다 알고있다. 나는이 코드를 제거 할 계획을 가지고있다. (나는 아직도 왜 그 코드가 들어 있는지 알지 못한다.) 그러나 나는 문제의 근원을 고쳐야한다. 나는 viewDidUnload을 AttributesViewController에 포함시키지 않았습니다. 나는 ARC를 사용하고 있다고 언급 했어야했는데, 여기에 문제가 있는지 없는지 확실하지 않다.

피드백을 받았기 때문에 카메라를 사용할 때 메모리 경고가 발생합니다 (소스 유형이 UIImagePickerControllerSourceTypeCamera 인 UIImagePickerController). AttributesViewController은 UIImagePickerController을 나타내는보기 컨트롤러보다 2 단계 위의보기 컨트롤러에 의해 모달로 표시되며 개체 나 다른 데이터를 공유하지 않습니다. 나는 카메라가 자주 메모리 경고를 일으킨다는 것을 안다. 따라서 UIImagePickerController이 메모리 hog라는 사실 이외의 어떤 식 으로든 관련이 있는지 확실하지 않다.

나는 항상 분석기를 실행하도록 Xcode를 설정 했으므로 문제가 발생하지 않았습니다. 또한 Zombies and Leaks 도구를 통해 코드를 실행했으며 문제를 재현하거나 다른 문제를 찾을 수 없었습니다.

Answer 1

didReceiveMemoryWarning에서 무엇을하고 있습니까? 기억을 풀어 주시겠습니까? 보기 닫기? 뭐? 우편 번호! [나는 당신이 조금 더 많은 코드를 게시 한 것을 본다. 감사합니다.]

그렇지 않은 경우 didReceiveMemoryWarning의 원인이되는 문제가 해결되지 않으므로 향후 더 많은 메모리 할당 시도 (예 : 새 개체 할당)가 실패하기 시작할 수 있습니다. 따라서 해당 객체에 종속 된 코드는 모두 실패합니다. 귀하의 코드가 실제로 새로운 값을 할당 한 모든 시간의 반환 값을 실제로 확인하고 있습니까?

더 중요한 것은 이러한 메모리 경고를받는 이유를 확인 했습니까? 물론 메모리 부족 상황을 적절히 처리하는 것이 중요하지만, 인간이 가능하다면 예방하는 것이 중요합니다. 분석기 (명령 + 시프트 + B)를 통해 코드를 실행 했습니까? 누수의 원인을 확인하기 위해 앱 (명령 +)을 프로파일 링 했습니까?

업데이트 : 귀하의 해명을 공유하기위한

감사합니다.솔직히, 나는 아이디어를 짧은 실행,하지만 몇 가지 더 생각 해요 :

1. 문제를 재현 할 수없는 때 (훨씬 적은 수정) 진단하기 힘듭니다. 정말 우선 순위 인 것 같습니다. iPhone 4 또는 4S에서 테스트 중이라면 512MB DRAM을 즐기고 있지만 3G에는 256MB 만 있고 3GB에는 128MB가 있습니다. 최신 기기에서 테스트하고 있습니까? 사용자가 less capable devices 일 수 있습니까? 또는 유사하게 장착 된 장치의 충돌 로그입니까? 기기 설정에 따라 다른 시간에 didReceiveMemoryWarning을받는 것처럼 보이므로 사용자가 볼 수있는 충돌을보다 분명하게 나타낼 수 있습니다.

2. 왜 앱이 충돌하고 있습니까? didReceiveMemoryWarning에서 계속 작업을 수행 할 수있는 충분한 메모리를 확보 할 수 없으므로 (즉, 필요한 객체가 이후에 alloc 개 필요합니다) 줄 수 있지만 충돌 로그에 표시되지는 않습니다. 로그를 통해 Key Value Observing 또는 NSNotificationCenter 로직을 수행하고 있는지 궁금합니다. 관찰자를 제거하지 않고도 관찰 된 물체가 문제가 된 것을 상상할 수 있기 때문에 물어 봅니다. 내가 addObserver:selector:name:object: 참조를 보았고, 코코아가 백그라운드에서했는지 또는 앱이 자체적으로 수행하고 있는지 여부를 알지 못하기 때문에 요청합니다. (그리고 그것은 관련이 없을 수 있습니다.) 모든 충돌 로그는 유사한 호출 스택을 보여줍니까?

3. 일반적으로 앱이 다양한 포인터가 nil이 아닌지 확인합니까? 다시 말하지만 약간 다른 충돌 로그가 나올 것으로 예상되지만, purgeMemoryForReason이 무언가를 당신에게 공개하지 않았는지 확인하기 위해 무심코 검사하는 것이 신중할 것 같습니다.

4. 또 다른 유일한 제안은 귀하의 모든 didReceiveMemoryWarning과 viewDidUnload가 메모리 경고의 영향을 최소화하기 위해 할 수있는 모든 것을 공개하는지 확인하여 앱이이 낮은 메모리 상황에서도 견딜 수 있도록 보장하는 것입니다. didReceiveMemoryWarning 표준이 활성화되지 않은보기를 언로드하려고 시도하는 것처럼 보입니다. 따라서보기가 정상적으로 메모리를 정리하고 있는지 확인하고 싶을 것입니다. Managing Your Memory Efficiently에 따르면 viewDidUnload 또는 didReceiveMemoryWarning에보기의 물체를 확보해야합니다.

죄송합니다. 건설적인 제안이 없습니다. 잘만되면 다른 누군가가 더 좋은 아이디어를 나눌 수 있기를 바랍니다.