Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!rutgers!iuvax!pur-ee!pur-phy!ng
From: ng@pur-phy (Nicholas J. Giordano)
Newsgroups: comp.sys.amiga
Subject: Bug(?) in SetTaskPri and recent Clock programs
Message-ID: <969@pur-phy>
Date: 3 Jan 88 22:14:25 GMT
References: <249@draken.nada.kth.se>
Reply-To: ng@newton.physics.purdue.edu.UUCP (Nicholas J. Giordano)
Organization: Purdue Univ. Physics Dept., W. Lafayette, IN
Lines: 90
Keywords: SetTaskPri, ledclock.c, clock.c
Summary: Incorrect (?) use of SetTaskPri and visits to the Guru




Several months ago, I accidently discovered something strange about
a clock program I had been using.  The program was written by M. Meyer
and D. Wecker; it opens a small window (that fits easily into a title
bar) and displays the time and the available memory.  
This program demonstrates a quirk which can crash the system.  
A different clock program named "ledclock" was recently posted to
the net; it seems to have the same "bug", and this prompted me
to finally try to track it down.  

After a little hunting, I distilled the problem to one line of code, 
and the two test programs given below show the culprit.

Here is the scenario.  First you run a program, like the clock program,
which sets its priority to some higher value using SetTaskPri.
The program then exits, without setting the priority back to
(usually) zero.  Then you try to use the Manx Z editor, and you
immediately visit the Guru.  

The problem seems to be with incorrect calls to SetTaskPri.  The second
argument is the new priority, and should be a SHORT.  However, the
clock program mentioned above, along with the ledclock program posted
recently, uses a LONG argument.  Using an argument of the wrong type
sort of works; if you examine the priority of the task from another
cli, you find the intended value.  However, this leads to Mr. Guru as
described above.  

The test programs below illustrate this program.  Compile them with
Manx 3.4a and 16 bit ints.  Run one, then run the Z editor, and see what
happens.  Hint: there is no problem with the second one, but after the
first one the machine will crash.

So, what gives?  Something seems a little strange about SetTaskPri,
although you can't really blame it for not liking arguments of the wrong
type.  However, the problem suggests that SetTaskPri makes some unwanted
changes in the lists of system tasks, which may indicate a problem
with this function.
At the least, people should use shorts for the second argument.
For programs like clock.c and ledclock.c, this problem usually is not
fatal, since these are intended to run from a separate cli, and never exit.
However, it would seem best to fix this problem.

Any comments??

Nick Giordano
Physics Department
Purdue University

**************************************************************

/* test2.c
 *
 *	try to track down bug with clock.c
 *
 *	this program will crash the machine if the Z editor is run
 *	from the same cli after it terminates
 *
 *	compile with Manx 3.4a with 16 bit ints
 */

#include <functions.h> 
#define NULL ((void *)0)

main() 
{
	SetTaskPri( (long)FindTask(NULL) , 20L) ;
}

****************************************************************

/* test3.c
 *
 *	try to track down bug with clock.c
 *
 *	this program will NOT crash the machine if the Z editor is run
 *	from the same cli after it terminates
 *
 *	compile with Manx 3.4a with 16 bit ints
 */

#include <functions.h> 
#define NULL ((void *)0)

main() 
{
	SetTaskPri( (long)FindTask(NULL) , 20L) ;
	SetTaskPri( (long)FindTask(NULL) , 0L) ;
}