Archive for May 17, 2015

Sunday, May 17, 2015

How Not to Crash #2: Mutation Exceptions

Brent Simmons:

You get a collection from somewhere and enumerate it — and then you get an error about the collection being mutated as it was being enumerated. The app crashes.

[…]

You might push back, citing performance or memory use issues or both — but I’ll admit something: I’m a performance junkie, and I spend an inappropriate amount of time in Instruments making sure things are fast and use a non-weird amount of memory. And I’ve never, ever found this to be a problem. If your app has performance or memory use issues, the problem is something else, not these copies.

[…]

There’s a general point: if you’re getting a collection from code that isn’t yours, it doesn’t hurt to be defensive and enumerate a copy.

Swift does something similar automatically, although it probably doesn’t work when enumerating an NSArray that you receive.

The Rush to “Deprecate” HTTP

Dave Winer:

Google and Mozilla and others want force all non-HTTPS sites to become HTTPS.

And while the name HTTPS sounds a lot like HTTP, it’s actually a lot more complex and fraught with problems. If what they want to do ever happens, much of the independent web will disappear.

[…]

Given that a vast amount of content likely won’t move, Google and Mozilla are contemplating far more vandalism to the web than any of the ISPs they’re trying to short-circuit.

[…]

[The tech industry is] run by people who shoot first and ask questions later. This is an awful way to be having this discussion, after the decision is made, without any recourse?

Update (2015-06-16): Dave Winer:

In the tweet, people thought I was writing about protecting whistleblowers, or circumventing the control of the entertainment industry, both worthy causes. But what I am protecting is much more fundamental -- the right of the people to use the web as a space to speak their mind without interference from government and corporations. It’s as fundamental as the First Amendment of the US Constitution. I’ve created dozens of websites over the 20-plus years I’ve been writing on the web that don’t support HTTPS and never will. It would be too much work, and too expensive, and would cede control of the content to yet another administrative body. I refuse. You should too.

Brent Simmons:

The problem is the other two apps. They all rely on the open web rather than servers controlled by the app writer. And it would be unacceptable to limit those apps to https only.

Let’s also consider my two secret-project Mac apps. Both of them need http access — they’re not limited to servers that I (or some corporation) control.

Since neither app will be sandboxed, I’ll be able to do this without Apple’s approval. My concern, of course, is that this situation won’t last.

Phantom iPhone “Photo Library” Storage Usage

My iPhone has been nearly full for a while now, and I’m in the process of switching away from Apple’s photo ecosystem, so I have been deactivating various features to free up space. I stopped syncing photos from iTunes to the phone. I deleted shared iCloud photo albums. I turned off Photo Stream. I emptied the Camera Roll using Image Capture. I deleted the contents of the Recently Deleted album. I deleted the contents of Photo Stream from Aperture.

At this point, I expected Settings ‣ General ‣ Usage ‣ Manage Storage to show very little spaced used by Photos & Camera. In fact, it was still using lots of space, second only to Overcast. Shared Photo Stream and Synced from iTunes Library were close to zero, but Photo Library was using lots of space, even though there were no photos shown in the Photos app.

Rebooting the phone did not help. For a third-party app, I could have cleared the data by uninstalling and reinstalling the app, but there doesn’t seem to be any way to do this for the built-in apps. Resetting the entire phone and restoring from a backup did not help.

I found several threads in Apple’s forums about this issue. An intriguing suggestion was to set the phone’s date to the past in order to make old photos reappear in the Recently Deleted album and thus be available for deletion. This didn’t help either.

I ended up looking around using PhoneView (which still works for photo data) and found two major consumers of space:

Since I no longer needed any photo data on the phone or in iCloud, it seemed safe to delete these files. Indeed, that seems to have gotten rid of the phantom Photo Library usage. My phone now has a comfortable amount of free space.

Debugging launchd

wuntee.sexy (via Hacker News):

The reason I had an interest in debugging launchd is because I had been able to trigger some crashes. launchd is like init for linux; the kernel spawns it as PID 1 and every process is executed under it. When launchd crashes, the kernel panics, and your machine reboots with the “there was a problem, press any key to continue” screen. User-land triggering kernel bugs is obviously interested due to the trust boundary crossed.

[…]

From everything I had read about other launchd crashes, there should be a crashdump file like any other process, however from the launchd re-write, I can only assume Apple had disabled that feature. In turn, you get a semi-useful /usr/bin/sample output located in the /var/log/com.apple.xpc.launchd/ directory. Although this gives a bit more information than the kernel panic, I still am leaps and bounds away from finding the root cause of these crashes.

[…]

My next thought was to move to kernel debugging, and try and catch the crash before it jumped into the kernel. […] When dealing with kernel crashes, having to reboot and re-attach every time became quite annoying, so I found myself using the flags that waited for the debugger upon panic.

[…]

I ran a simple dtrace script to perform a stacktrace on launchd upon it crashing, redirecting the output to a file (this can be done as a one-liner) […] And voila! I now had a specific location, within launchd, of where this crash is occurring. That being said, it was still quite hard backtracing to understand exactly why the crash occurred.