Hacker News new | ask | show | jobs
by Fjanth 5528 days ago
Im the original poster, that found the bug. Nah it doesnt brick it, it does however require (atleast on 4.1. for me) a factory reset.

The problem seems to be that springboard locks up in an endless loop, restarting the device wont help it because its still loading the offending notification from the cache.

3 comments

More apt would have been that it disables your iphone temporarily until a factory reset or restore is performed. Saying it bricks it causes me to think back to messing up the flashing of firmware on a device and the device never working again.
Yeah, I know. Its to bad though because all the discussions are turning into discussions about the proper use of "bricking".
Well, I'm pretty sure that getting "fscked" is not that bad. I mean, running file-system checks is probably a good idea to do periodically.
Wait. Is it really an endless loop, or just a queue that is getting filled up faster than it empties resulting in a more DOS-style problem? Because it sounds much more like the second case, in which case not only does it not brick the phone, but it isn't even a bug...
OP:Nope, you didnt read the code. Try reading the other version I posted. Works without a loop as well.
errr, that's what I said...
Which is why I wrote "OP" in front :)
In the post that I replied to, you said that Springboard is getting into an endless loop. Having looked at the code that you posted, I commented that it doesn't look like an endless loop but more like a denial of service type problem, to which you replied that I should read the code, and that it doesn't need a loop, which was just repeating my point about it not appearing to be a loop!

Ahhh, I give up. Just try reading what I wrote before replying, mkay?

If you try hard enough you can always find a piece (or many) of code that will "brick" (using your definition...) your device (whatever that is). I don't consider this a bug, or not a serious one at least.

And in this case Apple's approval process could protect the consumer. They would never let something like this past the gates.

If a sandboxed application can get the sandboxing environment into a state where the only way to get the sandboxing environment working again is by restoring it from a backup, that is a serious defect in that environment.

Also, since this issue is very trivial to trigger, it's not very difficult to hide the triggering mechanism in a malicious application in a way that even a reasonably thorough source code inspection would not necessarily spot it. See also: The Underhanded C Contest.