Report crash mac os ��� ���������

Crash Reports: How To Use Them To Troubleshoot Why Your Mac Crashed

This article’s focus is on macOS crash reports. More specifically this article explains how you can (1) locate crash logs (2) and read them to diagnose a crash.

Your Mac can crash, rarely. These crashes usually mean nothing important, if it is rare. Thus it is not something you should worry about. In most cases, restarting your Mac will resolve the issue. Your Mac will automatically reboot itself.

However, if your Mac is crashing frequently, you may want to find our why these crashes occur so that you can prevent them from happening again. And the most important thing you should do is to find more specific error details.

In this article we are going to take a look at using the crash logs that your system generate. These logs will help you identify what’s causing the crash.

Where to find crash reports

There are two ways to access your crash reports. You can use any of the methods:

1. You can use the Console app. The Console app included with your Mac. You can open this app by going to Applications > Utilities > Console. You can also use Spotlight to access Console. Select your Device and click Crash reports under the ‘reports’ section.
2. You can also find your crash reports in

/Library/Logs/DiagnosticReports/. Here is how you can access there:

1. Go to Finder
2. Now press the Option key and then click Go (while you are pressing the Option key)
3. Click Library
4. Click the Logs folder
5. Click the DiagnosticReports folder
6. And open the file that says “Crash”

How to read macOS crash reports

Understaing these reports can be difficult as they are usually big. Here is how you can decipther a crash report:

1. The first section of a crash report includes what process crashed. Something like this:

In this case, said process is WebKit (Safari).

2. The next section of a crash report includes date/time and operating system, like this:

3. The next section includes more crash details (The Exception), something like this:

There are four common exeption types, according to Apple:

EXC_BAD_ACCESS/KERN_INVALID_ADDRESS — This is caused by the thread accessing unmapped memory. It may be triggered by either a data access or an instruction fetch; the Thread State section describes how to tell the difference.

EXC_BAD_ACCESS/KERN_PROTECTION_FAILURE — This is caused by the thread trying to write to read-only memory. This is always caused by a data access.

EXC_BAD_INSTRUCTION — This is caused by the thread executing an illegal instruction.

EXC_ARITHMETIC/EXC_I386_DIV — This is caused by the thread doing an integer divide by zero on an Intel-based computer.

The next section includes backtrace information. There can be one or multiple threads. In reverse chronological order, each thread shows the series of events .

To understand this section, find the thread that crashed. You can easily find that, because the report will say something like this: Thread (thread number) Crashed. This section explains what lead to the crash.

There are four columns here:

• The first one is the frame number (reverse chronological), like 0, 1, 2, 3….
• The second one is the name of the program or other process that performed the task. In this instance, com.apple.WebKit.
• The third column is the counter program address.
• The fourth column is the task.

From this example, we know that, for example, “com.apple.WebCore 0x00007fff3e26977a WebCore::HTMLMediaElement::mediaCanStart(WebCore::Document&) + 90” is responsible for the crash.

Now you know what caused the crash and series of events triggered the crash. This will help you idendify the problem and then address it appropriately.

If your problem is a third-party app, you may want to contact its developer. Tell them your problem and you may want to send a copy of this crash log. You can click the share icon in the Console app to send the report.

Serhat Kurt

Dr. Serhat Kurt worked as a Senior Technology Director. He holds a doctoral degree (or doctorate) from the University of Illinois at Urbana / Champaign and a master’s degree from Purdue University. Here is his LinkedIn profile.

Thank you for choosing to leave a comment.

Please note the following:

• All comments are moderated.
• Your email will NOT be published nor shared.
• All SPAM comments will be deleted.
• Please see our comment policy page for more info.

Источник

How to Read macOS Crash Reports to Troubleshoot Your Mac

App crashes on the Mac are generally pretty rare. But when they do happen, you might want to trace their cause. And if you’re a developer, you need to understand why your app is crashing. Here’s how to read macOS crash reports and sort through the cryptic language.

Opening Crash Reports

When an app crashes on your Mac, it automatically generates a crash report. You’ll see this appear after the crash with a warning dialog saying “[App] has quit unexpectedly.” That crash report is available to read immediately in that window by clicking the “Report …” button. The crash report can also be found in the Console app.

1. Open the Console application by typing “Console” into Spotlight or navigating to “Application -> Utilities -> Console.app.”

2. Click on “User Reports” in the left menu, then click on the crash report you want to view. All these files will end in “.crash” and include the date and crashed application in the title. The details of the crash report are available in the pane on the right.

Reading macOS Crash Reports

Let’s navigate the crash report from top to bottom.

What crashed?

The first part of the crash report tells you what “process” or application crashed. The most important part for the average troubleshooter is the process name.

When did it crash?

The second part tells us when the crash occurred. It also provides a little information about your system.

What caused the crash?

The next part is the most illuminating. The”exception type” provided by the application tells us what caused the crash. The log also reports which thread crashed: in this case, thread 0.

Apple lists some common exception types in their technical documentation:

• Bad Memory Access ( EXC_BAD_ACCESS / SIGSEGV / SIGBUS ) – the program attempts to access memory incorrectly or with an invalid address. Appended with a code explaining the memory issue.
• Abnormal Exit ( EXC_CRASH / SIGABRT ) – abnormal exit, typically at the hand of an uncaught C++ exception and calls to abort()
• Trace Trap ( EXC_BREAKPOINT / SIGTRAP ) – like SIGABRT, but this exit gives the attached debugger the chance to interrupt the process at a breakpoint and trace the error.
• Illegal Instruction ( EXC_BAD_INSTRUCTION / SIGILL ) – the processed issued an instruction that wasn’t understood or couldn’t be processed.
• Quit ( SIGQUIT ) – the process was terminated by another process with sufficient privileges. Typically, a watchdog process terminates a misbehaving process.
• Killed ( SIGKILL ) – the process was terminated at the request of the system. A termination code will be appended to explain the exception.

As we can see from our crash report, the application tried to access unmapped memory. This is due to a programming error in the application or an unusual user state causing the application to map memory incorrectly.

What lead to the crash?

After that we see a reverse chronological list of what lead up to the crash. These are sorted by thread, starting with thread 0.

There are four columns to this report. The first reports the event’s number in reverse chronological order, starting at 0. The second is the process’s identifier. The third is the address of the process in memory. The fourth is the name of the program’s task.

This “backtrace” can be somewhat baffling. It’s “symbolicated,” meaning some of the memory addresses have been replaced with function names or application tasks. Sometimes this can’t be done completely, leaving unreadable memory addresses scattered through the report.

We see this in the crash report above: com.trankynam.aText is not symbolicated. Even with complete symbolication, it can be hard to read the backtrace. Sometimes developers include useful notes about application tasks and events. Other times, they’re cryptic titles or numerical code. If you can make sense of the symbolication, you might be able to understand what’s happening. But it’s equally as possible that you’ll need to have coded the application yourself to make sense of the backtrace.

Conclusion: Is This Useful?

If you’re a developer, reading crash reports is essential. It helps you understand what part of your application is crashing and why. If you’re a user, they’re not as helpful. But if you have a persistent crash, the crash reports can help you troubleshoot the issue or work with the developer to fix the problem. You might get a useful error code to Google or be able to provide tech support with the right information. If you want the gory details, you can read all about it in Apple’s technical note on crashes.

Alexander Fox is a tech and science writer based in Philadelphia, PA with one cat, three Macs and more USB cables than he could ever use.

Источник

Отключить диалоговое окно Crash Reporter в Mac OS X

Если вы разработчик (или кто-либо другой), вам может быстро надоесть диалоговое окно Crash Reporter, которое появляется, когда приложение «плавится» и вылетает в Mac OS X. Если вас беспокоит диалоговое окно аварийного репортера, затем вы можете быстро включать и выключать окно с помощью командной строки по умолчанию.

Обратите внимание, что отключение диалогового окна Crash Reporter не влияет на отчеты о сбоях, которые по-прежнему отображаются в системных журналах и в приложении консоли. Он просто останавливает появление окна в графическом интерфейсе Mac OS X.

Как отключить диалоговое окно Crash Reporter в Mac OS X

Ты можешь отключить Crash Reporter диалоговое окно, запустив Терминал и введя следующую команду:

defaults write com.apple.CrashReporter DialogType none

и вы можете отменить это, чтобы снова показать Crash Reporter, введя в командную строку следующее:

defaults write com.apple.CrashReporter DialogType crashreport

Как правило, лучше оставить этот тип вещей установленным по умолчанию, а отправка отчетов о сбоях действительно помогает Apple отлаживать и улучшать программное обеспечение, но если у вас есть веская причина отключить его, теперь вы знаете, как это сделать.

Итак, вы хотите видеть CrashReporter или нет? Решать вам:

Для некоторых пользователей это полезно, а для некоторых — нет. Это работает во всех версиях OS X.

Источник

В чипе безопасности iPhone нашли неустранимую уязвимость

Китайская группа исследователей в области кибербезопасности Pangu Team, специализирующаяся на поиске уязвимостей в железе и программном обеспечении Apple, продемонстрировала на конференции MOSEC в Шанхае найденную ими брешь в чипе SEP (secure enclave processor). Он используется iPhone и iPad для безопасного хранения биометрических данных (скан лица Face ID, отпечатки пальцев), токенов банковских карт, добавленных в Apple Pay, хранящихся в сервисе Keychain паролей и т.п.

Как пишет издание Digitpol со ссылкой на презентацию исследователей, уязвимость в «яблочном» SEP обнаружена впервые. При этом она затрагивает «вшитое» в чип программное обеспечение и поэтому является неустранимой — технической возможности обновить это ПО нет.

Новая уязвимость построена на вмешательстве в процесс защищенного обмена данными между основным чипом iPhone и чипом Secure Enclave. Доступ к манипуляциям с первым из них удалось получить благодаря эксплойту chekm8 — он задействует неустранимую уязвимость в загрузчике всех iPhone вплоть до iPhone X, найденную в прошлом году.

Издание отмечает, что новая уязвимость в iPhone не настолько страшна, как может показаться на первый взгляд. Во-первых, она затрагивает только устройства, на которых может быть установлен джейлбрейк checkra1n (он использует эксплойт checkm8), но не более новые iPhone с процессорами A12 и A13. Во-вторых, отмечает в твиттере обнаруживший в 2019-м checkm8 хакер @axi0mX, уязвимы для атаки с использованием бреши в SEP только устройства, к которым у взломщиков есть физический доступ.

(5) As long as no one else takes physical possession of the device, plugs in a cable and puts it in DFU Mode, it is still secure, and we can use latest iOS with all security patches. Yet, we have the option to jailbreak it anytime, if we want to, and do anything we want.

После загрузки операционной системы iPhone и без подключения по кабелю к ПК или специальному оборудованию использовать новую уязвимость во вред пользователю невозможно.

Источник