

MIT develops new tool that can interrupt infinite loops - pgatzke
http://bostinnovation.com/2011/08/02/mit-researchers-develop-tool-to-resuscitate-frozen-programs/

======
onan_barbarian
This is a good line of investigation. I don't understand all the harrumphing
here, except possibly as a means of self-congratulations at to why the
harrumpher in question didn't bother inventing this tool themselves and how
they understand the "halting problem" in a way not known at MIT.

As the economist famously joked in response to 'how are you'... "Compared to
what?" The comparison here is to killing the program and losing all the data.

Obviously there are some big limitations on this - especially given that the
state of the program isn't necessarily entirely defined in terms of the
process itself, but also a series of possibly stateful network connections and
os resources.

Another big limitation is that a straight-up infinite loop at the level of the
binary isn't necessarily the only way that a program could get stuck - we
could be going around quite a complex loop at the binary level in response to
an _interpreted_ loop, and killing the whole interpreter isn't necessarily
going to return the program into a usable state.

That being said, what else are you going to do in this case? A number of the
alternate solutions here seem to involve time travel.

Some fun possibilities - if you can replicate the OS state, and there's no
important network state held open by the program, you can make a bunch of
copies of the broken program and try lots of different approaches. You might
also be able to fire up the program cleanly, get to the main event loop,
identify what that looks like, and just magically splice that state back on
top of the broken program in the hope that whatever is happening in global
data structures is self-contained enough to recover from.

I understand that there are many reasons why this probably won't work... that
being said, the baseline here is zero (especially if the users are made very
aware that this program isn't a safety net of any kind and don't become more
careless thinking that there's a magic 'fixit' program out there).

~~~
mcarbin
I'm one of the authors of this paper and this comment pretty much hits it on
the head. Jolt is an investigation in developing tools to help users get more
use out of their programs when the alternative is failure. Because the reality
is that there will always be programs that fail.

Most of the comments here are pretty fair about where Jolt might not be
applicable (busy loops) and how this approach could be integrated with
development; we touch on many these points in the paper (already linked by
someone in the comments).

All of our emails are on the interwebs, so feel free to ping us if you want
more information.

------
matthavener
I've done this with MS Word and the VS debugger. Word crashed while I was
editing a huge document. I simply skipped a few instructions down, returned to
Word, saved the document, and restarted Word. When your options are either 1)
crash, or 2) possibly recover to some working state, it's pretty easy to
choose option 2.

~~~
edge17
i wish i could do that for safari

~~~
1amzave
You probably can:

    
    
      $ gdb /Applications/Safari.app/Contents/MacOS/Safari $PID
    

iTunes, annoyingly, uses Apple's stupid little "please don't ptrace me" flag,
which is a minor inconvenience, but fairly readily circumventable.

~~~
jarin
I wonder if that's to make it harder to crack FairPlay.

------
interesse
Not even a single mention of the halting problem?

~~~
achompas
Noob question time: what's the halting problem?

~~~
onan_barbarian
The halting problem is an profound bit of theoretical CS well-explained on
this thread.

However, the actual halting problem is moot in most of the references I see to
it, as the halting problem is usually misused by the half-educated to make
claims that 'nothing useful can ever be inferred about the behavior of any
program, ever'.

For example, we built a tool to either estimate a reasonable ceiling on the
stack usage (whole-program) or give up; it works very well and can detect when
the structure of the program prevents this tool from operating correctly
(nasty stack mischief or stack adjustments appearing in 'unusual' places).
Quite useful for us, especially because we control the source code and know
that we don't do naughty things to our own stack.

Entertainingly, on the way to build this tool, we encountered at a couple
screeds about how this problem just plain can't be solved because it's
equivalent to 'solving the halting problem'. Well, yes - in theory, but no -
in practice.

~~~
jules
That problem gets hard very quickly when you deal with recursion. How did you
deal with that? (if you did)

~~~
onan_barbarian
We control the source code in question, so we deal with it by detecting
unexpected recursion and screaming bloody murder.

We have a 'little bit' of recursion where we know that we won't go around the
recursion more than once and we've hand-hacked that it. We have similar hacks
to deal with indirect calls.

I'm not saying we've solved the problem for arbitrary code; I'm saying that
solutions that fall very far short of solving problems for arbitrary codes are
still enormously useful. Many compiler optimizations don't work for 'arbitrary
code' either, for example, and know just enough to bail out when they see an
irreducible flowgraph or a bizarre indirect jump, etc.

------
burgerbrain
Seems to me like this sort of thing could be pretty good for advanced users
who understand it's limitations and potential failure modes, but a nightmare
waiting to happen for everyone else.

And of course I'm also inclined to suggest that advanced users would be better
off attaching gdb to the process to get done what they need to, then
coredumping and contacting the developer...

------
zwischenzug
Aren't event loops infinite loops where memory might be unchanged for a long
time?

~~~
tedunangst
Presumably the user would not activate Jolt in that case. And technically,
unless the loop uses polling, it's not an infinite loop because the program
isn't even running.

~~~
eps
Even an event-driven loop needs to cycle now and then to service timers.

------
SoftwareMaven
The only way this would be valuable for every day use would be for programs
that produce "close" output. Think of things like large scale simulations
where sub-simulations might go infinite, but if they do and this causes the
output of the sub-simulation to change, it isn't likely to cause major changes
in the macro-simulation.

Very little code is written that way, but when code is written that way, it
allows much more interesting things to happen in software and hardware both.

~~~
scott_s
I think you missed the obvious examples of content-creation applications like
Word or Photoshop, where you could interrupt an infinite loop, save progress,
then restart.

~~~
SoftwareMaven
I didn't miss them. I think those will be much harder to reliably interrupt
loops, especially around file I/O. That infinite loop was caused by bad state
and those programs (currently) don't handle bad state well.

------
sidww2
A good autosave mechanism seems to be a much better solution than this. While
that would mean the loss of a little bit of data, it seems better than saving
a potentially corrupt file or incorrectly inferring that a loop is infinite.

------
Phargo
This seems like the software equivalent of smacking a car starter with a
hammer to get it to turn.

~~~
jonsen
Well more like smacking a Toyotas accellerator to get it to stop ;-)

------
prolepunk
First of all the solution of this problem is computationally impossible so
this tool makes me feel realy uneasy I'd never use it -- it would actually
make predictable easily reproducible bugs impossible to report when this tool
is activated. It makes an assumption that infinite loops are just stuck with a
false condition and nothing else is affected by that, which I believe is
fundametally false.

~~~
adrianN
It appears to take memory snapshots. If it detects a repeat in the snapshots
it knows that the program will loop indefinitely. Of course it can't detect
_all_ infinite loops, but a sizeable subset.

~~~
_delirium
In theory I believe it can actually detect all infinite loops, for an
extremely generous definition of "can detect". On a finite-memory machine, a
computation fails to halt iff it eventually repeats a state, which it must do
in finite time, since there are only finitely many possible states (the
finite-ness is what makes the halting problem not apply). However, that finite
time might be extremely large, perhaps longer than the age of the universe. A
<http://en.wikipedia.org/wiki/Busy_beaver> function gives an upper bound on
how long it can be.

But yeah, the _practical_ use is to tell you when a computation is already
looping, for the large subset of infinite loops that result in states being
repeated relatively quickly.

~~~
rcfox
> On a finite-memory machine, a computation fails to halt iff it eventually
> repeats a state

This is too strong of a statement. Lots of software simply loops, repeating
the same state over and over, until an external interrupt occurs.

~~~
_delirium
Good point; I guess I was thinking of the simplified textbook case of
computations with no external interaction. I wonder if this MIT system is able
to exclude the most likely false positives, like polling for input? On the
other hand, maybe polling too long for input counts as an infinite---or at
least, too long---loop for their use-case of interrupting user programs that
seem to be hanging, so that the user can save.

------
nickdunkman
I think the better way to do this would be to throw a "JoltException" which
you could catch in your program if you wanted to, like any other exception.

It seems like it'd be a huge mess to try to write code succeeding the loop
which tries to handle the case where your loop code didn't complete like you
expected it to.

------
spambot
OP looks like a spammer for bostinnovation.com:
<http://news.ycombinator.org/submitted?id=pgatzke>

~~~
civilian
There's a fuzzy line between spammer & contributor.

~~~
spambot
I made the comment because Reddit has some bostinnovation.com spammers:
<http://www.reddit.com/user/joeymullette> &
<http://www.reddit.com/user/chezral>

I'm guessing they have employees who just post to social news sites.

------
jheriko
my experience from debugging is that breaking out of a loop in this way is
very hit and miss - coupling that with my experience of common office software
failures being hard crashes rather than hangs and i can't imagine this tool
being /that/ useful. I'd much rather have a tool that does autosaving at a
very regular interval - I've written many throwaway tools for that in the past
mostly when dealing with old versions of excel being abused to solve
database/code problems... still this is better than nothing i guess

as for the nature of the halting problem meaning this can't work??? that only
displays a lack of understanding...

all in all this article and the comments reinforce my view that academia
diverges too far from the practical realities of software development. sure we
need academic research and education, i won't deny it, but the noise making
should be reserved for after practical success has actually occurred.

------
malkia
It's common for the runtime of game scripting language to have infinite loop
detections - for example if loop takes more than 5ms and hasn't reached (or
called) specific point/mark then it's reported, stopped or restarted.

But going to the next line...

------
adamdoupe
Link to the full paper for those interested:
<http://people.csail.mit.edu/rinard/paper/ecoop11.pdf>

------
netmau5
TLDR: Power button or inconsistent results, now you can choose.

------
brandonwang
What if you wrote an infinite loop, and wanted it that way?

There are plenty of legitimate uses for an infinite loop, a REPL, a server,
etc.

~~~
AltIvan
Oh look! there is a little note: "Do not use if you need an infinite loop not
to stop."

------
mhd
The RunStop key?

------
chrisfarms
Can't think of a use-case for this? .... maybe if you have some seriously
"legacy" process running somewhere that loves to stall but patching is not an
option for some obscure reason? ... space probes?

------
MostAwesomeDude
I thought the message at the end about people expecting full correctness was a
bit off; after all, if we expected fully-correct programs, we would be proving
them instead of writing C.

~~~
ezyang
They're poking fun at the formal methods community, which spends a lot of time
doing research in this direction. Percolation of these techniques back to
industry has been... less than stellar.

