Jolt framework lets users force some hung programs to recover

A group of MIT researchers have developed an experimental software framework that can detect when a program has entered an infinite loop in some cases and give the user the option of forcing the loop to end. Ars explains how it works.

<a href='http://meincmagazine.com/science/news/2011/08/jolt-framework-lets-users-force-some-hung-programs-to-recover.ars'>Read the whole story</a>

 

[BigDH]

Gee MS haven't you heard of a WatchDog timer process to monitor your app for such things.

The fact someone has to offer a snippet of code to do do this is also a surprise. Coders should know about WatchDog systems either during development (a.k.a. breakpoints) or what to put into their apps to breakout of loops.

 

[princec]

Aha great, so now programmers are absolved of the need to write working programs using such outdated techniques as testing. We can just get the users to debug them on the fly. Brilliant!

Maybe a better approach would be for developers to actually act in a timely fashion to bug reports. And maybe have apps that are force-quit send stacktrace data somewhere for analysis.

 

[mexaly]

This brings the halting problem to mind. Eventually this road will face into Turing's roadblocks.

 

[Donnicton]

Aha great, so now programmers are absolved of the need to write working programs using such outdated techniques as testing. We can just get the users to debug them on the fly. Brilliant!

Maybe a better approach would be for developers to actually act in a timely fashion to bug reports. And maybe have apps that are force-quit send stacktrace data somewhere for analysis.

Properly tested code will be a DLC that you can pay a nominal fee for the privilege of using. Otherwise, we encourage you to have such programs as Jolt installed in order to properly operate this program.

 

[helel ben shachar]

Aha great, so now programmers are absolved of the need to write working programs using such outdated techniques as testing. We can just get the users to debug them on the fly. Brilliant

Don't know if I'd take it that far, but one beef I've had is programmers getting away with writing sloppy redundant code. With the advent of phenomenal processing speeds compared to 15,20,30 years ago the incentive to optimize code had gone away in a lot of cases.

 

[ErikHeemskerk]

What. The. Fuck. This is the worst idea in software development since PHP. Forcing a program that's stuck in a loop out of said loop is as bad an idea as ignoring write errors and reporting your backup 'finished'.

There is no way to predict in what state the program will be in once the program is forced out of the loop, and will probably crash and burn.

The fact that that one MIT professor's instance of Word didn't, after he practically tortured the code to do what he wanted, is nothing short of a goddamn miracle. Maybe these guys should read some Raymond Chen.

 

[David Bradbury]

Are these type of infinite loops something that Clang/LLVM/static-analyzer can find before releasing a compiled application into the wild?

 

[MoonShark]

Another issue is that Jolt can't identify infinite loops that are caused by recursive function calls.

That sounds like a pretty big limitation. AFAIK infinite recursion can be a lot harder to spot, meaning it could be a lot easier for programmers to leave it in the code in the first place. Even moreso if two or more functions are mutually recursive.

Then again, recursion kind of hurts my brain, so if I was a programmer I'd probably avoid it whenever possible. Maybe that's the case for others?

 

[Control Group]

This brings the halting problem to mind. Eventually this road will face into Turing's roadblocks.

My first thought as well. There are obviously cases - the examples in the article of the loop not making any changes to state is one - where this can work, but the larger problem is provably intractable.

That said, I suspect that the loop which isn't making any state changes is among the more common infinite loop errors, so this could still be a very useful addition to software. Though it would be better incorporated at the OS level, of course.

 

[Stubabe]

What. The. Fuck. This is the worst idea in software development since PHP. Forcing a program that's stuck in a loop out of said loop is as bad an idea as ignoring write errors and reporting your backup 'finished'.

There is no way to predict in what state the program will be in once the program is forced out of the loop, and will probably crash and burn.

The fact that that one MIT professor's instance of Word didn't, after he practically tortured the code to do what he wanted, is nothing short of a goddamn miracle. Maybe these guys should read some Raymond Chen.

Agreed 100%. The reason Windows BSODs, Linux Kernel Panics, and applications get unhandled exceptions is to prevent further damage. Often these errors could be ignored but modern systems are specifically designed to cease execution. Ask yourself which you would prefer: loosing the last half an hour's edits to a document or potentially overwriting the old version with a corrupt unreadable one?

 

[moritz-s]

I think this is one of those things that every developer thought of when faced with an obvious infinite loop in a software they're using. It's great to see it implemented. Obviously -- and I don't think the article stresses this enough -- this is a dangerous operation, in many cases it might be preferable to be stuck in an infinite loop rather than forcibly and dumbly break out of it. Still, in some cases it might be worth trying it to save the data; I think the worst result in most (but not all) cases is that the program will just instantly kill itself due to a segfault or something; it's not going to suddenly delete your home directory or something.

 

[deas187]

you guys are all ripping on this, but i don't see the reasons other than you think all programmers should be at this same super high skill level and all programs should never hang and all code is coded perfectly. this could eventually be a great tool for some small company somewhere stuck in an infinite loop of slow growth.

 

[Einbrecher]

So, breaking a program out of an infinite loop that could possibly be running other routines important to its operation is now a good idea...

Having a program hang vs. having a program crash and burn in all sorts of fun, new ways. As much as I'm for crashing and burning, hung programs are easier to 'deal' with.

 

[wischmyr]

As a developer you should always unit, integration and performance test your code. You should also get your code reviewed by a peer. If you're not doing these things you are doing your users a disservice.

Breaking out of a loop and letting the code progress in an unknown state is asking trouble. Would you want a banking application to do this on your account?

 

[Putrid Polecat]

Another issue is that Jolt can't identify infinite loops that are caused by recursive function calls.

That sounds like a pretty big limitation. AFAIK infinite recursion can be a lot harder to spot, meaning it could be a lot easier for programmers to leave it in the code in the first place. Even moreso if two or more functions are mutually recursive.

Then again, recursion kind of hurts my brain, so if I was a programmer I'd probably avoid it whenever possible. Maybe that's the case for others?

Actually, infinite recursion is easy to spot. The stack blows its memory allocation and the program crashes, usually very quickly.

 

[Chamrin]

And some loops are meant to be infinite, and they have their own exit trigger anyway.

 

[fitten]

What. The. Fuck. This is the worst idea in software development since PHP. Forcing a program that's stuck in a loop out of said loop is as bad an idea as ignoring write errors and reporting your backup 'finished'.

There is no way to predict in what state the program will be in once the program is forced out of the loop, and will probably crash and burn.

The fact that that one MIT professor's instance of Word didn't, after he practically tortured the code to do what he wanted, is nothing short of a goddamn miracle. Maybe these guys should read some Raymond Chen.

Pretty much exactly what I was thinking... there's no way to know what the state of the app is after being forced out of the infinite loop. Anything after that would be extremely suspect... from corrupting the data file to reporting false results. That prof with the Word document won the lottery. He could have just as easily (and more probably) ended up with a corrupt document than being able to save what he had.

 

[Stubabe]

Actually this reminds me of Norton's? old crash guard technology for Windows. It usually allowed you to bypass the 1st error only to encounter at least 3-4 new errors or the program going haywire. They dropped that "utility" pretty quick.

Why on earth do you want to allow a program to run on once it is obviously not working correctly? I mean what's next: a utility to fix divide-by-zero errors in programs by getting them to spit out a random number for the answer or fixing file not found errors by opening a random file instead?

This isn't even remotly useful as the only time you should trust the output of a program fixed by this tool is if you don't care much about its results. But, if you don't care that much why bother continuing anyway?

 

[Petronivs]

As a programmer, I have to agree with some of the other comments that this is of questionable utility. Essentially, it tries to recover from infinite loops by BREAKING THE INTERNAL LOGIC. In a program that does any substantial heavy lifting, expecting the logic to flow seamlessly after you unilaterally break out of a loop could be catastrophic.

The only way I can see this being useful is if Jolt just inserts an exception that the target program can deal with on its own, or sends some sort of signal to tell it something's wrong. In order for this to have any constructive impact, the target program needs to know that something went wrong, and try to recover, otherwise, as the abstract clearly states, "For two out of our eight loops, escaping the innite loop
produced the same output as the corrected version of the application." (Translation: 75% of the time this technique resulted in corrupted data.)

 

[bames53]

What. The. Fuck. This is the worst idea in software development since PHP. Forcing a program that's stuck in a loop out of said loop is as bad an idea as ignoring write errors and reporting your backup 'finished'.

There is no way to predict in what state the program will be in once the program is forced out of the loop, and will probably crash and burn.

The fact that that one MIT professor's instance of Word didn't, after he practically tortured the code to do what he wanted, is nothing short of a goddamn miracle. Maybe these guys should read some Raymond Chen.

And if that instance of Word had crashed and burned it would have been no worse than if he'd just had to force quit the application because of the loop.

 

[Penforhire]

This sounds like an obstacle to some coding. If your loop condition (e.g. Do While) is a boolean variable it might not change while you crunch who-knows-how-many calculation loops. I wouldn't want big brother Jolt to kill that loop prematurely.

 

[ColinABQ]

I could see this as being truly "useful" (stretching) only for developers. But that's a market that doesn't need such a tool, since any development environment or platform worth using, comes with a full-featured debugger.

In the wild? I hope not. A very interesting, but very bad, idea. Conceptually, its only saving grace may be that it is almost always impossible, or at least highly impractical and prohibitively expensive, to really test all possible failure modes and scenarios during development of any even mildly complex software. In a very, very few situations, something like this might approach "legitimate use". Still, though, ya gotta push it back to the programmers to delimit operations sanely and safely with fail-safe, if not disaster-proof, exit strategies.

 

[masterbinky]

ROFL, when I read the article I thought "This has been proven to be impossible for all cases, this can only work in these scenario's...." Then I read the article and tada! I came to the same conclusion in less than 5 seconds of thought. The problem with this framework is it is easier to impliment this as a part of the function than an entire framework. Besides monitoring the state, if the loop is working towards a convergent result, you could just monitor the result and have it stop after the result stops changing at a some delta threshold. The bottom line is, You don't need a framework for this just better code. Maybe more exit cases (or cases in general) in your loop, but being mindful of being locked in your loop is something that should be on your mind anytime your writing such code.

 

[Dmanrocks22]

And if that instance of Word had crashed and burned it would have been no worse than if he'd just had to force quit the application because of the loop.

Forcibly quitting doesn't typically corrupt your entire document, which this easily had the potential to do.

 

[MoonShark]

Actually, infinite recursion is easy to spot. The stack blows its memory allocation and the program crashes, usually very quickly.

Good to know, but I actually meant hard to spot visually, in the code, not during a run. Especially for cases of mutual recursion when the second function is part of a different library or something you didn't write. You can't reasonably test every conceivable input at run, right?

But again I'm not experienced here so I could very well be typing out of my butt

As a programmer, I have to agree with some of the other comments that this is of questionable utility. Essentially, it tries to recover from infinite loops by BREAKING THE INTERNAL LOGIC. In a program that does any substantial heavy lifting, expecting the logic to flow seamlessly after you unilaterally break out of a loop could be catastrophic.

If the program does heavy lifting, shouldn't it also be using lots of assertions to be certain that functions are getting proper input? e.g. if Jolt breaks a loop and causes a function to be fed a large integer when it should get a character... shouldn't any industrial-strength program be ready to handle that? (I wouldn't expect that sort of robustness for everyday apps, but you said "heavy lifting" specifically)

 

[CmdrPage]

I agree with the sentiment that this sounds like a really good way to violate your invariants and wind up in an otherwise impossible state.

To take it a step further, this is in effect using an unstructured jump statement. Yes, I went there

Another issue is that Jolt can't identify infinite loops that are caused by recursive function calls.

That sounds like a pretty big limitation. AFAIK infinite recursion can be a lot harder to spot, meaning it could be a lot easier for programmers to leave it in the code in the first place. Even moreso if two or more functions are mutually recursive.

Then again, recursion kind of hurts my brain, so if I was a programmer I'd probably avoid it whenever possible. Maybe that's the case for others?

What concerns me about that is it is frequently possible to optimize recursion as iteration, and many compilers will do so to save stack space. I can understand not grasping a complex recursive case (such as mutual recursion or calling the recursive function multiple times with different arguments and applying some function to the result), but it seems like simple recursion should be susceptible to the same techniques they use for iteration.

 

[ErikHeemskerk]

you guys are all ripping on this, but i don't see the reasons other than you think all programmers should be at this same super high skill level and all programs should never hang and all code is coded perfectly. this could eventually be a great tool for some small company somewhere stuck in an infinite loop of slow growth.

It has nothing to do with the level of programmer that uses this, it's universally insanely stupid. The point is that if you prematurely break out of a loop, you can no longer make ANY valid assumption about the state of your program. Usually the point of a loop is that when you exit it -- when you want to, that is -- you have accomplished something useful.

Say, for example, you want to replace all occurrences of 'foo' with 'bar' in a file. You'd read the file's contents, get a list of all occurrences of 'foo' and then, in a loop, replace each of them with 'bar', after which you write the file back to disk. Suppose we're about halfway through. Half of the occurrences have already been replaced, half of them haven't. Jolt decides we're in an infinite loop and rapes the instruction pointer to get us out of the loop. What was the next step again? Oh, right, save the file. Now your code thinks all is well and has ignorantly saved the file with only half the occurrences of 'foo' replaced.

Especially higher level programmers would commit suicide over this. And this is only a relatively simple example.

 

[primordius]

This kind of research irritates me to no end.
Technology has allowed us to automate quality control in manufacturing, agriculture, and many other industries.
But having code automate the quality of code is ridiculous.

Loops of any kind must be able to break with some condition.
If there exists a scenario where the loop cannot break then the code is improperly written.
Breaking out and saving data, losing data... I don't care... in principle this should never happen anyways.

Let's get back to fundamentals people.
Write good code and put these idiotic research projects to bed.

 

[sidran32]

Neat and clever quick fix if the end user is stuck with buggy software. But it would be even better served by software testers. Perhaps that's the market they're going for.

Detecting infinite loops is an NP-complete problem so I'm surprised they were able to come up with a solution that gets them part of the way there, at least. Though I'm sure that it won't get everything.

 

[Xavin]

There is no way to predict in what state the program will be in once the program is forced out of the loop, and will probably crash and burn.

This. Once a program has gone off the reservation, you want it to terminate, period. Allowing it to continue so you can save means that you might end up corrupting your data, since the program state is unknown.

Trying to recover after an unhandled exception, or in this case an infinite loop, is an amateur mistake, and experienced developers understand why this is a terrible idea.

 

[gm112]

What. The. Fuck. This is the worst idea in software development since PHP. Forcing a program that's stuck in a loop out of said loop is as bad an idea as ignoring write errors and reporting your backup 'finished'.

There is no way to predict in what state the program will be in once the program is forced out of the loop, and will probably crash and burn.

The fact that that one MIT professor's instance of Word didn't, after he practically tortured the code to do what he wanted, is nothing short of a goddamn miracle. Maybe these guys should read some Raymond Chen.

LOL. The PHP part made me LOL so hard because I definitely know where you're coming from with that comment.

But yeah, I'm really curious if he was using the latest version of Word. As other people have stated in comments before mine, it's difficult to properly detect the exact state of the program whether the loop was meant to be or not. Honestly, this is like if GCC threw an error message on your screen and halted your program each time a warning showed up in the linux kernel. The idea behind Jolt is admirable, but so are many other ideas. I prefer going along with developers writing their code right and stable, not using some workaround that puts the fix in the users lap.

 

[kaleberg]

I agree with most that this is a terrible idea. More useful would be to bring back what Multics called the "program interrupt". This is just a signal that a program can catch and use for error recovery. Depending on the program, it would either do a simple clean up and return to the top level event loop or put the user in a special recovery state which would allow active data to be saved rather than lost, but require the program to restart before further work. It's something like booting into single user mode on a damaged system - good enough to get one's data off for the most part, but you wouldn't want to try and do anything serious.

I found the feature very useful back in the 70s and early 80s, but I've never found this feature in any more recent system. It could be implemented something like "force quit", only enabled if the programmer has set up an appropriate handler. I imagine the Mac version might present a dream like, misty display of the user interface, while serious Windows gamers would have code red bars flashing at the sides of the screen as in an abandon ship seqeuence from a space opera. The idea is to let the user save what they can and bail out.

 

[Torbjörn Larsson OM]

Yes! I have wanted an AI type supervisor at hand for so many years now.

That said, the facility is limited. There need to be a watchdog that works with the OS that identifies resource demanding or unresponsive threads and decides if they should be terminated or not.
-------------

But the comments here shows why this has been so long coming:

"There is no way to predict in what state the program will be in once the program is forced out of the loop,"

"So, breaking a program out of an infinite loop that could possibly be running other routines important to its operation is now a good idea..."

"Breaking out of a loop and letting the code progress in an unknown state is asking trouble."

"there's no way to know what the state of the app is after being forced out of the infinite loop."

"it tries to recover from infinite loops by BREAKING THE INTERNAL LOGIC."

"The point is that if you prematurely break out of a loop, you can no longer make ANY valid assumption about the state of your program."

"in principle this should never happen anyways."

The point is _exactly_ to break the faulty internal logic to save the external logic (remaining resources, the end user). It is a way to make realtime or soft realtime software (ideally, laptops) more robust.

I am fairly certain that concerns are misplaced because today this is what a user _do_ with a hung laptop, restart/force thread stop, and take the breaks. Frequent and stacked file backups has solved the file recover problem. The remaining problem is to get this automated and sandboxed without forcing restart.

The logic of a laptop is not the logic of a thread or interrelated threads. It is the logic of realtime use of an ecology of threads.

 

[robotic_tourist]

As a developer you should always unit, integration and performance test your code. You should also get your code reviewed by a peer. If you're not doing these things you are doing your users a disservice.

Breaking out of a loop and letting the code progress in an unknown state is asking trouble. Would you want a banking application to do this on your account?

try {
//some code
} catch (InfiniteLoopException) {
//handle InfiniteLoopException without making a worse mess
}

I know everything should be comprehensively unit tested and peer reviewed, but we can't always know all failure conditions beforehand, particularly in hugely complicated systems that will sometimes handle inputs they weren't designed for. And sometimes the effort involved in testing all possible scenarios outweighs the risks involved in one of those scenarios happening.

My friend used to work for a company that made aero-engine controllers. The language did not support loops at all, just in case. So horses for courses, as usual.

 

[Petronivs]

More useful would be to bring back what Multics called the "program interrupt". This is just a signal that a program can catch and use for error recovery. Depending on the program, it would either do a simple clean up and return to the top level event loop or put the user in a special recovery state which would allow active data to be saved rather than lost, but require the program to restart before further work.

You mean like a signal you can send to a program to tell it to clean up and exit?

Not that anything like that is specified in any standards like POSIX or anything...

 

[robotic_tourist]

you guys are all ripping on this, but i don't see the reasons other than you think all programmers should be at this same super high skill level and all programs should never hang and all code is coded perfectly. this could eventually be a great tool for some small company somewhere stuck in an infinite loop of slow growth.

It has nothing to do with the level of programmer that uses this, it's universally insanely stupid. The point is that if you prematurely break out of a loop, you can no longer make ANY valid assumption about the state of your program. Usually the point of a loop is that when you exit it -- when you want to, that is -- you have accomplished something useful.

Say, for example, you want to replace all occurrences of 'foo' with 'bar' in a file. You'd read the file's contents, get a list of all occurrences of 'foo' and then, in a loop, replace each of them with 'bar', after which you write the file back to disk. Suppose we're about halfway through. Half of the occurrences have already been replaced, half of them haven't. Jolt decides we're in an infinite loop and rapes the instruction pointer to get us out of the loop. What was the next step again? Oh, right, save the file. Now your code thinks all is well and has ignorantly saved the file with only half the occurrences of 'foo' replaced.

Oh noes! only half the occurrences have been replaced!! A better example would be that it was half way through writing an important xml tag, or zipping an xml bundle rendering the actual data unreadable. Even so, is it much different from other failure modes that are routinely handled by exceptions?

 

[Torbjörn Larsson OM]

After some though: I suspect this was the problem with windowed software too. (And threads.) Obviously it makes a computer less predictive. The guys who didn't care were the money winners.

The most important thing that gets a computer to actually work is the user.

 

[Putrid Polecat]

I agree with all the others here that this is the dumbest technology ever developed. It replaces an infinite loop with a preemptive action that leaves the program in an inconsistent state. Meaning, the consequences of leaving the loop prematurely are unknown to the author and could potentially be more damaging than force-quitting the app. And yes, it encourages more shitty code by letting bad code escape detection. The goal of testing is "crash early, crash often" -- much better than crashing when the user is writing a proposal.

 

[ronelson]

It has nothing to do with the level of programmer that uses this, it's universally insanely stupid. The point is that if you prematurely break out of a loop, you can no longer make ANY valid assumption about the state of your program. Usually the point of a loop is that when you exit it -- when you want to, that is -- you have accomplished something useful.

And when your program exits the loop through normal function, you should STILL be checking to ensure the loop did what it said it did. This does not change that. All it does is let the program get to its next validation test instead of never making it there.