infinite loop detection

[Steven Woody]

i have a program which always run dead after one or two days, i think
somewhere a piece of the code is suspicious of involving into a
infinite loop. but for some reason, it is very hard to debug. so i
thing there might be tool which can statically analysis the code and
notice me this kind of potential problems if found. any suggestion? (
i prefer linux open source tools )

thanks.

-
woody

 

[Walter Roberson]

i have a program which always run dead after one or two days, i think
somewhere a piece of the code is suspicious of involving into a
infinite loop. but for some reason, it is very hard to debug. so i
thing there might be tool which can statically analysis the code and
notice me this kind of potential problems if found. any suggestion? (
i prefer linux open source tools )

http://en.wikipedia.org/wiki/Halting_problem

 

[Christopher Benson-Manica]

1) As Walter pointed out, your problem does not have a general
solution.

2) It is possible that there is some open-source code analysis tool
that may be able to use a heuristic to identify potential bugs, but
this newsgroup is not the place to ask about it:

http://www.ungerhu.com/jxh/clc.welcome.txt
http://c-faq.com
http://benpfaff.org/writings/clc/off-topic.html

3) Even if you found such a tool, what makes you think that your
problem is an infinite loop? How do you know that you do not have a
memory leak, for exmaple?

4) I'm sure comp.unix.programmer would be able to suggest good
debugging tools and techniques to help you solve your problem.

 

[Christopher Benson-Manica]

(Apologies to those who see a duplicate of this message, the original
was mis-posted as a reply to Walter's post rather than to OP.)

i have a program which always run dead after one or two days, i think
somewhere a piece of the code is suspicious of involving into a
infinite loop. but for some reason, it is very hard to debug. so i
thing there might be tool which can statically analysis the code and
notice me this kind of potential problems if found. any suggestion? (
i prefer linux open source tools )

1) As Walter pointed out, your problem does not have a general
solution.

2) It is possible that there is some open-source code analysis tool
that may be able to use a heuristic to identify potential bugs, but
this newsgroup is not the place to ask about it:

http://www.ungerhu.com/jxh/clc.welcome.txt
http://c-faq.com
http://benpfaff.org/writings/clc/off-topic.html

3) Even if you found such a tool, what makes you think that your
problem is an infinite loop? How do you know that you do not have a
memory leak, for exmaple?

4) I'm sure comp.unix.programmer would be able to suggest good
debugging tools and techniques to help you solve your problem.

 

[Steven Woody]

1) As Walter pointed out, your problem does not have a general
solution.

2) It is possible that there is some open-source code analysis tool
that may be able to use a heuristic to identify potential bugs, but
this newsgroup is not the place to ask about it:

http://www.ungerhu.com/jxh/clc.welcome.txt
http://c-faq.com
http://benpfaff.org/writings/clc/off-topic.html

3) Even if you found such a tool, what makes you think that your
problem is an infinite loop? How do you know that you do not have a
memory leak, for exmaple?

i am wondering what kind of memory leak can cause halting?

4) I'm sure comp.unix.programmer would be able to suggest good
debugging tools and techniques to help you solve your problem.

ok, i will try.

 

[Walter Roberson]

i am wondering what kind of memory leak can cause halting?

<OT>
It depends on the operating system and the way it is configured.
After you run through all the readily available
memory, the system will usually do one of the following:

1) Return a NULL pointer for a memory allocation request. If you
don't check for NULL then there are lots of different behaviours
that you can run into;

2) stop your program without warning when it asks for more memory

3) tell your program it is out of memory, with the telling being done
in a way that -could- be noticed and dealt with cleanly, but usually
is not dealt with explicitly with the result being that the program
stops

4) stop your program without warning (or with warning as per #3) some
time -after- it runs through all the available memory, because it
told you you could have more memory than was really available
[because it thought you weren't serious about using *all* of it,
or because it thought that by the time you actually used it, that
it would have more memory available to give you.]
(Note: not really using all requested memory is quite common in
unix-type systems: it happens often when fork() is used.)

5) And on some systems, as long as you don't allocate more memory
than a pointer can possibly reference, the operating system will
continue to give you more and more memory, by allocating disk space
as if it were system memory. Sometimes this strategy is very
effective and the result is quite fast, but in other cases
the strategy results in the computer operating *very* *very* slowly.
</OT>

<OT degree="moreso">
I've been using Opteron nodes running Debian Linux lately. The nodes
have 8.5 to 11 gigabytes of RAM. It's pathetically easy to get them
swapping to the point where they drop input (not just -slow- response:
they *drop* it even though the buffers are not even close to full.)
We seldom encounter serious swapping problems on our SGI IRIX machines,
and the few times we do, the response drops but there -is- still response.
</OT>

 

[David Resnick]

i have a program which always run dead after one or two days, i think
somewhere a piece of the code is suspicious of involving into a
infinite loop. but for some reason, it is very hard to debug. so i
thing there might be tool which can statically analysis the code and
notice me this kind of potential problems if found. any suggestion? (
i prefer linux open source tools )

thanks.

-
woody

So a platform independant answer is that you could add some more
logging (fprintfs/whatever you are using) so you know where your
program is and what it is doing once it fails by whatever means it
fails -- which not too clear to me. Do you mean by infinite loop that
it is spinning, burning CPU, but not using other resources in an
increasing way that would cause the system to run out of memory/etc?

Or ask in comp.unix.programmer or a linux group. Someone can probably
direct you at a way to, e.g., attach a debugger to your program and see
what it is currently executing (assuming by "dead" you mean up but not
responsive/etc) or making it dump a core and analyze it/etc.

-David

 

[inmatarian]

i have a program which always run dead after one or two days, i think
somewhere a piece of the code is suspicious of involving into a
infinite loop. but for some reason, it is very hard to debug. so i
thing there might be tool which can statically analysis the code and
notice me this kind of potential problems if found. any suggestion? (
i prefer linux open source tools )

thanks.

-
woody

If you can alter the code in question, where you think infinite loops
are happening, add an extra terminating condition. Or, if that's not an
option, start some kind of timer based callback, or even a thread,
which'll monitor the program and tell you where it's running dead.

Inmatarian.

 

[Steven Woody]

If you can alter the code in question, where you think infinite loops
are happening, add an extra terminating condition. Or, if that's not an
option, start some kind of timer based callback, or even a thread,
which'll monitor the program and tell you where it's running dead.

Inmatarian.

thank you all. actually, the program was written in linux and
cross-compliled before running in a microcontroller where there is no
extra serial port to print out debug info. any invalid point reference
in the platform will cause a reboot rather halt, this leads me think
the problem is a infinite loop. another thing is that i only use few of
malloc operations that is not likely be the cause.

 

[Flash Gordon]

thank you all. actually, the program was written in linux and
cross-compliled before running in a microcontroller where there is no
extra serial port to print out debug info.

Hook up an in-circuit emulator. Or a logic analyser. Or get the program
to change the state of a couple of pins depending on what it is doing
and hook up an oscilloscope. Or write harnesses to allow you to run the
code on some other system such as your PC. I've used all of these methods.

> any invalid point reference
in the platform will cause a reboot rather halt,

It could be going in to a reboot loop.

> this leads me think
the problem is a infinite loop.

You will have to find some method to identify where the code is failing.
Identifying if there are infinite loops is, in general, not possible by
static analysis.

> another thing is that i only use few of
malloc operations that is not likely be the cause.

It only takes one memory corruption (by overrunning a buffer for
example) for the next call to malloc to potentially crash in some manner.

Until you either identify where the code is crashing or manage to
*prove* that some areas are not the problem area, the problem could be
anywhere and caused by any form of undefined error or by some logic
error in your code.

 

[pete]

i have a program which always run dead after one or two days,

The cpu is overheating.