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?
Related
When using a mobile Android Wi-Fi hot spot on macOS Catalina and MenuMeters utility to see total mobile traffic I noticed that every time I launch iOS Simulator (tested on iPhone Pro Max and iPhone SE 2nd generation both with iOS 13.5) it starts downloading huge amounts of data (approx. 450-800 MB) on every launch, so it gets rather expensive. I know that's Simulator because when I quit it traffic stops.
So I'd like to find out what and why Simulator may download maybe to try to block/work around this expensive operations.
I tried to use Charles and Proxyman to detect addresses Simulator could connect to - but with no avail, I cannot see this hundreds of megabytes there. Another option was Wireshark, but I do not know how I could use it to get what I want (as I imagine it should be some addresses from where Simulator could download data).
Could you please give me some advices how to get needed info with these applications or in some other way.
Edit
Thanks to accepted answer and Little Snitch I was able to catch and block "evil" connection
If it's not appearing at all in Charles or Proxyman then it's probably not being sent over HTTP. Wireshark will show the raw TCP & UDP connections, but it's very complicated if you're not familiar with it, and there'll be a lot of info there.
One good option for this is Little Snitch. It does exactly what you want, and can show you exactly who every app is connecting to and how much traffic is sent. It normally costs $30, but they let you try it out for free, and a quick check should be all you need.
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)
The setup:
OSX Yosemite.
Ableton Live 9 (Suite).
Crossover/Wine (14.0.3).
Connected device is a Novation Launchpad Mini (USB).
The problem:
The install of Ableton and most of its use work well. I have compiled and successfully installed wineasio.dll (wineasio.dll.so) to obtain low latency audio, again this works extremely well.
But what I am finding is the communication between the LP and Live is somewhat sporadic. examples of this are, having to list the LP in the midi in/out section of live multiple times just to get it to behave correctly (mostly), pads/lights randomly lighting/becoming non responsive, active tracks not showing (lighting up)
There is no pattern in all this. bug what i can say this setup works without problems in windows and OSX (obviously)
before you ask I'm having to use WINE as one of my favourite VST's is only windows based.
if someone can recommend a VM based solution (with low latency audio/ Midi) i will welcome it.
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.