I'm sandboxing my Mac app, and am using the Security-Scoped Bookmarks feature of OS X 10.7.3 to persist references to files outside of the app's sandbox. All my code appears to function correctly, but I end up with the following message repeated hundreds of times in the app's output (for a relatively brief operation).
scoped bookmarks agent connection interrupted
Is this a problem? It makes me think I'm doing something the wrong way, but I'm not sure what that might be.
No, you shouldn't worry. At least according to Apple employees.
If you have an Mac Dev Center membership, see this thread on the forums for details.
If you don't, probably nobody is allowed to tell you the details, because the thread is in the NDA section of the forum. (Even though it's a Lion feature, and this question is specifically about 10.7.3, the Application Sandboxing forum is part of the Mountain Lion section…)
EDIT: As Dov pointed out, Mountain Lion has been public for quite some time, so the thread is no longer in the NDA section of the forum. (The Application Sandboxing forum has been moved into the Deployment forum, which I believe anyone can access.) You should be able to just follow the link for more details.
But the relevant part, from Apple employee Aerie, is:
This is harmless. The agent aggressively idle exits, interrupting idle connections. Since you're holding your process frozen in the debugger, the connection to the agent is idle.
It's unexpected, but yes, still harmless. We'll take a look at what might be causing the output so frequently.
I don't know whether or not there have been any fixes. I personally haven't noticed it as often under 10.8.2 and 10.8.3 beta as I did under 10.7.3 and the 10.8 PRs… but then I'm not developing the same code, and probably not paying as much attention.
Related
In MacOS Catalina, you can still work around the notarization and signing requirements to download from anywhere by running
sudo spctl --master-enable
With the new security features in Big Sur, which I cannot try myself, I am concerned that the workaround might disappear. Can you still, at your own risk, run binaries that you compile yourself or download from elsewhere, by using this command?
The answer to this question might also be different on Apple Silicon ARM chips, which aren’t available to anyone without a limited-supply transition developer kit. In the off-chance that someone with one of these kits sees this post, what are the options for restoring the ability to download and build without gatekeeper blocking and requiring notarization? This is really important to know for internal development.
Also, ignoring all the risks, let’s say my computer is on a local secure network and I am only downloading, sharing, and compiling things I KNOW are safe by communicating with the developers. A lot of responses to questions like this that ask about disabling security seem to dodge the question and tell me not to do it, but I promise that I am cautious.
Just upgraded my 2015 MacBook Pro to Big Sur. Running sudo spctl --master-enable still works.
I recently noticed some frustrating issues on mac. my program simply, silently quits, without any error message and crash report.
I think the crash reporter is enabled, as I can still see it with some other access violation bug. I don't know how to debug this issue without a call stack dump. I had to put logs everywhere and I then realized that the program doesn't always quit at the same place.
the issue seems to be related to sockets, I'm not sure. I kinda think this is an OS bug, because if it is really my program that crashes, I should see the crash reporter. Also, I couldn't reproduce this issue with mac 10.8.5, but I could reproduce it with 10.9 and 10.10.
are you aware of an OS bug that may related to this? how am I suppose to approach this issue?
right now i am running the OS X Yosemite beta 10.10, after upgrading my OS X i lost my camera, i tried everything in the forums, but nothing helped.
i can't FaceTime, or Skype or anything. normally i would take it in to an apple store, but the closest apple store to me is about 200 miles away.
since i am beta testing OS X Yosemite, i knew i was going to have some problems, but i need this to work
also; i also installed the update 2 days ago as it was recommended in the app store.
(not a hardware problem, was working perfectly before the upgrade and it is not found in the "system info> USB"); also not user specific.
Open your terminal and type this command:
$ sudo Killall VDCAssistant
Now, go to your Skype->Preferences->Audio/Video and you can see the webcam working.
Have a good one!
Apparently, this problem persists even in the recent versions of OS X Yosemite. I also had this problem. So, the answer to solve it is basically resetting the SMC, which Apple provides instructions in https://support.apple.com/en-us/HT201295
Now, I was not able to sort it even by resetting the SMC in a Macbook Pro 15 mid 2012. At least, not immediately. As I keep a few things connected in the USB ports, I believe it might have been the reason, so I closed all my applications (just in case), turned off the computer, unplugged all the USB and thunderbolt connectors (yes, including the LAN adaptor), as well as the earphone connector to speakers. THEN, reset the SMC (for non-removable battery computers, by pressing and releasing control-shift-alt-power [left shift] simultaneously while connected to power). For me, it worked.
It might be useful to remember that the SMC is the System Management Controller, that takes care of the hardware in a low-level, including i/o, keyboard backlight, speakers, camera... so, if you are going to reset it, it might make sense to release all the possible burden it might feel.
Resetting SMC is the only thing that solved the problem on my MBP Mid-2012.
The issue came about around the time I upgraded to High Sierra.
This issue is solved with the newest update of OSX Yosemite. Just update through the Appstore app and everything will be normal.
Shark started crashing on me when I use the "Processor Bandwidth (Core 2)" mode of analysis. It collects the samples, spends the time to analyze them, and crashes with a bus error about when the window should come up.
First I thought it might be because I've been running on low memory. I installed the latest system updates, rebooted, tried again. No difference. Installed latest XCode, no difference. Used CHUD Remover, reinstalled Shark, rebooted, no difference. Tried building with symbols and without.
All the other analyses work. I don't have any third-party KEXTs and never had problems with this before.
Has anyone else seen this? Is there another forum where I can ask this kind of thing? (Apple's dev forums require a $500/yr support package!) Is there a verbose mode for Shark, perhaps via command-line option?
You might try the apple perfoptimization-dev mailing list.
Even if this turns out to be an easily solved issue, please file a bug. You need to have a developer account, but a free account is fine.
Hey! I think this is a simple question for you. Most of the system apps and also some third-party apps have integrated a CodeSignature in their bundle. I heard with such a CodeSignature the system would not ask anymore for accepting incoming network connections (if the firewall is enabled). Now the question is where to get such a CodeSignature...
Thank you for your help!
Where and how to get code signed?
See Code Signing Guide:
Code signing is a technology
introduced in Mac OS X v10.5 that
ensures the integrity of code and
allows the system to recognize updated
versions of code as the same program
as the original. Once you have signed
your code, any change in the code that
you did not intend—whether introduced
accidently or by hackers—can be
detected by the system. On the other
hand, your signature on an updated
version of your program tells the
system to treat the new version
exactly as it treated the old, so that
users are not bothered with obscure
dialogs asking them to give permission
to the keychain or some other system
component to interact with your code.
Signing code is fast, requires few
resources, and increases the size of
your deliverable by less than 1%.
Signatures do not alter how your code
runs and are ignored by Mac OS X
versions prior to Mac OS X v10.5;
therefore, there is no reason not to
sign your code. However, there are a
few things you need to know before you
begin. This document explains the
terminology and concepts you need to
know and gives you a few
straightforward procedures you can
follow to sign your code.
Because the system will expect all
code to be signed, any code that is
not signed will not behave in the same
manner as the majority of the programs
on the user’s system. In particular,
the user is likely to be bothered with
additional dialog boxes and prompts
for unsigned code that they don’t see
with signed code, and unsigned code
might not work as expected with some
system components, such as parental
controls. It is highly recommended
that you sign all code intended for
use with Mac OS X v10.5 or later.
Therefore, if you are delivering, or
intend to deliver, code that might
ever be run on Mac OS X v10.5 or
later, you should read this document.
Code Signing Guide