我有一個多線程應(yīng)用程序，該程序在所有測試機(jī)上都非常穩(wěn)定，并且?guī)缀鯇ξ业拿總€用戶都是穩(wěn)定的（基于對崩潰的抱怨）。但是，該應(yīng)用程序經(jīng)常會崩潰，因為一位用戶足夠發(fā)送崩潰報告。所有崩潰報告（約10個連續(xù)報告）看起來基本相同：Date/Time: 2010-04-06 11:44:56.106 -0700OS Version: Mac OS X 10.6.3 (10D573)Report Version: 6Exception Type: EXC_BREAKPOINT (SIGTRAP)Exception Codes: 0x0000000000000002, 0x0000000000000000Crashed Thread: 0 Dispatch queue: com.apple.main-threadThread 0 Crashed: Dispatch queue: com.apple.main-thread0 com.apple.CoreFoundation 0x90ab98d4 __CFBasicHashRehash + 33481 com.apple.CoreFoundation 0x90adf610 CFBasicHashRemoveValue + 12642 com.apple.CoreText 0x94e0069c TCFMutableSet::Intersect(__CFSet const*) const + 1263 com.apple.CoreText 0x94dfe465 TDescriptorSource::CopyMandatoryMatchableRequest(__CFDictionary const*, __CFSet const*) + 1154 com.apple.CoreText 0x94dfdda6 TDescriptorSource::CopyDescriptorsForRequest(__CFDictionary const*, __CFSet const*, long (*)(void const*, void const*, void*), void*, unsigned long) const + 405 com.apple.CoreText 0x94e00377 TDescriptor::CreateMatchingDescriptors(__CFSet const*, unsigned long) const + 1356 com.apple.AppKit 0x961f5952 __NSFontFactoryWithName + 9047 com.apple.AppKit 0x961f54f0 +[NSFont fontWithName:size:] + 39（....更多文字如下）首先，我花了很長時間研究[NSFont fontWithName：size：]。我發(fā)現(xiàn)也許用戶的字體以某種方式被弄亂了，所以[NSFont fontWithName：size：]正在請求一些不存在的內(nèi)容，并且由于該原因而失敗。我使用[[NSFontManager sharedFontManager] availableFontNamesWithTraits：NSItalicFontMask]添加了一堆代碼來預(yù)先檢查字體可用性?？杀氖?，這些更改并不能解決問題。現(xiàn)在，我注意到我忘記刪除一些調(diào)試斷點，包括_NSLockError，[NSException提高]和objc_exception_throw。但是，該應(yīng)用程序肯定是使用“發(fā)布”作為活動的構(gòu)建配置來構(gòu)建的。我假設(shè)使用“發(fā)布”配置可以防止設(shè)置任何斷點-但是，我再次不確定斷點是如何工作的，或者不確定是否需要從gdb中運(yùn)行程序才能使斷點生效。我的問題是：我離開斷點集后會導(dǎo)致用戶觀察到崩潰的原因嗎？如果是這樣，為什么斷點僅對這個用戶造成問題？如果不是，還有其他人對[NSFont fontWithName：size：]有類似的問題嗎？我可能會嘗試刪除斷點并發(fā)送回該用戶，但是我不確定該用戶剩下多少貨幣。而且，我想更廣泛地理解是否保留斷點設(shè)置可能會導(dǎo)致問題（當(dāng)使用“發(fā)布”配置構(gòu)建應(yīng)用程序時）。
3 回答
德瑪西亞99
TA貢獻(xiàn)1770條經(jīng)驗 獲得超3個贊
“ EXC_BREAKPOINT（SIGTRAP）”異常是否由調(diào)試斷點引起？
否。實際上，反過來：SIGTRAP（跟蹤陷阱）將導(dǎo)致調(diào)試器中斷（中斷）您的程序，就像實際斷點一樣。但這是因為調(diào)試器總是在崩潰時中斷，而SIGTRAP（就像其他幾個信號一樣）是崩潰的一種類型。
SIGTRAP通常是由引發(fā)NSExceptions引起的，但并非總是如此-甚至有可能直接自己引發(fā)。
現(xiàn)在，我注意到我忘記刪除一些調(diào)試斷點，包括_NSLockError，[NSException提高]和objc_exception_throw。
這些不是斷點。其中兩個是函數(shù)，-[NSException raise]是一種方法。
您是說要在這些函數(shù)和方法上設(shè)置斷點嗎？
我假設(shè)使用“發(fā)布”配置可防止設(shè)置任何斷點-
沒有。
這些配置是構(gòu)建配置。它們影響Xcode構(gòu)建應(yīng)用程序的方式。
斷點不是構(gòu)建的一部分；您在調(diào)試器中設(shè)置它們。它們僅存在，只會被命中，并且只有在調(diào)試器下運(yùn)行程序時才停止程序。
由于它們不是構(gòu)建的一部分，因此不可能僅通過向他們提供應(yīng)用程序捆綁包就將斷點傳遞給用戶。
我不確定斷點是如何工作的……
當(dāng)您的程序到達(dá)斷點時，調(diào)試器將中斷（中斷）您的程序，隨后您可以檢查程序的狀態(tài)并仔細(xì)向前查看程序如何出錯。
由于是調(diào)試器停止程序，因此當(dāng)您不在調(diào)試器下運(yùn)行程序時，斷點不起作用。
…或者是否需要從gdb內(nèi)部運(yùn)行程序才能使斷點生效。
是的 調(diào)試器斷點僅在調(diào)試器中起作用。
我的問題是：我離開斷點集后會導(dǎo)致用戶觀察到崩潰的原因嗎？
沒有。
首先，如前所述，即使這些斷點確實以某種方式傳遞到用戶的系統(tǒng)中，斷點也僅在調(diào)試器中有效。如果您的程序不在調(diào)試器下運(yùn)行，則調(diào)試器無法在斷點處停止。用戶幾乎可以肯定不在調(diào)試器下運(yùn)行您的應(yīng)用程序，尤其是因為他們從崩潰日志中注銷了該應(yīng)用程序。
即使他們與所有這些斷點設(shè)置的調(diào)試器下運(yùn)行你的應(yīng)用程序，當(dāng)你的程序到這一點，這些斷點所以人們只能火災(zāi)，如果你或可可稱為斷點只打了_NSLockError，-[NSException raise]或objc_exception_throw。達(dá)到這一點并不是問題的原因，而是問題的征兆。
而且，如果由于其中之一被調(diào)用而導(dǎo)致崩潰，那么崩潰日志中將至少有其中一個被命名。沒有。
因此，這與您的斷點無關(guān)（不涉及其他機(jī)器，調(diào)試器），也不是Cocoa異常-正如我提到的那樣，Cocoa異常是SIGTRAP的原因之一，但不是唯一的原因。您遇到了另一個。
如果不是，還有其他人對[NSFont fontWithName：size：]有類似的問題嗎？
因為您切斷了崩潰日志，所以我們無法說出我們遇到的任何問題是否相似。我們對于崩潰發(fā)生的背景一無所知。
唯一值得刪除的是“二進(jìn)制映像”部分，因為我們沒有您的dSYM軟件包，這意味著我們無法使用該部分來表示崩潰日志。
另一方面，您可以。我為此目的編寫了一個應(yīng)用程序；將崩潰日志提供給它，并且它應(yīng)該自動檢測dSYM軟件包（您為分發(fā)的每個Release版本保留dSYM軟件包，對嗎？），然后將函數(shù)和方法名恢復(fù)到堆棧跟蹤中，無論函數(shù)和方法出現(xiàn)在何處。
三國紛爭
TA貢獻(xiàn)1804條經(jīng)驗 獲得超7個贊
此用戶極有可能安裝了損壞的字體。堆棧跟蹤絕對支持該假設(shè)，事實上它僅影響一個用戶。
在這種情況下，除了讓用戶刪除有問題的字體外，您無能為力，因為崩潰發(fā)生在Apple代碼的深處。
嘗試讓用戶在“字體書”中運(yùn)行字體驗證。為此，請啟動“字體書”，在源列表中單擊“ 所有字體 ”，然后選擇所有列出的字體。然后，您可以從“ 文件”菜單中選擇“ 驗證字體 ” 。
- 3 回答
- 0 關(guān)注
- 4295 瀏覽
添加回答
舉報
0/150
提交
取消