I'm using
security find-identity -v
command, but it works extremely slow on Mavericks (on 10.8 it was working much faster).
I've tried it without -v option without any luck.
Is there any other options to get such list, or how can I speed up the security utility?
I think it should be possible because when I open KeychainAccess.app it shows all identities (about 60) in about 2 seconds, when security util making it in 2 minutes.
Ok, I've ended up in writing my own utility which is using Security.framework.
Works like a charm, and very quickly!
Related
I have been developing with React Native for some years now but the following behaviour only started recently. After running any React Native app on the iOS simulator (either directly from Xcode or via react-native run-ios) the diagnosticd process slowly increases CPU usage to 150% after a couple of minutes. My laptop becomes unusable because the process is also eating up all file handles of the OS. Googling around only points to excessive logging, but either I'm not looking in the right location or no huge amounts of logging is taking place.
Closing the app by pressing the Home button in the simulator immediately stops the high cpu load.
Is anybody also experiencing this? How can I find out what is causing this?
MacOS Catalina version 10.15.3, Xcode version 11.4, React version 16.9.0, React Native version 0.61.5, Simulator iPhone 11 (iOS 13.4)
I think I found the solution. Xcode was logging a lot of lines containing: xcode nw_connection_get_connected_socket Client called nw_connection_get_connected_socket on unconnected nw_connection. This started after some update of Xcode a couple of months ago. Disabling the logging has stopped the diagnosticd process from eating up all OS resources. I followed these instructions: Hide strange unwanted Xcode logs
Basically comes down to adding an environment variable OS_ACTIVITY_MODE with value disable to the Scheme (Run).
What the real reason for the logging is I still don't know. It looks like some sort of polling from React Native.
It's more of a workaround than a solution, but it seems that resetting the simulator to factory default temporary fix this problem (at least on my case).
It looks like diagnosticd is processing some files which may be located on the simulator internal memory, so it may takes more and more cpu as the files are growing over time ?
Anyway try to go to the simulator menu : Hardware -> Erase All Content and Settings
Then close the simulator and start it again from XCode in order to copy your app on it.
workaround from Xcode 9.3 Playground - diagnosticd,
kill $(ps -ef | grep Xcode.app | egrep "diagnosticd|homed" | awk '{ print $2 }')
I found this to be useful
Finally found the solution! I was always wondering why the default url in AppDelegate.m did not work. So I started focusing on that. It turns out that my huge adblocking hosts file was the cause of this. Restoring the original /etc/hosts file solved both problems! 🎉
One more thing you can try, this is a very drastic measure and only do this at your own risk,
first try this,
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.diagnosticd.plist
and if you get a message about system protection (SIP),
you can try turning off SIP, then running that command again,
That will pretty much guarantee diagnosticd never run's again... no idea about the implications of that though...
read more about those two things here,
https://makandracards.com/dev/16439-disable-daemons-services-in-mac-os-x
https://www.imore.com/how-turn-system-integrity-protection-macos
*disclaimer, this is probably not the safest solution messing with SIP, but I did it on my old 2015 i5 macbook because I was getting desperate, and literally couldn't do any work on simulator with the diagnosticd bug.
So far everything seems happy...
I have tried both Bear and CompileDB to generate compilation database JSON from makefiles. However, it turns out that both of them generate useless empty JSON files on my mac.
Bear acknowledges this problem in its list of known issues.
Security extension/modes on different operating systems might disable library preloads. In this case Bear behaves normally, but the result compilation database will be empty. (Please make sure it's not the case when reporting bugs.) Notable examples for enabled security modes are: OS X 10.11 (check with csrutil status | grep 'System Integrity Protection'), and Fedora, CentOS, RHEL (check with sestatus | grep 'SELinux status').
Now, turning off SIP just to run one small program is not a good workaround. Do you know of any other way I can generate a compilation database from a given makefile?
Have you investigated why compiledb failed? Under the neath, it parse the compile commands that make "print" out while building.
If you have the output of make --print-directory -n, your can also generate the json file here: https://texttoolkit.com/compilation-database-generator, it basically works like compiledb, but as a web app.
I Used to change my Mac Adress in Open Networks with the command:
ifconfig eth0 ether 00:11:22:33:44:55
in iOS4 this was no Problem, i remember there was even an App on Cydia for that. For ifconfig i instaklled network-tools from BigBoss Source.
Since iOS5 the Command is going thru Terminal without any error, however the MAC-Address isnt changing anymore... Someone a Idea on how to change it?
It's possible. For some reason, spoofing it in iOS 5 won't work (either via command line or MacX4), but you could always rewrite it in hardware. There are several cons to this and this is not worth during unless you absolutely have to: it will break your music player (so you have to use VLC or the like), is permanent even after reboot, and effectively changes your UDID (so betas will not work and the device will be unregistered).
nvram wifiaddr="XX:XX:XX:XX:XX"
Again, the cons definitely outweigh the pros here. I'm sure eventually someone will come up with the software to do a spoof, not a total rewrite.
It can be done. My iPad running 5.01 has an arbitrary MAC. There are no restrictions as far as playing music, and I am still able to access Apple services (at least those that I use personally) without hindrance. It's a moderately tedious process, but after a bunch of failed attempts I was able to successfully (and permanently unless I decide to repeat the process using my originals) change the values with a combination of terminal commands, DFU/recovery cycles, OSX apps, and a clean restore via iTunes. If anyone is still interested, I would be willing to outline the process. I would do so now, but I have to hash out some specifics concerning the iTunes host file.
Because the MAC address is unchangeable for a reason?
Here is what I want to do:
I want to run Mathematica on another Mac from my Mac (both Snow Leopards). I want to do this because the remote Mac has multiple cores/processors while my local Mac is rather shabby. I would like to have the front end still locally (i.e. the graphical interface).
What I've learned:
I used to do this type of thing from multiple Linux machines and was expecting to have similar success for Mac-to-Mac operation. However no such luck.
The problem seems to be a display issue (front end).
Mac front end runs in Aqua while X11 is what is really needed (this is why there is no problem on Unix). While Macs have X11, for some reason Mathematica can't use it.
So how do I get around this issue?
Possible solutions that I have had to rule out are: 1. screen sharing. Not practical since someone else will be using the remote Mac on another account. Screen sharing only uses the active screen. 2. Installing Unix on the remote computer. Not possible in my situation.
Thanks.
You should be able to set up a remote kernel on the other Mac. This is done through the Evaluation > Kernel Configurations menu item. The you can set the remote kernel for a given notebook using Evaluation > Notebook's Kernel or globally via Evaluation > Default Kernel.
I haven't done this in a while, and it's sometimes useful to test things from a terminal with something like
ssh <user>#<remote.machine.com> </path/to/remote/Mathematica.app/Contents/MacOS/MathKernel>
Why not use the command line kernel? I have a script math which does:
#!/bin/bash
rlwrap /Applications/Mathematica.app/Contents/MacOS/MathKernel
I built rlwrap from source, but basically that tool gives you readline behaviors. You can just do
ssh remote-machine /Applications/Mathematica.app/Contents/MacOS/MathKernel
The only solution, I believe, is for you to upgrade to OS X Lion. It allows simultaneous screen sharing sessions where each user can control the screen for their own account:
http://www.apple.com/macosx/whats-new/features.html#screensharing
I've got a user reporting crashes in my Mac OS X application, and their console logs report the following:
Symbolication warning: error parsing FDE at 0x100052649 in:\n
Does anyone have any insight into what this might be? I assume that somehow the symbols have been stripped from my app in a way that gets in the way of Mac OS X's crash reporter, but I've not seen it before.
I can honestly say that I have never seen this one before. I have seen a number of other dynamic linking problems just not this one. If the user is amenable to helping you with this defect, you might want to write a shell script to enable some dynamic linking environment variables and then launch your application.
#! /bin/bash
export DYLD_PRINT_LIBRARIES=1
export DYLD_PRINT_LIBRARIES_POST_LAUNCH=1
export DYLD_PRINT_APIS=1
export DYLD_PRINT_BINDINGS=1
export DYLD_PRINT_DOFS=1
open -a Console.app > /tmp/link-log 2>&1
The output log might provide some hint as to what is going on. You could also capture the output of otool and other command line utilities to check for unexpected libraries and what not.
You might want to google Symbolication to get a better handle of what is going on here. I came across an interesting chunk of code from Darwin that points this to a dynamic symbol lookup warning. There is also a utility called Shark that may be of interest as well.
Good luck...
I just found this topic via Google because I'm having the same problem. The StarCraft installer crashes immediately. It points to /usr/libexec/oah/translate, which seems to work perfectly well. My guess is this has something to do with the fact the computer it doesn't work on runs iDeneb 1.3 (aka Mac OS X 86 for use on non-Apple hardware), whereas the computer that can run the application just fine has a genuine version of Leopard.