top | item 2492730

Found a nice bug in IOS today, bricks your phone and kills the Simulator

50 points| jimsteinhart | 15 years ago |pastie.org | reply

31 comments

order
[+] Fjanth|15 years ago|reply
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.

[+] gedekran|15 years ago|reply
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.
[+] demallien|15 years ago|reply
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...
[+] gpambrozio|15 years ago|reply
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.

[+] schrototo|15 years ago|reply
Does it really "brick" your phone, as in "makes it crash in a way that is completely irrecoverable and that can never ever be repaired, therefore turning your phone forever into a piece of hardware comparable in functionality to a brick" or does it just make the phone crash?
[+] gedekran|15 years ago|reply
People use bricked incorrectly way too often. Leading to others wondering if they actually mean it is as functional as a brick or that it just crashed and thus can be rebooted or restored.

Then again I haven't personally bricked a device in a long time.

[+] TillE|15 years ago|reply
I'll accept "brick" when recovery requires flashing via JTAG. But not when you just have to press a few buttons.
[+] tomjen3|15 years ago|reply
I am not an iPhone developer, but the code doesn't seem unreasonable to me.

Can anybody explain what is special about this code?

[+] JoachimSchipper|15 years ago|reply
It's a function that configures ten timers to call itself. So it causes an exponential number of timers to be set.
[+] napierzaza|15 years ago|reply
It creates 10 copies of an alarm on the same date with a setting to repeat twice. So I imagine 10 alarms firing at the same time is not a good idea. I don't see where it calls itself like other people are saying.
[+] mrcharles|15 years ago|reply
For people lost in the thread, I've read the whole thing. The actual problem here as posted by the guy who found it (Fjanth in this thread) is that setting a local notification with a repeat value of era breaks iOS and requires a factory reset in order to recover.