"EXC_BREAKPOINT (SIGTRAP)"예외가 중단 점 디버깅으로 인해 발생합니까?

"EXC_BREAKPOINT (SIGTRAP)"예외가 중단 점 디버깅으로 인해 발생합니까?

---

모든 테스트 컴퓨터에서 매우 안정적이고 거의 모든 사용자에게 안정적인 것처럼 보이는 다중 스레드 앱이 있습니다 (충돌에 대한 불만 사항 없음). 하지만 앱은 충돌 보고서를 보낼만큼 친절했던 한 사용자에게 자주 충돌합니다. 모든 충돌 보고서 (~ 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 내에서 프로그램을 실행해야하는지 여부.

그렇습니다. 디버거 중단 점은 디버거 내에서만 작동합니다.

My questions are: could my having left the breakpoints set be the cause of the crashes observed by the user?

No.

First, as noted, even if these breakpoints did somehow get carried over to the user's system, breakpoints are only effective in the debugger. The debugger can't stop on a breakpoint if your program isn't running under the debugger. The user almost certainly isn't running your app under the debugger, especially since they got a crash log out of it.

Even if they did run your app under the debugger with all of these breakpoints set, a breakpoint is only hit when your program reaches that point, so one of these breakpoints could only fire if you or Cocoa called _NSLockError, -[NSException raise], or objc_exception_throw. Getting to that point wouldn't be the cause of the problem, it'd be a symptom of the problem.

And if you did crash as a result of one of those being called, your crash log would have at least one of them named in it. It doesn't.

So, this wasn't related to your breakpoints (different machine, debugger not involved), and it wasn't a Cocoa exception—as I mentioned, Cocoa exceptions are one cause of SIGTRAPs, but they are not the only one. You encountered a different one.

If not, has anybody else had similar problems with [NSFont fontWithName:size:]?

There's no way we can tell whether any problems we've had are similar because you cut off the crash log. We know nothing about what context the crash happened in.

The only thing that's good to cut out is the “Binary images” section, since we don't have your dSYM bundles, which means we can't use that section to symbolicate the crash log.

You, on the other hand, can. I wrote an app for this purpose; feed the crash log to it, and it should detect the dSYM bundle automatically (you are keeping the dSYM bundle for every Release build you distribute, right?) and restore your function and method names into the stack trace wherever your functions and methods appear.

For further information, see the Xcode Debugging Guide.

---

It is extremely likely that this user has a corrupt font installed. The stack trace definitely supports that hypothesis, as does the fact that it's only affecting one user.

There's not much you can do in that case except get the user to remove the offending font, as the crashes that occur take place deep down in Apple's code.

Try getting the user to run a font validation in Font Book. To do this, launch Font Book, click All Fonts in the source list and then select all the listed fonts. You can then select Validate Fonts from the File menu.

---

Breakpoints aren't written to the binary. Odds are good that this person has a broken OS installation. Check the console logs for dyld messages.

---

I had the same error. For an unexplainable reason the breakpoint was the responsible of the throwing the EXC_BREAKPOINT exception. The solution was to remove the breakpoint, and then code works.

EXC_BREAKPOINT is a type of exception that debuggers use. When you set a breakpoint in your code, the compiler inserts an exception of this type in the executable code. When the execution reaches that point, the exception is thrown and the debugger catches it. Then the debugger shows your code in the "breakpointed" line. This is how debuggers work. But in this case the debugger does not handle the exception correctly and is presented as a regular exception error.

I have found this error two times in my life:

• one using Xcode about a year ago.
• the other using Visual C++ about 15 years ago.

참고URL : https://stackoverflow.com/questions/2611607/are-exc-breakpoint-sigtrap-exceptions-caused-by-debugging-breakpoints