Recently my laptop has been having Kernel Panics once every few days. I can't find a certain program that is making it happen, or a certain task that I perform.
I read that you can look in the .crash reports for a possible cause. So here is part of one I found.
Dyld Error Message:
Library not loaded: /usr/lib/libgutenprint.2.dylib
Referenced from: /usr/libexec/cups/driver/gutenprint.5.2
Reason: image not found
I am wondering if gutenprint.5.2 could be the reason for the Kernel crashing. If so, should I remove it? Install an update?
Thanks!
That's not a kernel panic. You'll find kernel panic reports in Console.app, under system diagnostic reports. They start with "kernel" and end with ".panic". Unless you wrote the driver that's crashing, this is the wrong site to post such questions. Try the Ask Different sister site at https://apple.stackexchange.com/ instead.
Related
I've got some obscure errors in an OS X program concerning the loading and unloading and symbol bindings of dynamically loaded libraries. First attempts to analyse the problem by using the DYLD_PRINT_* environment variables failed.
I solved similar problems under GNU/Linux by installing the glibc with debug symbols and the corresponding sources. Since the sources for dyld are also available, something similar must be possible under OS X.
How do I have to proceed in order to set up a debugging session and step through the sources of dyld in order to understand what went wrong with the program? Is it possible to start an application using a different hand-crafted dyld?
You can set a symbolic breakpoint of dyld`dyldbootstrap::start.
So, Symbol is "dyldbootstrap::start", and Module is "dyld".
Actually, we can set a symbolic breakpoint of dyld`_dyld_start, and we can see it enabled after the process launched, but it won't be hit.
Yes, and it's actually designed to be this way. You can drop your custom dyld in the file system, making sure its LC_ID_DYLINKER command is set properly. Then, to use it, edit the Mach-O you are loading so that its LC_LOAD_DYLINKER points to it.
Mind you, it's possible to just step through dyld anyway without all this - use lldb and do process launch -s , then you can single step right through dyld as well, albeit in assembly.
Caveat: Don't touch or move the /usr/lib/dyld in the process - but rather drop the custom dyld side by side to it. Since virtually everything requires dyld, moving it can be a pain to undo (and requires booting with a ramdisk and mounting the root file system as a secondary just so as to issue the correcting mv..)
I have I/O Kit driver: virtual ethernet device. After some period of work OS hangs, so looks like I have some deadlock in my driver.
I've done next steps:
- connect two macbooks via FireWire
- set up debugging environment
- initialise NMI (via power button)
- connect to the target via gdb
- grab address of my kext
- create and load symbols (this is the last point in all docs I've read)
So far so good. In case of kernel panic it would be enough. But in my case there is no kernel panic and I reside in the thread that handle the NMI.
Now the question: how can I switch to the thread of my kext?
Command showalltasks gives me listing of all tasks, the only task where my kext may be running is kernel_task, so I'm trying to examine this task via showtaskthreads and showtaskstacks but can't find anything similar to my code. Am I missing something?
I would be appreciated for any suggestions or links to the docs.
I'm not answering your question directly - but would it be possible to hit your kext code with a breakpoint? A common method of kernel debugging is to nmi the machine, attach the debugger, put a breakpoint in the code of interest, resume execution (continue) and then do whatever is needed to hit the breakpoint.
Well, I'm answering my own question.
To see the thread using code of my kext I need to switch to the process using my kext. In my case it will be probably a browser (since my kext is the NKE).
But in fact it didn't help me a lot. But old print method helped me to find the deadlock. So my advice is next: for the kernel panic - use debugger, for the deadlock - use printing, find place where lock is and analyse code.
I am working on a video processing project using Qt and Opencv with Qt Creator IDE in Windows 7 32bit. I have been successful compiling and running my code. But when I close the gui of my application Windows pops up an error :
MyProgram.exe has stopped working
Problem signature:
Problem Event Name: APPCRASH
Application Name: QtTracker3.exe
Application Version: 0.0.0.0
Application Timestamp: 5107b5da
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7600.16695
Fault Module Timestamp: 4cc7ab44
Exception Code: c0000005
Exception Offset: 00052073
OS Version: 6.1.7600.2.3.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
I am not a professional programmer and I need not to know whether this happens because my poor programming skills or something else..
Exception code c0000005 is an access violation, also known as general protection fault. The program is reading from, or writing to, an address which is not part of the virtual address space. A very common cause is that you are de-referencing a stale pointer. In other words, the pointer was once valid, but you have subsequently freed it. Then later when you attempt to access it, an exception is raised.
The exception is faulting in ntdll.dll which is a system DLL. That means that something in your program is passing invalid data to a system API.
In order to solve this problem you will likely need to run under the debugger and let the debugger break at the point in the code where the exception occurs. Then you can attempt to work out why the memory that is being accessed is invalid.
That's something that you can do, but we cannot. You have the code, we do not. So, we can't give you any more help than this. In any case, there's no need to despair–these problems are usually easy enough to solve with the help of a debugger.
Sometimes delete the contents of your build directory and try to compile again just to make sure nothing is caching.
Well, fortunately I haven't written many applications that cause a BSOD but I just wonder about the usefullness of the information on this screen. Does it contain any useful information that could help me to find the error in my code? If so, what do I need, exactly?
And then, the system restarts and probably has written some error log or other information to the system somewhere. Where is it, what does it contain and how do I use it to improve my code?
I did get a BSOD regularly in the past when I was interacting with a PBX system where the amount of documentation of it's drivers were just absent, so I had to do some trial-and-error coding. Fortunately, I now work for a different company and don't see any BSOD's as a result of my code.
If you want a fairly easy way to find out what caused an OS crash that will work ~90% of the time - assuming you have a crash dump available - then try the following:
Download WinDbg as part of the Debugging tools for Windows package. Note, you only need to install the component called Debugging Tools for Windows.
Run WinDbg
Select "Open Crash Dump" from the file menu
When the dump file has loaded type analyze -v and press enter
WinDbg will do an automated analysis of the crash and will provide a huge amount of information on the system state at the time of the crash. It will usually be able to tell you which module was at fault and what type of error caused the crash. You should also get a stack trace that may or may not be helpful to you.
Another useful command is kbwhich prints out a stack trace. In that list, look for a line contains .sys. This is normally the driver which caused the crash.
Note that you will have to configure symbols in WinDbg if you want the stack trace to give you function names. To do this:
Create a folder such as C:\symbols
In WinDbg, open File -> Symbol File Path
Add: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
This will cache symbol files from Microsoft's servers.
If the automated analysis is not sufficient then there are a variety of commands that WinDbg provides to enable you to work out exactly what was happening at the time of the crash. The help file is a good place to start in this scenario.
Generally speaking, you cannot cause a OS crash or bug check from within your application code. That said, if you are looking for general tips and stuff, I recommend the NTDebugging blog. Most of the stuff is way over my head.
What happens when the OS crashes is it will write a kernel dump file, depending on the current flags and so on, you get more or less info in it. You can load up the dump file in windbg or some other debugger. Windbg has the useful !analyze command, which will examine the dump file and give you hints on the bucket the crash fell into, and the possible culprits. Also check the windbg documentation on the general cause of the bug check, and what you can do to resolve it.
Short Q.: What does this exception mean? "EXC_BAD_ACCESS (0x0001)"
Full Q.: How can I use this error log info (and thread particulars that I omitted here) to diagnosis this app crash? (NB: I have no expertise with crash logs or OS kernels.)
In this case, my email client (Eudora) crashes immediately on launch, every time, after no apparent system changes.
Host Name: [name of Mac]
Date/Time: 2008-09-28 14:46:54.177 -0400
OS Version: 10.4.11 (Build 8S165)
Report Version: 4
Command: Eudora
Path: /Applications/[...]/Eudora Application Folder/Eudora.app/Contents/MacOS/Eudora
Parent: WindowServer [59]
Version: 6.2.4 (6.2.4)
PID: 231
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000001
To answer your short question: EXC_BAD_ACCESS means an illegal memory access. This means that the program tried to use a memory location outside its virtual address space (roughly speaking, the area of memory it has requested from the OS kernel). This is what Unix people typically call a "segmentation fault" (segfault), and what Windows people typically call an "access violation" (AV) or "general protection fault" (GPF). (Yes, you probably already knew that. But I'm just making sure...)
Does the crash report say what memory address was being referenced? Does the report include the call stack or a core dump? All three are very valuable, especially the core dump as you can load it into the debugger and restart the program right from the point of the exception. And if the memory address seems totally out of whack (in the higher half of the virtual address, or very close to 0, then you have a good clue where the problem lies).
Just to complete Michael's answer - analyzing the crash log is not what you are supposed to do. The eudora programmers screwed up (or the people providing the tools the eudora programmers use to make eudora). The best thing you can do is copy and paste the entire contents of the crash log in to a mail client (try MAIL, as you can't seem to use eudora, right now, hahaha), and send it to eudora-support#eudora.com along with a short description of what's happening. It's their job to figure out what went wrong.