I'm running macOS Sierra, but same experienced on High Sierra.
When I open the Simulator in Xcode 9.1, it doesn't load anything (sometimes a red screen), however crashes the whole system. I can move the mouse, but everything is unclickable.
Really rarely it receives clicks and I can open the Activity Monitor to shut it down. Restart doesn't help, because Simulator is reopened then, and crashes the whole system again.
Is there anyone out there experiencing the same issue? Any solutions, suggestions?
Could this relate to the fact that I have a Hackintosh?
We can't provide support for pirate copies of macOS running on non-Apple hardware. I would encourage you to purchase authorized Apple hardware which comes with a legal copy of macOS.
Red is the canary texture indicating the GPU didn't write anything to the surface. It is probably a rendering failure due to graphics driver bugs. You can check the logs in cases where it doesn't fully restart and you may find GPU restarts are taking place. If the GPU restart fails then the system will panic and reboot.
Edit: As I previously indicated, you're running untested hardware on a hacked copy of macOS using unknown drivers. If you're using built-in drivers it may be a mis-match between the hardware they expect and the GPU you have. If you're using vendor-provided drivers it may be a simple bug. And when running any non-standard kernels or kernel extensions there could be a vast array of possible causes (bad kernel extension corrupting some data structure, etc)
Related
I need help debugging an issue, where an application that uses CoreAudio to mix several input sources into an output screen, experiences crackling in the output stream, but only after the Mac has woken from sleep.
The app was running fine before the Mac went to sleep, and restarting the app fixes the problem.
The application uses a couple of threads to do it's thing, which makes me assume that resource limits are altered by the system for the app, or some buffers used by CoreAudio have changed in size.
Any ideas how to debug that issue?
I'm more of a web-developer and database guy, but severely inconvenient performance issues relating to kernel_task and temperature on my personal machine have made me interested in digging into the details of my Mac OS (I notices some processes would trigger long-lasting spikes in kernel-task, despite consistently low CPU temperature and newly re-imaged machine).
I am a root user on my own OSX machine. I can read /System/Library/Kernels/kernel. My understanding is this is "Mach/XNU" Kernel of this machine (although I don't know a lot about those, but I'm surprised that it's only 13Mb).
What happens if I modify or delete /System/Library/Kernels/kernel?
I imagine since it's at run-time, things might be okay until I try to reboot. If this is the case, would carefully modifying this file change the behavior of my OS, only effective on reboot, presuming it didn't cause a kernel panic? (is kernel-panic only a linux thing?)
What happens if I modify or delete /System/Library/Kernels/kernel?
First off, you'll need to disable SIP (system integrity protection) in order to be able to modify or edit this file, as it's protected even from the root user by default for security reasons.
If you delete it, your system will no longer boot. If you replace it with a different xnu kernel, that kernel will in theory boot next time, assuming it's sufficiently matched to both the installed device drivers and other kexts, and the OS userland.
Note that you don't need to delete/replace the kernel file to boot a different one, you can have more than one installed at a time. For details, see the documentation that comes with Apple's Kernel Debug Kits (KDKs) which you can download from the Apple Developer Downloads Area.
I imagine since it's at run-time, things might be okay until I try to reboot.
Yes, the kernel is loaded into memory by the bootloader early on during the boot process; the file isn't used past that, except for producing prelinked kernels when your device drivers change.
Finally, I feel like I should explain a little about what you actually seem to be trying to diagnose/fix:
but severely inconvenient performance issues relating to kernel_task and temperature on my personal machine have made me interested in digging into the details of my Mac OS
kernel_task runs more code than just the kernel core itself. Specifically, any kexts that are loaded (see kextstat command) - and there are a lot of those on a modern macOS system - are loaded into kernel space, meaning they are counted under kernel_task.
Long-running spikes of kernel CPU usage sound like they might be caused by file system self-maintenance, or volume encryption/decryption activity. They are almost certainly not basic programming errors in the xnu kernel itself. (Although I suppose stupid mistakes are easy to make.)
Another possible culprits are device drivers; especially GPU drivers are incredibly complex pieces of software, and of course are busy even if your system is seemingly idle.
The first step to dealing with this problem - if there indeed is one - would be to find out what the kernel is actually doing with those CPU cycles. So for that you'd want to do some profiling and/or tracing. Doing this on the running kernel most likely again requires SIP to be disabled. The Instruments.app that ships with Xcode is able to profile processes; I'm not sure if it's still possible to profile kernel_task with it, I think it at least used to be possible in earlier versions. Another possible option is DTrace. (there are entire books written on this topic)
I'm developing a KEXT on mac using Xcode, After every compile I'm changing permissions through terminal and load the KEXT, then reading results from console app. Some of the mistakes in development giving system a kernel panic and I have to restart my mac, this is so annoying. I was wondering if there is a better way to develop and debug a KEXT?
This is too big a topic for an answer, but it is at least well documented, look at these documents from Apple:
When Things Go Wrong: Debugging the Kernel
Debugging a Kernel Extension with GDB
Technical Note TN2063: Understanding and Debugging Kernel Panics
Also note that you can get the output from kprintf() logging calls via Firewire (using the fwkpfv command-line utility on the other Mac) or Serial Port (mainly useful for testing in VMs, as modern Macs don't have serial ports). kprintf is synchronous, so unlike the kernel.log you will see the debug output even if it occurs immediately before a crash.
Currently i'm developing a Cocos2d application for Mac OS X using xCode 4.2.1.So my problem is,sometimes while running the program the system get's stuck and show me a message like this- You need to restart your computer.Hold down the power button until it turns off.Then press the power button again. After receiving this message i can't proceed further without restarting the computer. What might be the problem behind this issue. Can anyone help me out.
What You get is called a kernel panic.
Resolution
Restart your Mac with a Safe Boot and see if the kernel panic happens
again
In most cases, kernel panics are not caused by an issue with your Mac.
They are most likely caused by an issue external to your Mac. If the
kernel panic doesn't happen again within a few weeks, you don't need
to troubleshoot further.
Depending on the model of Mac you have, restart one of these ways:
• Press and hold the Power button for several seconds to turn off your Mac. Then, press the Power button to startup your Mac.
• If you have a Restart button, press it.
As soon as your Mac starts up, hold down the Shift key to start up with a Safe Boot into Safe Mode. Note: If you are using a third-party
external keyboard and cannot start with a Safe Boot, try using an
Apple keyboard instead.
If your Mac has a kernel panic starting up, or while in Safe Mode, jump to the "Troubleshooting a recurring kernel panic" section of this
article.
If your Mac starts up without a kernel panic after a Safe Boot, restart your Mac by choosing Apple Menu > Restart…, then let it start
up normally. Run Software Update and install all available updates
until Software Update reports "Your software is up to date". Mac OS X
updates improve the tolerance for external issues such as malformed
network packets. For most kernel panics, this is all you have to do.
Note: It is possible, although very unlikely, that something on your network is sending your Mac malformed network packets which could cause recurring kernel panics. If the hardware and software on your Mac checks out as OK, check the devices on your network. Make sure your router's firmware is up-to-date, and that the router is not malfunctioning. Refer to your router's manufacturer for service and support.
And You also can try to find the problem in kernel.log. Go to the console app in the utilities folder and then type this:
tail -f /var/log/kernel.log
It will print kernel.log file to Your console.
More information:
Kernel Logs from the Command Line in Mac OS X.
How to log a kernel panic.
Kernel Panic.
I'm building an IOKit CFPlugin driver for OS X. I'll be working with network data coming in that will be translated to MIDI data. No hardware is involved other than the built-in Airport. I have experience with drivers on Windows machines and firmware but this is my first dip into doing it on the Mac. So far things are going pretty well, but the Apple documentation sez: "For safety reasons, you should not load your driver on your development machine."
I only have one Mac. I really don't want two Macs- sorry, Apple. Should I take this warning seriously? Are there things I need to know?
Thanks, Tom Jeffries
You could also consider running OS X inside a VM as your testbed. It would surely be much more convenient that having a separate boot volume.
The warning is rather poorly worded; what you should consider doing is using a separate boot volume (partition) for trying out your driver, since it's possible to arbitrarily hose your system with your driver.
If you're doing kernel development on any OS that isn't isolated from your main system (via a VM, alternate boot disk, etc.), you're crazy!
What may be a bigger issue is that you can't do any kernel debugging, because the only option for that is to use GDB on a remote OS X system. For this, you may want to consider running OS X in virtualization.
you DEFINITELY want to have some way to recover a fubar kext installation: a bootable external drive or something you can quickly restore from-- this is the main reason for Apple's warning against running in-development-kernel-extensions on your production machine.
Nicholas is right that in order to debug using gdb (the only way in kernel space) you do need two machines. I've never tried using a VM as Coxy suggests: but I guess it's feasible (assuming that you run your kext on the virtual machine and use the real host machine to run gdb).
My preferred method for tracing and debugging in the kernel is kprintf() routed to firewire (aka firewire kprintf (man fwkpfv) ). for this you do need two machines with firewire ports.
finally, being an old computer musician myself, I wonder why you want to program a MIDI synthesizer (or transformer) on the network stack level. my guess is that you would have a much more gratifying experience working in userland (where you can use floating point math...)
if you need some hints or tips, feel free to get in touch...
|K<
from the ADC Kernel Programming Guide
Kernel programming is a black art that
should be avoided if at all possible.
Fortunately, kernel programming is
usually unnecessary. You can write
most software entirely in user space.
Even most device drivers (FireWire and
USB, for example) can be written as
applications, rather than as kernel
code. A few low-level drivers must be
resident in the kernel's address
space, however, and this document
might be marginally useful if you are
writing drivers that fall into this
category.