Killing a looping oorexx program

Occasionally, while developing a program, I'll end up with one in an
infinite loop.

Usually, I can Ctrl+C (^C) it, and that's an end to it. But quite
often, the program stops looping, but the interpreter goes into a loop
instead.

Sometimes, these looping threads cannot be killed without root access
(this is on a Debian system, but I've seen the same loops on other
Linuxes)

As a bug report, the above would be pretty pathetic, but it's all I
really have to go on. I could try to develop a testcase (or wait for
the next accidental one), but for obvious reasons I'm not too keen on
deliberately creating tasks that consume 99% of the CPU and cannot
(easily) be killed. I prefer to stay on good terms with root. He has a
sticker on his laptop:

"Bow before me, for I am root."

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

Swifty wrote:

> but the interpreter goes into a loop
> instead.

How do you know it is the interpreter ?
Could it be a signal handler, in the sript or in the environment around the
interpreter ?

This problem happens sometime at work, but I always blamed our own software.
Our implementation sets the old interpreter aside and starts a new one, but
if the old interpreter maintains file locks or exhausts resources of the
java environment then this solution doesn't help.
Sometimes it helps if the script sends spaces to the environment (sort of
'breakpoint') as if accessing the environment helps in executing Ctrl+C.

Also there is the rxapi daemon/system service which users can't kill, but I
don't know what role it plays.

Cheers, Uli

"U.Zinngrebe" <Name@inter.NL.net> wrote:

> Also there is the rxapi daemon/system service which users can't kill, but
> I don't know what role it plays.

I opened a bug quite a while ago (for ooREXX V4.0.0) -
https://sourceforge.net/tracker/?fun...roup_id=119701

having found several instances of rxapi listed in Windows XP's task manager.
It was only by accident that I noticed - usually I have the tasks listed in
decreasing CPU% order but had re-sorted the display to look at stuff by task
name, and happened to scroll past the "R"s.

I noticed four rxapi tasks a week or two ago, and revisited the bug report.
As I have no idea how often this happens I now have a Scheduled Task (XP's
equivalent of cron) running an exec every 5 minutes looking at the number of
rxapi tasks active (via SysInternals' pslist utility). If it finds more
than one task, as well as telling me immediately, it logs the task tree and
other detailed info. The logging happens even for normal cases a few times
per day so I get confirmation that the whole process is working properly. So
far, it's not happened again.

--
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".

On Fri, 02 Mar 2012 00:11:01 +0100, "U.Zinngrebe" <Name@inter.NL.net>
wrote:

>How do you know it is the interpreter ?
>Could it be a signal handler, in the sript or in the environment around the
>interpreter ?

Because the PS command, or the TOP command in linux indicates that the
running executable clocking up all the CPU is "rexx". Since my program
has stopped, all that is left is the rexx interpreter. I know my
program has stopped, because the loop (in my code) was putting out
messages in some cases.

My programs (especially the "quick fix" variety) often don't contain
signal handlers. One case in point, the program consisted of a single
"Do until ..." loop but a spelling mistake in the "until" clause
turned it into an infinite loop.

OK, there may be some funny stuff going on between linux itself and
the interpreter, but being assigned to the interpreter's process. This
would affect other executables than just rexx, so would probably have
been fixed by now.

Anyhow, in the end it comes down to the fact that ^C sometimes kills
the rexx program, and sometimes it turns it into a thread which only
root can kill, and even then, only by using the most powerful forms of
the kill command. We had a couple of processes that even root couldn't
kill. They were not looping, so it didn't matter much, but we had to
schedule a reboot to tidy up.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk