Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Escaping Infinite Loops

Unknown Lamer posted more than 3 years ago | from the pc-losering dept.

Programming 204

twocentplain writes in with an MIT news release about Jolt, a research project designed to unfreeze software stuck in an infinite loop (for a subset of infinite loops). It uses a combination of static instrumentation (using LLVM) and a run time watchdog that checks the program state during loop iteration; when a duplicate state is detected it permits the user to take one a few actions to escape the loop. The authors claim it works well enough that the program can often continue operating properly. The original paper contains detailed case studies.

Sorry! There are no comments related to the filter you selected.

yipes (2, Insightful)

Anonymous Coward | more than 3 years ago | (#36964978)

bad programmers can now sink to new lows...

PL/C and PL/I Checkout Compiler also "fixed" bugs (1)

billstewart (78916) | more than 3 years ago | (#36965576)

The standard teaching language at Cornell in the mid-70s was PL/C, Cornell's version of the IBM PL/I Checkout Compiler. It didn't "fix" infinite loops, but if "fixed" a lot of simple syntax errors and some runtime errors like "divide by zero" or out-of-bounds array indexes.

Sure, it wasn't always reliable, and could even cause infinite loops rather than preventing them, but it still let you speed up the code-keypunch-wait-run-debug cycle a lot. Fixing the syntax errors meant that you could usually identify all your syntax errors in one run (especially simple ones like forgetting a statement-delimiting semicolon or using the wrong number of closing parentheses), and could often find where you had logic errors even though it didn't always do the right thing (e.g. replacing an out-of-bounds array index with "1" was seldom correct, but it told you you'd done something wrong.) Since the development cycle typically included "wait for a keypunch", "wait to put your cards in the reader" and "wait for your batch job to come out of the printer", and the computer labs got overcrowded when CS100 projects were due, this was a big win.

Loop invariants (4, Insightful)

Anonymous Coward | more than 3 years ago | (#36964980)

So you just jump to an address outside of the loop and hope that your loop invariant hasn't been violated?

Re:Loop invariants (1)

YodasEvilTwin (2014446) | more than 3 years ago | (#36965034)

My thought exactly. Not to mention that other operations performed by the loop (that are obviously malfunctioning) may be necessary for the program to proceed correctly even if they don't affect the loop invariant.

Re:Loop invariants (1)

ShakaUVM (157947) | more than 3 years ago | (#36965342)

>>My thought exactly. Not to mention that other operations performed by the loop (that are obviously malfunctioning) may be necessary for the program to proceed correctly even if they don't affect the loop invariant.

I guess MAYBE if you write code defensively throughout your codebase, it might work. Though it seems a recipe for disaster unless it'd be a worse disaster for your code to freeze up. (Medical equipment, maybe? Yikes.) But programmers that are cautious to validate all their input and output are also going to be not writing loops that fall into infinite loops.

I've actually been bitten in the ass by watchdog timers before. No, I'm not in an infinite loop, thank you very much, I'm just running a complicated calculation. It sounds like this will be a little bit more sophisticated, maybe.

Re:Loop invariants (1)

neokushan (932374) | more than 3 years ago | (#36965444)

Don't your average, bog-standard windows programs run in an infinite loop? Does this account for that?

Re:Loop invariants (0)

Anonymous Coward | more than 3 years ago | (#36965652)

No, it is not an infinite loop. It is, generally, a loop built around a blocking function that will return true as long as the message queue does not have a quit message posted to it, e.g.

MSG msg;
while(GetMessage(&msg))
{
    DispatchMessage(msg);
}

It's not really that different from blocking network operations in that respect.

Re:Loop invariants (1)

CSMoran (1577071) | more than 3 years ago | (#36965788)

Though it seems a recipe for disaster unless it'd be a worse disaster for your code to freeze up. (Medical equipment, maybe? Yikes.)

I'd rather never choose between "the irradiator control is stuck in a for(;;) loop" and "let's get out of the irradiator control loop by using a default radiation of 99999.99999".

Re:Loop invariants (1)

angel'o'sphere (80593) | more than 3 years ago | (#36965694)

The loop invariant (assuming you know what it is) is not the state of your program, but only the state of your loop!

If after several loops the state of the program is not changing, the loop obviously is not doing anything and is an endless loop ... well that was simple, don't get how you failed to see that.

Re:Loop invariants (0)

Anonymous Coward | more than 3 years ago | (#36965812)

That is just one case of loops. What about the far more likely case of the program state changing after every iteration?

Gah im stuck.... (-1)

Anonymous Coward | more than 3 years ago | (#36964982)

...in a loop trying to get first post!

One Infinite Loop, Cupertino CA (1)

billstewart (78916) | more than 3 years ago | (#36965446)

  • Insert Apple Fanboi Response Here!
  • Our hardware is so fast it can do infinite loops in 2.6 microseconds!
  • Infinite Loop was better when it had the Computer Literacy Bookstore branch, and the Peppermill down the block!
  • Insert your own insanely great response here!

The authors claim... (2)

Nikker (749551) | more than 3 years ago | (#36964986)

The authors claim it works well enough that the program can often continue operating properly.

If the software wasn't written properly to begin with, what metric are we now using to establish it is operating "properly" ?

Re:The authors claim... (0)

Anonymous Coward | more than 3 years ago | (#36965024)

What I've seen people do for a long time "if it doesn't crash it's fine".

Re:The authors claim... (1)

cowboy76Spain (815442) | more than 3 years ago | (#36965070)

Yeah, but "restoring" your program in an indefinite state may have worse consequencies than just freezing. Imagine that your compression algorithm has an infinite loop in certains conditions and, when the data has been "successfully" processed, it is written to your file...

Re:The authors claim... (1)

dgatwood (11270) | more than 3 years ago | (#36965800)

Either it is taking in new data, in which case you will never reach an exact repeated state, or it isn't, in which case the programmer was incompetently using polling instead of a more reasonable notification mechanism, and you should buy or write better software.

Besides, for most graphical applications, a hang means an infinite loop in the main run loop. Kicking the app back out to the main run loop should almost never cause any catastrophic side effects, and will usually leave the app in a state that is clean enough to allow you to perform a "Save As" operation before quitting.

Re:The authors claim... (1)

drpimp (900837) | more than 3 years ago | (#36965036)

Not to mention that if you just jump out of the loop, the software state is probably (in most cases) invalid anyhow. Not that you are any worse off then just leaving it hung, but killing the process will most likely still be required unless it's a well written threaded app of sorts, but we probably wouldn't be having this discussion if that was the case now anyway right?

Re:The authors claim... (1)

Urkki (668283) | more than 3 years ago | (#36965738)

Not to mention that if you just jump out of the loop, the software state is probably (in most cases) invalid anyhow.

These days many programs are event based. I'd say there's a decent chance, that program is left in valid state, especially if loop is broken at the condition, and remaining code in the function is allowed to execute before function returns to the main event loop.

Re:The authors claim... (1)

Charliemopps (1157495) | more than 3 years ago | (#36965106)

It does the thing you made it to do in the amount of time you want it to do it.

Re:The authors claim... (1)

Hatta (162192) | more than 3 years ago | (#36965118)

Isn't it impossible to determine a priori whether a given piece of software will halt? How can you then say that any software that doesn't halt isn't acting properly?

Re:The authors claim... (2)

newcastlejon (1483695) | more than 3 years ago | (#36965194)

IANACS, but this seems different to the halting problem: if the program is a FSM (not the Noodly One) then one that repeatedly enters the same state with a short period is possibly in an infinite loop. The halting problem is more a question of being able to tell if a program given an input ever reaches its end without actually running it

Re:The authors claim... (1)

bondsbw (888959) | more than 3 years ago | (#36965458)

Not really. Running the program/input in question is an option, so long as the executing environment itself always halts. It must somehow detect that the program/input in question does not halt, but then halt itself while returning that fact.

The undecidable nature of the halting problem indicates that there is no executing environment for which this is true for all possible programs and inputs.

This software appears to be able to answer that question for some programs and inputs.

Easy... (1)

xMrFishx (1956084) | more than 3 years ago | (#36964992)

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

Re:Easy... (4, Funny)

Baloroth (2370816) | more than 3 years ago | (#36965054)

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

Re:Easy... (1)

Anonymous Coward | more than 3 years ago | (#36965136)

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

Re:Easy... (1)

Anonymous Coward | more than 3 years ago | (#36965184)

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

Re:Easy... (2)

gl4ss (559668) | more than 3 years ago | (#36965320)

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

this is the infinite loop watch-- yo dawg, it seems you like repeating so we put an infinite loop in your infinite loop.

Re:Easy... (-1)

Anonymous Coward | more than 3 years ago | (#36965504)

We now return you to the appropriate software state

http://tinyurl.com/55bsxu [tinyurl.com]

Re:Easy... (0)

Anonymous Coward | more than 3 years ago | (#36965552)

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

Re:Easy... (0)

Anonymous Coward | more than 3 years ago | (#36965718)

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

Execution timer expired; exiting.

Re:Easy... (0)

Anonymous Coward | more than 3 years ago | (#36965172)

I always thought recursion wasn't the same as looping. For one thing, real machines have finite stack space. (But, tail recursion, blah, blah. Except you quoted him...)

Re:Easy... (1)

Short Circuit (52384) | more than 3 years ago | (#36965508)

Any recursive function can be converted to a loop, and vice versa. Of course, any real machine will have a finite heap, so you wouldn't be able to properly emulate a machine with an infinite stack. (Which would be the analogous counterpart to your implied infinite heap, if we include the constraints in a transformation)

Re:Easy... (0)

Anonymous Coward | more than 3 years ago | (#36965850)

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

I always thought the best method of getting out of infinite loops was to not have infinite loops. Everybody loves watchdogs and timers but they would be a reactive fix rather than a proactive fix.

Bad idea (0)

Anonymous Coward | more than 3 years ago | (#36964998)

Compensating for failure to design properly at the compiler level scares me.

Does This Really Happen? (0)

Anonymous Coward | more than 3 years ago | (#36965002)

Sure, I've written infinite loops, and encountered them while debugging. But how often do you actually find infinite loops (that you KNOW are infinite loops) in software that's actually been released?

Re:Does This Really Happen? (2)

UnknowingFool (672806) | more than 3 years ago | (#36965162)

You mean like the Zune Leap Year Bug which causes them to be unusable for a few days?

Re:Does This Really Happen? (1)

Short Circuit (52384) | more than 3 years ago | (#36965520)

In my own code, even.

Re:Does This Really Happen? (1)

dgatwood (11270) | more than 3 years ago | (#36965866)

But how often do you actually find infinite loops (that you KNOW are infinite loops) in software that's actually been released?

I found one in a shipping version of Xcode 4 last week. Steps to reproduce:

1. Create a project containing a library.

2. Drag the library into its own "Link Binary With Libraries" box.

3. Build.

It's not as uncommon as you think when you're dealing with apps that maintain complex, potentially cyclic (or at least heavily cross-linked) data structures under the hood.

Infinite loops aren't the real problem (1)

grimmjeeper (2301232) | more than 3 years ago | (#36965008)

I've found that tasks waiting on resources without a reasonable timeout (or sometimes no timeout at all) and refusing to respond to outside stimuli are more often the problem than a task stuck in an infinite loop.

Re:Infinite loops aren't the real problem (2)

sdBlue (844590) | more than 3 years ago | (#36965088)

One might argue that the function that is waiting on the resource with no timeout is itself an infinite loop (as to whether or not this fix would fix that, it would of course depend on error checking code being present and correct, after the loop exits...)

Re:Infinite loops aren't the real problem (1)

grimmjeeper (2301232) | more than 3 years ago | (#36965182)

Good point. A task forever stuck in a wait state pending on a resource allocation would resemble an infinite loop. Though a task that's stuck in the pending queue by the scheduler may not ever show up as an infinite loop since it doesn't actually get scheduled to run anything. I wonder how a task like that would be handled differently than one with an actual infinite loop.

Really interesting (3, Funny)

Harald Paulsen (621759) | more than 3 years ago | (#36965018)

That's really interesting.
That's really interesting.
That's really interesting.
That's really interesting.
That's really interesting.
# duplicate state detected, jumping loop
Daisy, daisy, give me your answer do..

Re:Really interesting (2)

grimmjeeper (2301232) | more than 3 years ago | (#36965026)

I'm sorry Dave. I'm afraid I just can't do that.

Re:Really interesting (1)

Z_A_Commando (991404) | more than 3 years ago | (#36965160)

Ah, ah, ah, you didn't say the magic word!

Re:Really interesting (0)

Anonymous Coward | more than 3 years ago | (#36965380)

"I hate this hacker crap"...

"Ah, ah, ah?"
"Ah, ah, ah?"
"Ah, ah, ah?"
"Ah, ah, ah?"
"Ah, ah, ah?"
"Ah, ah, ah?"...

-AC

Re:Really interesting (1)

stderr_dk (902007) | more than 3 years ago | (#36965644)

It's a UNIX system! I know this!

Interesting.... what about finite state machines? (0)

Anonymous Coward | more than 3 years ago | (#36965030)

This is an interesting, and no doubt fairly useful piece of software, but, now, correct me if I'm wrong - if a program is coded as a finite state machine there'd be instances of duplicate states that can appear to be "hung," in which case this software would only do harm, no?

Re:Interesting.... what about finite state machine (0)

Anonymous Coward | more than 3 years ago | (#36965198)

Presumably, one would not use it on a finite state machine.

Halting Problem (4, Funny)

krovisser (1056294) | more than 3 years ago | (#36965042)

So we've solved the halting problem.

By making it the user's problem?

Wait a second...

Re:Halting Problem (1)

gstrickler (920733) | more than 3 years ago | (#36965190)

Isn't that the standard reply from developers and tech support?

Re:Halting Problem (4, Interesting)

AdmiralXyz (1378985) | more than 3 years ago | (#36965282)

Joking aside, this really has nothing to do with the Halting Problem, because the Halting Problem is a statement about Turing machines, which have unbounded space. Actual computers are not Turing machines: because they have finite memory, they have a finite (though very large) number of states, and are actually finite-state automata.

Here, the Halting Problem doesn't really apply, because if all else fails, you can (in theory) take every combination of programs up to N bits in length, and every combination of inputs up to M bits in length, and make a table of size 2^(N + M) saying whether a given program halts on a given input by running it and looking for a duplicate state. Of course that's impossible in the real world, but it does demonstrate that there's nothing about this research that's violating established principles of computer science.

And in a sense, that seems to be what they're doing here: checking "has this program existed in this exact same state before?", because if it has, you're in an infinite loop. I seriously doubt it's as effective in the real world as they claim though: in my experience infinite loops simply don't happen in computing anymore. If your computer locks up, it's probably because you're in deadlock, or waiting on the disk or the network.

Re:Halting Problem (1)

Sduic (805226) | more than 3 years ago | (#36965612)

Actual computers are not Turing machines: because they have finite memory...

Could encountering OOM errors, combined with some (perhaps non-deterministic) memory reclamation lead to problems with enumerating all of the states?

Browsers (0)

Anonymous Coward | more than 3 years ago | (#36965044)

Pretty sure most browsers do this now. (even IE, even Flash actually)
When loop has been running too long, it halts and asks if the user wants to continue running it.

I'm guessing it is a whole different ball-game when it comes to interpreted versus compiled?

Re:Browsers (1)

Short Circuit (52384) | more than 3 years ago | (#36965548)

Different solution. This isn't a watchdog, this is a, "hey, this program's been here before. And once it's been here, it'll go there. And then there. And then here. And it won't stop."

One bright side: The song that never ends...will.

Last (1)

Anonymous Coward | more than 3 years ago | (#36965046)

Last

Another advanced techiique to escape invinite loop (1)

Shompol (1690084) | more than 3 years ago | (#36965062)

Put a counter in all your loops. If the counter hits some arbitrarily ridiculous number throw an exception.

This goes contrary to my management's belief that if anything goes wrong the program should "crash and burn".

Re:Another advanced techiique to escape invinite l (2, Informative)

Anonymous Coward | more than 3 years ago | (#36965134)

Listen to your management. Generally: failing silently is worse than failing noisily (is worse than not failing at all of course).

In any case, your technique—unless you do a lot more analysis of your software than your comment suggests—will lead to a) lots of watchdog code cluttering up the logic and b) the software failing when it’s run on more data than you expected.

Re:Another advanced techiique to escape invinite l (0)

Anonymous Coward | more than 3 years ago | (#36965254)

I'm not sure if you're going for a funny, or if you are a terrible programmer.

flint spot (-1)

Anonymous Coward | more than 3 years ago | (#36965082)

hahahahahahaha_first_hahahahahaha

Some loops are less infinite than others... (1)

Sduic (805226) | more than 3 years ago | (#36965098)

You are in a maze of twisty little branches. All alike.

>_

Now if only... (1)

HighOrbit (631451) | more than 3 years ago | (#36965102)

Now if only they could get the software development unstuck from an infinite loop of project management, powerpoint slides, and TPS reports.

Yea, but what happens.... (1)

mat catastrophe (105256) | more than 3 years ago | (#36965116)

...if it goes into an infinite loop while trying to rescue another piece of code?

Re:Yea, but what happens.... (1)

xMrFishx (1956084) | more than 3 years ago | (#36965168)

The computer implodes and there's a fire.

This is done routinely (0)

Anonymous Coward | more than 3 years ago | (#36965148)

This is done routinely on the Parallax Propeller multicore microcontroller. In general, CPU cores can easily watchdog each other.

Near-ideal solution? (1)

Twinbee (767046) | more than 3 years ago | (#36965150)

One thing I noticed in the article was this:

and because of some fundamental results in computer science, “I know for a fact that he’ll never be able to get it exactly right.” But, Weimer says, “The vast majority of infinite loops he will be able to figure out.”

Does this we can't get above a certain percentage of correct predictions, or does it mean that more and more work will converge towards 100% (99.5, 99.9%, 99.999% etc. etc.)

Re:Near-ideal solution? (1)

Haedrian (1676506) | more than 3 years ago | (#36965470)

No it means that no Computer Program can work out whether a program is in an infinite loop or not (Halting Problem), so he'll have to use heuristics to work it out. You can't get a 100% , because if you did you would have violated something which is mathematically proven.

Re:Near-ideal solution? (1)

Twinbee (767046) | more than 3 years ago | (#36965598)

Yes, but my question was not if you could reach 100%, but whether you could *arbitrarily close* to 100% given enough effort.

Re:Near-ideal solution? (1)

Haedrian (1676506) | more than 3 years ago | (#36965786)

Since we're talking about heuristics, given enough programs you could train it/program to be pretty close. But then you'd end up with a ton of false positives so its not very worth it. Plus the idea of force-exiting an infinite loop is a bad either anyway, so I'm not sure its worth it in any case.

Re:Near-ideal solution? (1)

Short Circuit (52384) | more than 3 years ago | (#36965574)

Does this we can't get above a certain percentage of correct predictions, or does it mean that more and more work will converge towards 100% (99.5, 99.9%, 99.999% etc. etc.)

It means one of those two things is true, yes.

Norton CrashGuard (0)

Anonymous Coward | more than 3 years ago | (#36965196)

Sounds like Norton CrashGuard, a Symantec product that came out in the mid-90's bundled with Norton Navigator and, if I recall correctly, PC Handyman.

Disclosure: I worked for Symantec at the time and made a major contribution to CrashGuard - the background graphic.

They should this method (1)

UnknowingFool (672806) | more than 3 years ago | (#36965216)

Escaping the RDF.

Thanks, I'll be here all week. Tip your waitstaff.

Re:They should this method (0)

Anonymous Coward | more than 3 years ago | (#36965660)

You should your method "the verb."

uh-oh (1)

drolli (522659) | more than 3 years ago | (#36965218)

All these endless loops which i created just to let some background threads executing....

Misleading title (1)

Illusion2269 (959341) | more than 3 years ago | (#36965224)

I thought this would be about how to get away from Apple headquarters.

Boy do I feel silly....

More like "Escaping non-Infinite Loops" (1)

Anonymous Coward | more than 3 years ago | (#36965236)

If you can escape the loop, it's by definition NOT an infinite loop, right?

Re:More like "Escaping non-Infinite Loops" (3, Insightful)

kwiqsilver (585008) | more than 3 years ago | (#36965758)

So...if the computer eventually gives in to entropy, it's not an infinite loop?

Take one of what? (1)

wjousts (1529427) | more than 3 years ago | (#36965260)

when a duplicate state is detected it permits the user to take one a few actions to escape the loop.

article is a dup (1)

Anonymous Coward | more than 3 years ago | (#36965332)

This story was posted here last week, [slashdot.org] with many of same snarky observations.

Re:article is a dup (1)

freedumb2000 (966222) | more than 3 years ago | (#36965614)

nice

Anyone remember Norton Crash-guard/anti-freeze (2)

slew (2918) | more than 3 years ago | (#36965410)

I seem to remember the old norton crash-guard/anti-freeze utility that was somewhat useful in getting around problems like infinite loops in old Windows programs.

I'm pretty sure the way this worked takes advantage of the fact that windows programs are essentially structured as message-processing co-routines plugged into a infinite scheduling loop (the windows loop). Although mostly, messages are posted, sometimes these messages can go re-entrant and if poorly coded cause an infinite loop. Anti-freeze could be then "sprayed" on the app which would then try to insert or delete messages in the program's processing loop to help it exit the re-entrant part loop and go back to the main scheduling loop. Often this would work well enough to enter the "Save" menu processing part of the program to avoid losing work. It also attempted to handle traps effectively (things that often happen when a program runs past the end of an array if it's in an infinite loop) by suspending the main flow of the program and inserting another message and thread to try an allow for limited operation (like "Save" menu processing).

Unfortunatly, this technology wouldn't be that effective in todays environment (basically, it probably could be classified as malware/spyware so the defenses against malware/spyware woud probably prevent it from working), but it seems like bulding this into an application code development infrastructure seems like it might be a good idea...

Re:Anyone remember Norton Crash-guard/anti-freeze (2)

ZiggyM (238243) | more than 3 years ago | (#36965874)

yes I had that [norton?] antifreeze program too over 15 years ago. It gave you the option to jump out of an infinite loop (at your own risk) and most of the time that was good enough to unfreeze the entire (16 bit) computer, save your files.

Just another debugger? (1)

mj1856 (589031) | more than 3 years ago | (#36965420)

From TFA: Jolt works in conjunction with a compiler, a program that translates code written in a high-level programming language into rudimentary instructions that a computer can understand. When an application is being compiled, Jolt marks the beginnings and ends of all the loops indicated in the source code. If the compiled application later stalls, Jolt simply forces it to skip ahead to the first instruction following the loop it’s stuck in.

Wouldn't this be like using a symbol file? In .Net, for example, a .pdb gets generated when you compile in debug mode. You can certainly then attach a debugger to a program stuck in an infinite loop and tell the debugger to jump to the code following the loop. It sounds like they're just doing this in some automated way.

Of course this completely ignores any benefit of compiler optimization when compiled without symbols in "release" mode. Not to mention making it impractical to obfuscate your code to prevent disassembly. Seems like a really bad idea overall.

Re:Just another debugger? (0)

Anonymous Coward | more than 3 years ago | (#36965744)

Not to mention making it impractical to obfuscate your code to prevent disassembly.

A good thing.

I've done that by hand (1)

greed (112493) | more than 3 years ago | (#36965424)

Back in my days as a software tester, that's basically what I would do when I suspected something was looping. Wedge a debugger into the running process, see how far the program counter was going, and see what registers were changing, and a quick look at the autos in the current stack frame. (Most autos would be in registers: this was not an x86-based system.)

I made no attempt to get the program to continue, though; once I was pretty sure it was in a loop, I'd then work out the minimum necessary circumstances to trigger it and log a bug report.

Bypass the interface (1)

arbulus (1095967) | more than 3 years ago | (#36965450)

Bypass the interface

backtracking? (0)

Anonymous Coward | more than 3 years ago | (#36965464)

I imagine the software does the best it can to look at everything involved in arriving at the loop and tries to take the user to the nearest user-interruptable point just before the loop occured. If the program could also keep track of registers and variables for some number of changes or period of time, then it could even restore any relevant variables to what they were at the exact moment it decides to take you back to, and with all that work why not also make it spit out debugging for the state it had to break out of? Does this thing do all that? Who wants to write something like that?

If it's good enough you can just roll it in (0)

Anonymous Coward | more than 3 years ago | (#36965478)

Wow, cool idea! If it's good enough you can just roll it into the program and it'll work like you want (end sarcasm).

Possibly useful for AI (0)

Anonymous Coward | more than 3 years ago | (#36965482)

This sounds like a terrible ID for programs written by people for a specific goal. It could be useful for artificial intelligence. We could presume that a learning algorithm would make the infinite loop mistake sometimes.. Being able to break from the loop and try something else would be useful.

But WAIT, it is incomplete... (1)

Anonymous Coward | more than 3 years ago | (#36965498)

This solution serves NO purpose unless it is also accompanied by a modal dialog with this text:

Infinite loop detected! Do you want to break the infinite loop?

With one button labelled "OK".

Remember not to use Jolt on your drivers (0)

Anonymous Coward | more than 3 years ago | (#36965512)

Seems your keyboard handler was stuck in an infinite loop, so I jumped out of the loop for you. You can thank me later...

It's east, look at the post below mine (0)

Anonymous Coward | more than 3 years ago | (#36965522)

It's east, look at the post below mine

Unrealistic use case, limited scope (1)

vivaoporto (1064484) | more than 3 years ago | (#36965542)

From TF Paper

Subject: Thanks

I was writing a document in Word this morning, and after about an hour of unsaved work, Word went into an infinite loop that made the application completely frozen. So, having listened to your talks too many times, I got my debugger, paused the program, changed the program counter to a point a few instructions past the end of the loop, and let it keep running from there. Word went back to working as if nothing had ever happened. I was able to finish my document, save it, and close Word without problems.
So thanks,
Armando.

If that's a real use case scenario, thing must be really different in MIT than they are in the real world. Users, even with a technical background don't have a clue about what an infinite loops looks like, let alone open a debug and move out of it.

If that's the target audience, not having the overhead of the automatic detection for the other 99% and letting the tech savy fend for themselves with the debugger. Also, the scope is too limited.

As the application executes, Jolt compares the current state with the state from the previous iteration. If the states are equal, Jolt has detected an innite loop.

As the paper itself says, it doesn't "detect loops due to recursion or unstructured control ". It could probably be fooled by some busy waiting loop.

Doesn't seem like a serious paper, or something that solves a serious problem.

Infinite loops (1)

dominious (1077089) | more than 3 years ago | (#36965556)

I'm running on a micro-controller you insensitive clods!

Re:Infinite loops (1)

angel'o'sphere (80593) | more than 3 years ago | (#36965830)

My mind state is running on a micro-controller, you insensitive clod!

Illiac had infinite loop detection (5, Interesting)

uigrad_2000 (398500) | more than 3 years ago | (#36965608)

Here at the U of I, we built the 4th computer ever made: the Illiac [wikipedia.org]

24 hours a day, an operator would sit at the computer to operate it. "Software" or jobs would be submitted by faculty. When one finished, the operator would load the next one.

Since only one job could be running at a time, it was quite important to detect infinite loops. The last bit of the ALU was connected to a speaker, and would produce sound similar to static when the computer was running correctly. If an infinite loop was encountered, then the static would suddenly hum a pitch, and the operator would kick out the job, and move to the next.

As the story goes, the very first machine music was written by a math professor, and submitted as an Illiac job, as a prank on the operator. Sometime around 3am, the operator picked up the next job and fed it to the machine. Immediately, the Illiac began playing "Hail to the Orange"!

Re:Illiac had infinite loop detection (0)

Anonymous Coward | more than 3 years ago | (#36965794)

Man, thank you for sharing this awesome piece of computer history ;)

NMI button (1)

equex (747231) | more than 3 years ago | (#36965724)

The Amiga could be soldered to add a button that would trigger the Non Maskable Interrupt, pressing this would throw you back into AsmOne if you got stuck :)

Re:NMI button (1)

Frogking (126462) | more than 3 years ago | (#36965796)

I also remember a program called GOMF (Get Out'a My Face) that let an Amiga user abort a program after the dreaded Guru Meditation Error threatened to crash the entire system. Ah, good times!

Just remember the number 3 (1)

Pete McCann (1949942) | more than 3 years ago | (#36965762)

And listen to Riker this time around.

Breaking my infinite loops would be easy... (1)

kwiqsilver (585008) | more than 3 years ago | (#36965766)

Just make 1 false. However, I can foresee a few unwanted side effects...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?