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>

 

[Petronivs]

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.

But that will probably take another loop. Then we'll have to have another loop to make sure that loop checked things correctly, in case it went wrong, then we'll have to check the check . . .

Wait, I thought we were trying to prevent infinite loops.

 

[masterbinky]

It was never part of the constraints that we avoid paradoxes......

 

[bersl2]

If anyone tries to incorporate this in its current form into an actual software program, they are smoking crack. As a research project, though, it looks intriguing.

Also, to everyone invoking the halting problem, remember that what isn't possible is a general algorithm to solve the problem for an arbitrary program; that doesn't mean that there aren't an infinite number of possible heuristics to answer certain forms of the problem, a subset of which might cover a large portion of common patterns.

I can see this possibly being useful; they have a long way to go before they can claim that it's better than just using a watchdog timer (as mentioned in previous comments), but we won't know unless someone tries.

 

[JanJanyson]

Has this Word user never heard of Time Machine for the Mac or Genie TimeLine for PCs? Both of these utilities save changed versions of files in selected directories at selected intervals. Far better to lose the last thirty minute's worth of work -- which most people can easily remember -- than to overlay everything with hopelessly botched nonsense. Also, what if the application hangs because the OS decides to relocate itself to Apple's address in Cupertino -- happens with Windows all the bloody time.

 

[Stubabe]

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.

And you are a classic example of the mentality that leads to shoddy, slow software in the first place. Yes, let not validate our logic and input, no its much better to try and run with it and hope we can clean the mess up after it explodes in our face. Let's not fix our program instead run it lots of times abort when it fails and hope one run works.
If the programmer that wrote the code failed to validate the edge case that caused the error when they had explicit knowledge of what was meant to occur then how the hell is an external module meant to do a better job?
I also fail to see what this has to do with laptops or real-time systems (soft or otherwise). Real-time OSs must handle all long running jobs that fail to yield (either due to infinite errors or just lots of processing) and still meet their latency requirements - that's called scheduling not bug fixing. As for laptops? This is hardly a general use case and I don't see why infinite loops should represent a significant proportion of everyday workflows. Also a hung app != a hung system in a pre-emptive environment.



As for those that are claiming we can validate our way out of this really nasty loop termination hack. Let's take a hypothetical example.
Declare A, B
Loop (condition) { Do something with A}
If (A looks ok) Print A
Ok let's say condition fails to terminate the loop to we break in and jolt it. But if we validate A we are ok if A is corrupted by this, yes?
No, no,no!
1) A may pass basic validation but be wrong anyway -> now overwrite good data with bad (worse than just data loss)
2) Due to the code and stack mangling effects of optimising compilers we may breakout past our validation code (so it never gets to reject the void values) or end up running the wrong function entirely.
3) What if the error was in the validation code in the first place? What now, validation of validation code???
4) What to validate and where? The programmer is no longer in sole control of program flow so there is no causality in his/her code. A=B+C can suddenly become B=C+sheep or Print(flibble) so your error checking code will become more complex (and so more buggy) than your actual code.
This whole idea has been done in various forms before, it's a mess and an amateurish failure of logical reasoning and design, sooner or later anyone that tries it finds that out the hard way...

 

[Xavin]

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.

You can't do that and expect the program to still work, or your data to be good. It is impossible. This is a basic tenant of good programming, it's not debatable.

Just saying your data is safe because of backups is idiotic. Despite all the efforts to make things otherwise, un-backedup data is still the norm. Even with backups this kind of error can easily cause silent corruption, where it's not noticed until much later.

 

[Stubabe]

It is not just impossible Xavin it's completely backwards thinking: lets improve reliability by making software more complex and less deterministic. Honestly, I am surprised (or maybe not) that a MIT prof hasn't had the naivety knocked out of him yet...

 

[bames53]

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.

It does have to potential to not save all the work that's been done since whenever the last save was done, or whenever Word last autosaved. And it should only have the possibility of corruption if the user saves over his document instead of saving to a new file.

 

[forthedough]

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.

The halting problem is in no way part of the NP-complete set of problems. No algorithm exists or can exist that can solve the halting problem, one of the requirements of placing a problem in NP or NP-complete is the existence of an algorithm that can solve it.

 

[cvarner]

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.

+1

...and experienced developers understand why this is a terrible idea.

I am, and I do, and it is.

 

[byronblue]

I think a better use of the researcher's time would be to write a tool that analyzes code for this before programmers ship their code.

 

[hpmmfs]

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?

for all the faults of recursion it allows for elegant and efficient code when use properly. There are problems that are nearly intractable, (if not actually intractable), without the use of recursion (this is also dependent on the language structure and style). Like any other powerful tool, it should be used when necessary and to make code both more efficient and readable.

 

[ShuggyCoUk]

Detecting infinite loops is an NP-complete problem

Be sure to get your Turing prize renamed to the sidran32 prize

 

[ErikHeemskerk]

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?

for all the faults of recursion it allows for elegant and efficient code when use properly. There are problems that are nearly intractable, (if not actually intractable), without the use of recursion (this is also dependent on the language structure and style). Like any other powerful tool, it should be used when necessary and to make code both more efficient and readable.

I doubt there are any problems that cannot be solved without recursion. You might have to use your own stack, but sometimes that's the better thing to do, especially if the 'recursion depth' is exorbitantly large (couple of thousand items).