Чи винятки “EXC_BREAKPOINT (SIGTRAP)” спричинені точками зупинки налагодження?


82

У мене є багатопоточна програма, яка є дуже стабільною на всіх моїх тестових машинах і, здається, є стабільною майже для кожного мого користувача (на основі скарг на збої). Додаток часто аварійно завершує роботу для одного користувача, який достатньо люб’язно надсилав звіти про збої. Усі звіти про аварії (~ 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").

Відповіді:


188

Чи винятки “EXC_BREAKPOINT (SIGTRAP)” спричинені точками зупинки налагодження?

Ні. Навпаки, насправді: SIGTRAP (трап-трап) призведе до відладчика, який зламає (перерве) вашу програму, так само, як і фактична точка зупинки. Але це тому, що налагоджувач завжди ламається під час аварії, і SIGTRAP (як і кілька інших сигналів ) - це один із видів аварійних завершень .

SIGTRAP, як правило, спричинені викидами NSExceptions, але не завжди - можливо навіть безпосередньо підняти один.

Зараз я помітив, що забув видалити деякі точки налагодження, включаючи _NSLockError, [NSException raise] та objc_exception_throw.

Це не точки зупинку. Два з них є функціями і -[NSException raise]є методом.

Ви мали на увазі, що ви встановили точки зупинки для цих функцій та цього методу?

Я припускаю, що використання конфігурації "Release" перешкоджає встановленню будь-яких точок зупинки--

Немає.

Конфігурації - це конфігурації збірки . Вони впливають на те, як Xcode створює ваші програми.

Точки зупинку не є частиною побудови; ви встановлюєте їх у налагоджувачі. Вони існують, лише потрапляють і лише зупиняють вашу програму, коли запускаєте програму під налагоджувачем.

Оскільки вони не є частиною збірки, неможливо передати ваші точки зупинки користувачеві, просто надавши їм пакет програм.

Я не впевнений, як саме працюють точки зупинку ...

Коли ваша програма потрапляє в точку зупинки, налагоджувач розбиває (перериває) програму, після чого ви можете вивчити стан програми і обережно перейти вперед, щоб побачити, як програма йде не так.

Оскільки налагоджувач зупиняє вашу програму, точки зупинки не впливають, коли ви не запускаєте програму під налагоджувачем.

… Або чи потрібно запускати програму з gdb, щоб точки зупинку мали якийсь ефект.

Це робить. Точки зупинки налагоджувача працюють лише в межах налагоджувача.

Мої запитання: чи моє залишення встановлених точок зупинки може бути причиною збоїв, які спостерігає користувач?

Немає.

По-перше, як зазначалося, навіть якщо ці точки зупинку якимось чином переносились на систему користувача, точки зупинку ефективні лише в налагоджувачі. Налагоджувач не може зупинитися на точці зупинки, якщо ваша програма не працює під налагоджувачем. Користувач майже напевно не запускає ваш додаток під налагоджувачем, тим більше, що він отримав з нього журнал аварійного завершення роботи.

Навіть якщо вони не запустити додаток під отладчиком з усіма з цих точок зупину , встановленим, точка зупинки тільки хіт , коли ваша програма досягає цієї точки, так що одна з цих точок зупину може стріляти тільки якщо ви або какао називається _NSLockError, -[NSException raise]або objc_exception_throw. Дістатися до цієї точки не було б причиною проблеми, це було б симптомом проблеми.

І якби ви аварійно завершили роботу внаслідок того, що когось із тих, кого викликали, ваш журнал збоїв містив би принаймні один із них. Це не так.

Отже, це не було пов’язано з вашими точками зупинки (інша машина, налагоджувач не задіяний), і це не було винятком какао - як я вже згадував, винятки какао - одна з причин SIGTRAP, але вони не єдина. Ви зіткнулися з іншим.

Якщо ні, чи хтось ще мав подібні проблеми із [NSFont fontWithName: size:]?

Ми жодним чином не можемо визначити, чи є подібні проблеми у нас подібними, оскільки ви вирізали журнал збоїв. Ми нічого не знаємо про те, в якому контексті сталася аварія.

Єдине, що добре вирізати, це розділ «Двійкові зображення», оскільки у нас немає ваших пакетів dSYM, а це означає, що ми не можемо використовувати цей розділ для символізації журналу збоїв.

Ви, навпаки, можете. Для цього я написав додаток ; подайте до нього журнал збоїв, і він повинен автоматично виявляти набір dSYM (ви зберігаєте набір dSYM для кожної збірки випуску, яку ви розповсюджуєте, чи не так) і відновлювати імена функцій та методів у трасі стека, де б не з’являлися ваші функції та методи.

Для отримання додаткової інформації див . Посібник з налагодження Xcode .


3
Ого, дякую за вичерпну відповідь. • "Ви мали на увазі, що ви встановили точки зупинку для цих функцій ..." Так, це я мав на увазі. • "Точки зупинки не є частиною складання ... Вони існують лише, лише потрапляють і зупиняють програму лише тоді, коли запускаєте програму під налагоджувачем" Дякую, це саме те, що я хотів знати. • "символізувати журнал збоїв ... Я написав додаток для цього" Хороший додаток. Я зазвичай "символізую" чистою інтуїцією, але ваш додаток - кращий спосіб! • Я дійшов висновку, що це має певну проблему зі шрифтом користувача і буде працювати над цим з цієї точки зору.
Денніс

7

Надзвичайно ймовірно, що у цього користувача встановлено пошкоджений шрифт. Трасування стека безумовно підтримує цю гіпотезу, як і той факт, що це стосується лише одного користувача.

У цьому випадку ви не можете багато чого зробити, крім того, щоб змусити користувача видалити образливий шрифт, оскільки аварії, що трапляються, відбуваються глибоко в коді Apple.

Спробуйте змусити користувача виконати перевірку шрифтів у Font Book. Для цього запустіть Font Book, клацніть Усі шрифти у вихідному списку, а потім виберіть усі перелічені шрифти. Потім у меню Файл можна вибрати Перевірити шрифти .


1
Дякую за цю пораду щодо Font Book - я дуже мало знаю шрифти і насправді цікаво проводив перевірку власних шрифтів ... Я запропоную користувачеві спробувати це.
Денніс

0

Точки зупинки не записуються в двійковий файл. Хороші шанси, що у цієї людини зламана інсталяція ОС. Перевірте журнали консолі на наявність повідомлень dyld.


Дякую за цю швидку відповідь! Погугливши цю проблему, я помітив, що інші мають EXC_BREAKPOINTS, пов’язані з повідомленнями dyld, але в моїх журналах збоїв не відображаються повідомлення від dyld.
Денніс,

0

У мене була та ж помилка. З незрозумілої причини саме точка зупинки була причиною викиду EXC_BREAKPOINT . Рішенням було видалити точку зупинки, і тоді код працює.

EXC_BREAKPOINT - це тип винятку, який використовують налагоджувачі. Коли ви встановлюєте точку зупинки у своєму коді, компілятор вставляє виняток цього типу у виконуваний код. Коли виконання досягає цієї точки, виняток викидається, і налагоджувач ловить його. Потім налагоджувач відображає ваш код у рядку "з перервою". Ось як працюють налагоджувачі. Але в цьому випадку налагоджувач не обробляє виняток належним чином і подається як звичайна помилка винятку.

Я двічі у своєму житті знаходив цю помилку:

  • один, який використовує Xcode близько року тому.
  • інший за допомогою Visual C ++ близько 15 років тому.

Дивно, що я отримав цю помилку взагалі без жодних точок зупинки.
kelin

Я не кажу, що ця помилка виникає лише з точками зупинки: EXC_BREAKPOINT може трапитися з багатьох причин. Що я пояснюю, це пара дуже рідкісних випадків, коли точка зупинки породжує необроблений виняток.
veladan
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.