

Found a nice bug in IOS today, bricks your phone and kills the Simulator - jimsteinhart
http://www.pastie.org/private/orzgwxc2ax80vrs8v0rew

======
Fjanth
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.

~~~
demallien
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...

~~~
Fjanth
OP:Nope, you didnt read the code. Try reading the other version I posted.
Works without a loop as well.

~~~
demallien
errr, that's what I said...

~~~
Fjanth
Which is why I wrote "OP" in front :)

~~~
demallien
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?

------
schrototo
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
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.

~~~
repsilat
> Heretofore, "to brick" can brick _anything_.

[http://apple.slashdot.org/comments.pl?sid=423338&cid=221...](http://apple.slashdot.org/comments.pl?sid=423338&cid=22102564)

~~~
GrandMasterBirt
I have to say, I once came fairly close to bricking my router. However after I
realized the router was complete and utter garbage I put the brick to it, so
now it is officially bricked, office space style.

------
Fjanth
Also here is a nicer version that still triggers the bug
<http://www.pastie.org/private/8a48wgmcuuhjjwbupbk3g>

~~~
flog
So what's the bug then? If there's no loop here?

~~~
Fjanth
alarm.repeatInterval = NSEraCalendarUnit

Triggers the bug, its totally valid as well.

~~~
revolvingcur
So basically the repeatInterval is expected to have one of the values of an
enumeration assigned to it, where the enumerated values are calendar units
(representing daily, weekly, monthly, etc.), and it somehow mishandles the
value representing "once-per-era"?

~~~
Fjanth
That would seem to be the case.

------
tomjen3
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
It's a function that configures ten timers to call itself. So it causes an
exponential number of timers to be set.

~~~
Fjanth
Thats not the bug though. Can do it without a loop as well. This was an old
version, check the other one I posted here in this thread.

~~~
JoachimSchipper
Ok. I would be very grateful for an explanation, then. ;-)

------
mrcharles
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.

