내 모든 테스트 컴퓨터에서 매우 안정적이고 거의 모든 사용자에게 안정적인 것처럼 보이는 다중 스레드 앱이 있습니다 (충돌에 대한 불만 사항 없음). 하지만 앱은 충돌 보고서를 보낼만큼 친절했던 한 사용자에게 자주 충돌합니다. 모든 충돌 보고서 (~ 10 개의 연속 보고서)는 본질적으로 동일하게 보입니다.
Date/Time: 2010-04-06 11:44:56.106 -0700
OS Version: Mac OS X 10.6.3 (10D573)
Report Version: 6
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x90ab98d4 __CFBasicHashRehash + 3348
1 com.apple.CoreFoundation 0x90adf610 CFBasicHashRemoveValue + 1264
2 com.apple.CoreText 0x94e0069c TCFMutableSet::Intersect(__CFSet const*) const + 126
3 com.apple.CoreText 0x94dfe465 TDescriptorSource::CopyMandatoryMatchableRequest(__CFDictionary const*, __CFSet const*) + 115
4 com.apple.CoreText 0x94dfdda6 TDescriptorSource::CopyDescriptorsForRequest(__CFDictionary const*, __CFSet const*, long (*)(void const*, void const*, void*), void*, unsigned long) const + 40
5 com.apple.CoreText 0x94e00377 TDescriptor::CreateMatchingDescriptors(__CFSet const*, unsigned long) const + 135
6 com.apple.AppKit 0x961f5952 __NSFontFactoryWithName + 904
7 com.apple.AppKit 0x961f54f0 +[NSFont fontWithName:size:] + 39
(…. 더 많은 텍스트가 이어집니다)
먼저 [NSFont fontWithName : size :]를 조사하는 데 오랜 시간을 보냈습니다. 나는 사용자의 글꼴이 어떻게 든 망가 져서 [NSFont fontWithName : size :]가 존재하지 않는 것을 요청하고 그 이유로 실패 할 것이라고 생각했습니다. 글꼴 가용성을 미리 확인하기 위해 [[NSFontManager sharedFontManager] availableFontNamesWithTraits : NSItalicFontMask]를 사용하여 코드를 추가했습니다. 안타깝게도 이러한 변경으로 문제가 해결되지 않았습니다.
이제 _NSLockError, [NSException raise] 및 objc_exception_throw를 포함하여 일부 디버깅 중단 점을 제거하는 것을 잊었습니다. 그러나 앱은 활성 빌드 구성으로 “Release”를 사용하여 확실히 빌드되었습니다. “Release”구성을 사용하면 중단 점 설정이 방지된다고 가정합니다. 그러나 중단 점이 어떻게 작동하는지 또는 중단 점이 효과를 내기 위해 프로그램이 gdb 내에서 실행되어야하는지 정확히 알 수 없습니다.
내 질문은 다음과 같습니다. 중단 점을 설정 한 것이 사용자가 관찰 한 충돌의 원인이 될 수 있습니까? 그렇다면 중단 점이이 한 사용자에게만 문제를 일으키는 이유는 무엇입니까? 그렇지 않다면 다른 사람이 [NSFont fontWithName : size :]와 유사한 문제를 겪고 있습니까?
아마도 중단 점을 제거하고 사용자에게 다시 보내려고 할 것입니다. 그러나 해당 사용자에게 얼마나 많은 통화가 남아 있는지 잘 모르겠습니다. 중단 점을 설정 한 채로두면 문제가 발생할 수 있는지 더 일반적으로 이해하고 싶습니다 (앱이 “Release”구성을 사용하여 빌드 된 경우).
답변
“EXC_BREAKPOINT (SIGTRAP)”예외가 중단 점 디버깅으로 인해 발생합니까?
그렇지 않습니다. 실제로는 SIGTRAP (트레이스 트랩)를 사용하면 실제 중단 점과 동일한 방식으로 디버거가 프로그램을 중단 (중단) 할 수 있습니다. 그러나 이는 디버거가 항상 충돌시 중단되기 때문이며 SIGTRAP (다른 여러 신호 와 마찬가지로 )는 충돌 유형 중 하나입니다.
SIGTRAPs은 일반적으로 NSExceptions에 의해 발생 던져지는, 그러나 항상 직접적 심지어 가능 인상 하나를 자신을.
이제 _NSLockError, [NSException raise] 및 objc_exception_throw를 포함하여 일부 디버깅 중단 점을 제거하는 것을 잊었습니다.
그것들은 중단 점이 아닙니다. 그 중 두 가지는 기능이고 -[NSException raise]방법입니다.
그 함수와 그 방법 에 중단 점 을 설정 했나요 ?
“Release”구성을 사용하면 중단 점 설정이 방지된다고 가정합니다.
아니.
구성은 빌드 구성입니다. Xcode가 애플리케이션을 빌드하는 방법에 영향을줍니다.
중단 점은 빌드의 일부가 아닙니다. 디버거에서 설정합니다. 그들은 단지 존재하고, 히트를 받고, 디버거에서 프로그램을 실행할 때만 프로그램을 중지합니다.
빌드의 일부가 아니기 때문에 단순히 앱 번들을 제공하는 것만으로는 중단 점을 사용자에게 전달할 수 없습니다.
중단 점이 어떻게 작동하는지 정확히 모르겠습니다…
프로그램이 중단 점에 도달하면 디버거가 프로그램을 중단 (중단)합니다. 그러면 프로그램의 상태를 검사하고 프로그램이 어떻게 잘못되었는지주의 깊게 살펴볼 수 있습니다.
프로그램을 중지하는 것은 디버거이기 때문에 디버거에서 프로그램을 실행하지 않을 때는 중단 점이 효과가 없습니다.
… 또는 중단 점이 영향을 미치기 위해 gdb 내에서 프로그램을 실행해야하는지 여부.
그렇습니다. 디버거 중단 점은 디버거 내에서만 작동합니다.
내 질문은 다음과 같습니다. 중단 점을 설정 한 것이 사용자가 관찰 한 충돌의 원인이 될 수 있습니까?
아니.
먼저 언급했듯이 이러한 중단 점이 어떻게 든 사용자 시스템에 전달 되었더라도 중단 점은 디버거에서만 효과적입니다. 프로그램이 디버거에서 실행되지 않는 경우 디버거는 중단 점에서 중지 할 수 없습니다. 사용자는 디버거에서 앱을 실행하고 있지 않습니다. 특히 크래시 로그 아웃이 발생했기 때문입니다.
그들이 설정이 중단 점을 모두와 디버거에서 귀하의 응용 프로그램을 실행 않았더라도 프로그램에 도달 지점이이 중단 그렇게 하나가 당신이나 코코아 만 불이라고 할 수 있다면 있다고 할 때, 중단 점 적중 전용 _NSLockError, -[NSException raise]또는 objc_exception_throw. 그 지점에 도달하는 것이 문제의 원인이 아니라 문제의 증상 일 것입니다.
그리고 그 중 하나가 호출되어 충돌이 발생하면 충돌 로그에 적어도 하나의 이름이 포함됩니다. 그렇지 않습니다.
따라서 이것은 중단 점 (다른 머신, 관련되지 않은 디버거)과 관련이 없으며 Cocoa 예외도 아닙니다. 앞서 언급했듯이 Cocoa 예외는 SIGTRAP의 원인 중 하나이지만 유일한 원인은 아닙니다. 당신은 다른 것을 만났습니다.
그렇지 않다면 다른 사람이 [NSFont fontWithName : size :]와 유사한 문제를 겪고 있습니까?
충돌 로그를 잘라 냈기 때문에 우리가 가진 문제가 비슷한 지 여부를 알 수있는 방법은 없습니다. 우리는 충돌이 발생한 상황에 대해 아무것도 모릅니다.
잘라내기에 좋은 유일한 것은 “바이너리 이미지”섹션입니다. dSYM 번들이 없기 때문에이 섹션을 사용하여 충돌 로그를 상징 할 수 없습니다.
반면에 당신은 할 수 있습니다. 이 목적을 위해 앱 을 작성 했습니다 . 크래시 로그를 제공하면 자동으로 dSYM 번들을 감지하고 (배포하는 모든 릴리스 빌드에 대해 dSYM 번들을 유지하고 있습니까?) 함수와 메서드가 나타날 때마다 함수와 메서드 이름을 스택 추적에 복원해야합니다.
자세한 내용은 Xcode 디버깅 가이드를 참조하십시오 .
답변
이 사용자가 손상된 글꼴을 설치했을 가능성이 매우 높습니다. 스택 추적은 한 명의 사용자에게만 영향을 미친다는 사실과 마찬가지로이 가설을 확실히 뒷받침합니다.
이 경우 사용자가 문제가되는 글꼴을 제거하도록하는 것 외에는 할 수있는 일이 많지 않습니다. 발생하는 충돌은 Apple 코드의 깊숙한 곳에서 발생하기 때문입니다.
사용자가 서체 관리자에서 서체 유효성 검사를 실행하도록하십시오. 이렇게하려면 서체 관리자 를 시작하고 소스 목록에서 모든 서체 를 클릭 한 다음 나열된 모든 서체를 선택하십시오. 그런 다음 파일 메뉴 에서 글꼴 유효성 검사 를 선택할 수 있습니다 .
답변
중단 점은 바이너리에 기록되지 않습니다. 이 사람이 OS 설치에 문제가있을 가능성이 높습니다. 콘솔 로그에서 dyld 메시지를 확인하십시오.
답변
나는 같은 오류가 있었다. 설명 할 수없는 이유로 중단 점이 EXC_BREAKPOINT 예외를 던지는 원인이 되었습니다 . 해결책은 중단 점을 제거하는 것이 었습니다. 그러면 코드가 작동합니다.
EXC_BREAKPOINT 는 디버거가 사용하는 예외 유형입니다. 코드에 중단 점을 설정하면 컴파일러는 실행 코드에이 유형의 예외를 삽입합니다. 실행이 해당 지점에 도달하면 예외가 발생하고 디버거가이를 포착합니다. 그런 다음 디버거는 “중단 점”줄에 코드를 표시합니다. 이것이 디버거가 작동하는 방식입니다. 그러나이 경우 디버거는 예외를 올바르게 처리하지 않으며 일반 예외 오류로 표시됩니다.
내 인생에서이 오류를 두 번 발견했습니다.
- 약 1 년 전에 Xcode를 사용했습니다.
- 다른 하나는 약 15 년 전에 Visual C ++를 사용했습니다.
답변
