This also affects Mobile Chrome on iOS.
Still seeing this too. Even though sourcetree claims it's not responsible in the error, it unfortunately is. This generally happens after having Sourcetree open for a few days, and happened on both Sierra and El Capitan.
Anyone encountering this, to see the number of open files and which process is responsible, run this in your terminal:
lsof |cut -b1-16|sort|uniq -c|sort -n | head -n 5
And you'll get the top 5 of apps using file descriptors:
4655 SourceTre 7898
667 Google 1624
379 Finder 445
375 Dropbox 455
336 Adobex20 504
SourceTree has 4655 open files (7898 is the process id)
Inspect shows a lot of files like this open:
The names between /T/ and Before match the paths of files iny my repository, and I see many of these files being opened multiple times
The most straightforward way to handle (workaround) this scenario is to add this code to the host VC:
which will cause the layout pass that is fired during the rotation event to also include the layout invalidation.
There will be 2 invalidation passes.
Sure I can. As I mentioned in my update already, the problem is that initially the account panel correctly recognizes that this is an IMAP account, which it really is(!), but then it adds the account as a POP3 account (as I also saw in Mail) and there is no way to change it to IMAP thereafter.
'IMAPgoesPOP3.m4v' was successfully uploaded.
We cannot reproduce this issue.
Can you please provide detailed reproduction steps and a screen recording showing the issue?
Please provide your response or results by updating your bug report.
This bug is actually related to the bug 24437353. When adding the account, it is recognized to be an IMAP account, thus I can choose to also use it for notes, but then it is added as a POP account and as such an account doesn't support Notes anymore, this option has vanished. Okay, something goes seriously wrong here.
Sorry for the delay. I installed the profile, made a reboot and ran sysdiagnose. File is attached. Note that I had 556 iMessage keys prior to boot and 560 after next boot, another 4 keys. Just as I expected: 4 keys are generated on every reboot.
What I don't quite understand is why you need that information. I can reproduce this issue on all my Macs! Doesn't matter if MacBook Pro or Mac Mini, they all show the very same issue, they all keep growing the number of iMessage keys and these are cloned systems, every system was a fresh install. I highly doubt that this issue is specific to my system setup. And I'm pretty sure that you can also reproduce it with your Mac. If anything, this issue may be specific to my Apple ID, as all these computers share the same Apple ID.
We need more information to investigate this issue.
Please grab logs using the attached profile. (Profile attached to email)
Install the attached profile
Reproduce as you have been
Run: sysdiagnose (in terminal)
Then attach that output please.
> Do you retain returnEventDescriptor?
No, I don't retain it. And I also don't see how that would play a role as retaining it would not cause a leak as long as I also release it. Also it's not returnEventDescriptor itself that instrument considers leaking IMHO.
> Does its autorelease pool get released before you check for leaks?
You saw the stacktrace? The code runs within a block scheduled on a GCD queue and queues implicitly have an autorelease pool.
Whether it was drained already at that point? I don't know, but again, how would that matter? If there is an autorelease pool that sill has a reference, how would that be a leak? A leak is allocated memory to that no reference exists. Something in an autorelease pool has never been considered a leak by any tool I've ever used.
> What does your script do? Does it contain any AppleScript/Objective-C code?
I doubt that this is really relevant as nothing the script does or can do should cause a leak. Here's the script, full source (really, that's the whole script!):
tell application "System Events"
get properties of every login item
> Do you see the same leaks if you run the script in Script Editor or with osascript?
No, I don't, but who says these tools even use "NSAppleScript" at all?
> Can you attach the Instruments recording?
Not sure if I can, it gives quite a lot away from our software and I really don't know what you intend to find there.
16-Nov-2016 07:02 PM
Do you retain returnEventDescriptor? Does its autorelease pool get released before you check for leaks?
What does your script do? Does it contain any AppleScript/Objective-C code?
Do you see the same leaks if you run the script in Script Editor or with osascript?
Can you attach the Instruments recording?
Please provide your response or results by updating your bug report. If uploading files, please compress first.
Duplicate of 29916461 (Open)
Some methods in AppKit, such as -[NSPathCell autoUpdateCellContents] contain calls to -[NSURL(BRCloudPathComponent) brpathComponentDisplayMetadataWithOptions:].
This works in 10.10 because CloudDocs.framework, which is where this method is actually implemented gets linked in. But it looks like CloudDocs.framework doesn't get linked on 10.11, and this ends up getting a "unrecognized selector" crash.
Steps to Reproduce:
Run this code on a 10.11 system:
NSURL *url = [NSURL fileURLWithPath:[@"~/Library/Mobile Documents/2BUA8C4S2C~com~agilebits~onepassword" stringByExpandingTildeInPath]];
Replace the last part of the path with a valid URL inside of Mobile Documents.
Not a crash.
Crash. I've attached a real world crash report, as well as one from my sample code, as well as my sample code.
Mac OS X 10.11.0 (15A282a)
This is a regression. The crash does not exist in 10.10.5.
Hardware seems irrelevant. Only OS X version.
I had a similar problem today, I was on a train and put in one Airpod then pressed play on iPhone and the music came blasting out of the iPhone speaker instead of the iPhone. So I had to manually connect the iPhone to to the AirPods which took about a minute. Then putting second one in ear there was no sound and no way to manually connect it. It started working on its own after about 2 minutes.
Screenshot can be seen here:
Apple engineering pointed me into the right direction to solve this problem. Seems that on iOS 10 apps must always be registered for remote control events in order for CarPlay to work.
Bluetooth logging and a timestamp provided: 21-Nov-2016
I'm having the same issue right now, where old sandbox accounts work fine, but new ones are failing. I'm also receiving the "New Password Required" screen, however it loops around to an endless loop and never updates the password. I'm unable to login to any new sandbox accounts to verify an in app purchase.
GitHub project at https://github.com/dlo/Radar30018587