ng@pur-phy (Nicholas J. Giordano) (01/04/88)
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) ;
}ali@rocky.STANFORD.EDU (Ali Ozer) (01/04/88)
In article <969@pur-phy> Nicholas J. Giordano writes: >Several months ago, I accidently discovered something strange about >a clock program I had been using. ... >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. A short while ago Tom Rokicki pointed out to me that if you execute a program without "run," and the program changes its priority, the CLI, upon exit, will have the new priority. Thus the program should probably keep the original priority around, and SetTaskPri() it upon exit: if (me = FindTask(NULL)) oldtaskpri = SetTaskPri (me,newpri); /* At start */ ... if (me) SetTaskPri (me,oldtaskpri); /* At end */ Of course, as you point out, normally clock programs are "run," so they have their own CLIs that go away when the programs exit. So, is it really a problem with SetTaskPri() getting the wrong argument, or is it a problem with CLI getting stuck with a high priority and having some later program not deal with it well? Don't forget that even if the manuals state some system function argument is SHORT, it is still 32 bits and needs to be LONG in Manx. It'd be real strange if SetTaskPri() really required a 16-bit argument. I just ran ledclock (not with "run" but with "ledclock"), exited, and indeed CLI is at priority 5. Then I started up Emacs, exited, etc, and things seem fine. Ali Ozer, ali@rocky.stanford.edu
paolucci@snll-arpagw.UUCP (Sam Paolucci) (04/21/89)
Try the following. Create a directory called "dir". Then try to cd into it by typing "cd dir". It will not work. It comes back with "Bad Args: Keyword needs an argument". The reason is because cd accepts the undocumented keyword "DIR". So in order to do the above you have to type "cd dir=dir". Any comment on this from the people at CATS? -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
andy@cbmvax.UUCP (Andy Finkel) (04/22/89)
In article <97@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >Try the following. Create a directory called "dir". Then try to cd into >it by typing "cd dir". It will not work. It comes back with "Bad Args: >Keyword needs an argument". The reason is because cd accepts the >undocumented keyword "DIR". So in order to do the above you have to >type "cd dir=dir". > >Any comment on this from the people at CATS? CD accepts the documented keyword DIR, actually. (either look in your AmigaDOS manual, or type cd ? to see the keywords) The usual way to get around a conflict between a keyword and a filename (or a directory name) is to use quotes, like this: cd "dir" However, specifying the directory by keyword (as you've done) will also work. You can even (under 1.3) make this the default, ie alias cd cd dir=[] will essentually 'unkeyword' the dir keyword for you. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "There is no programming problem that cannot be solved by proper "application of the Delete command." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
andrews@cos.com (Andrew R. Scholnick) (04/23/89)
In article <97@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > Try the following. Create a directory called "dir". Then try to cd into > it by typing "cd dir". It will not work. It comes back with "Bad Args: > Keyword needs an argument". The reason is because cd accepts the > undocumented keyword "DIR". So in order to do the above you have to > type "cd dir=dir". I just tried it and found that: cd "dir" will also work.... Just so you know.;-) ARS. -- - Andrew R. Scholnick @ Corp. for Open Systems, McLean, VA -- andrews@cos.com - {uunet, sundc, decuac}!cos!andrews -- Everything I write blame on me, NOT -- my employer. - "Adventure is when you toss your life on the scales of -- chance and wait for the pointer to stop." - M. Leinster (First Contact)
AWKSG@UOTTAWA.BITNET (Alan Kelm) (10/16/90)
I have been trying for some time to use VLT to send and receive files
from a remote kermit running on the mainframe. The trouble I have
(I'm using release 1.5 of XPRkermit), is that every time I give
the command (from ARexx):
'FILE GET [myfile]'
VLT puts up a requester asking for the name of the file to get, ignoring
the fact that I have already specified the filename ("myfile"). The
corresponding syntax for the send function:
'FILE SEND [myfile]'
works fine (i.e., it sends "myfile" without putting up a filename requester).
Note that the remote kermit is in server mode, and that VLT External
Protocol Options knows that the mainframe is in server mode (I've also
set Kermit Mode host_server in case that might help).
This operation did work in the older version of VLT (the KG command
did a kermit get). According to the VLT docs, it should only put up a
requester if the file name in the FILE GET command is not specified.
Am I overlooking something? Any help would be appreciated.
- Alan Kelm (awksg@uottawa.bitnet or awksg@acadvm1.UOttawa.CA)