root@qetzal.UUCP (Admin) (08/25/87)
Here is the canonical list of bugs which have been submitted thus
far for the Microport System V/AT product. Supposedly these
bugs should be placed on the form which is supplied elsewhere in
this newsgroup.
Send any bugs to isis!qetzal!uportlist or
ihnp4!upba!qetzal!uportlist.
Until fixes are in the hands of customers,
they will stay on this list. There is supposed to be a new
release available on August 31. At that time, I will go through
and see what can be edited out.
I have reluctantly included the code fragments which "prove"
some of these bugs. I don't currently have a lot of time to go
through and verify that the code fragments prove their point (isn't
that uport's job?). You can expect a new version of this list
sometime in Mid to Late September. Unfortunately, it seems to
be growing by leaps and bounds - rcw@qetzal. (Robert White)
1. dd(1) and mail(1) need to be recompiled with a unsigned long
data length so that they don't say wrong things. (5 minute fixes).
2. csh(1) needs to have variables exported properly. This would
fix several broken programs that require these variables like newgrp(1).
3. malloc(3) and malloc(3X) produce different results sometimes ending
in a core dump (segmentation violation). Working code usig malloc(3)
will fail to run when compiled identically with malloc(3X). This is a
'286 architechure problem with sbrk(2) that Microport knows about and
hates.
4. TSS and double fault panics for seemingly no good reason. No OS
should "just crash". Problem still occurrs in 2.2.2.
5. fdisk(1) has some undocumented features like destroying bad sector
information when changing partitions. Why does Microport need to use a
different means of bad sector forwarding that does the rest of the DOS/
Xenix world? Fdisk(1) should never destroy bad sector information even
when the active partion or any other partition boundry is changed.
6. Shell layering is necessary for people on terminals to do efficient
development. It was promised in advertising in 8/86 and is still in the
to-be-in-the-next-release category.
7. Release of source code for attaching shared memory as the code so far
in packaged form is extremely lacking. (Both shmcreate and shmvidkey
were buggy and not efficient calls from within C.)
8. Console keys can give too many characters to vi(1). This is a SVr2
bug in vi(1) that uses the alarm call. It could be fixed. Also, vi(1)
has a bug in which it will enter ex(1) mode after fast keystrokes (like "yy")
even on terminals.
9. Problems with SIO crashes. This is problem #1 for us right now.
The system will drop characters at any baud rate over 300, and it doesn't
take a lot of coaxing to make it occur (just some load on the serial
ports). Also, the system panics in the driver, routine 'rmsd').
Compiler problems -- specifically:
10. Passing (char *) NULL to a function in a large model program can cause
a core dump/program abort. This makes some programs, which work under
small model, fail under large for no apparent reason. Symptom is that
the dump occurs between the function call and the first executable
instruction in the function itself (usually a Mem fault or Segv)
This blows up a LOT of things, including printf("%s", (char *) NULL)
(or equivalent). Since you quite often are in this situation when you
are reading/writing files in the standard I/O system, you have to code
around the possibility (ie: test first before allowing it to be
called). Not nice! One problem with this in particular is that it is
not consistant -- at least not in terms of what must precede it to
cause a fault. Sometimes it works, sometimes not (more often not).
11. You cannot use an array of pointers to point to >64K of data. This is
a very significant irritant.
12. Varargs problems (dumps core on statements using this capability).
This may be the same problem as (a), in that the unused arguments are
not declared and could default to anything.
13. Potential memory allocation problems -- occasionally a well-behaved
program, ESPECIALLY if using Microports' 'improved' malloc library,
will core dump for no apparent reason. Investigation with 'sdb' shows
that a malloc dumped it, or sometimes a function call will pass junk
instead of the values (instant dump if there's a pointer being passed!)
14. Uucp problems -- these have been acknowledged (jmsully@microp), and they
have told me that HoneyDanber will be an installable option on release
2.3. This might fix the uucp problem entirely. What I get now is an
inordinate number of failed calls, lost packets, etc. Probably at
least mildly related to problem (9). Also, core dumps in -x1-9 modes
(probably related to one or more of the compiler problems).
15. Providing what you say you will. Specically, we received the dialer
upgrade some months ago. The documentation specifically mentions two
programs that are not included in the 'upgrade', and this was a PD
package! We've also had things 'left out' or 'not included' when we order
upgrades, stuff that ANYONE doing development would need -- like a link
kit. Then, of course, they want to charge you (again) to complete your
order...Along this line is the revelation of problems like the serial
panics when asked -- their sales staff has been less than truthful about
this stuff with us in the past. If it simply is a case of 'I don't know',
then they need more education and/or a current bug list on their desks.
16. 2.2.2's wall is broken. No idea how that happened, but 'wall' now gives a
complaint and exits (Bus error - core dumped).
17. Along the same line, so is 'ps' with no arguments (produces nothing,
should show your processes.) 'ps' with arguments works fine. New problem
with 2.2.2.
18. Sdb will sometimes complain "can't allocate memory for symbol table; Goodbye"
Seems as though this is related to the garbaged memory allocation and/or
the (char *) NULL problem, as those traps always seem to produce these
failures of sdb to read the file. (Note: we have 4.5M of memory here,
there is NO reason why SDB cannot get enough core to debug a 250K
executable file!) Happens on large model programs only.
19. File systems larger than 300,000 blocks get trashed repeatedly.
[Need more info - ed.]
20. The version of easyinstall for 2.2.2 is broken. The shell script
crashes after the second question.
21. The documentation is extremely inadequate when attempting to
install a secondary hard disk. I've destroyed the partition
table on my PRIMARY hard disk numerous times.
22. The requirements for adding additional memory cards to the
system needs to be stated. NMI errors occur if the wrong types
of cards are used.
23. Many if not all shell scripts distributed do not include a ':'
character at the beginning. This means that the user must edit
each shell script when it is distributed so that it will run
under csh.
24. System will panic if the line printer is switched off during
printing. This problem is reproducible. I hope YOUR printer
doesn't suddenly run out of paper.
25. vi will hang occasionally when editing text files. Half of the
file will be displayed, vi will not then respond to any
keystrokes. User must log on to another tty then kill -9 the
process, then do stty to restore sanity. This problem is not
easily reproduced.
26. Cron likes to fire up jobs more than once. This is very nasty
when the job scheduled to run is rnews.
27. Microport clock still can not keep sane time. The clock worked
lots better in 1.3.8. This becomes a real pain when using nifty
things like pc-pursuit which one must'nt call at the wrong time.
28. Preconditions for re-linking the kernel are not well documented.
You must be using /bin/sh, and the variable SHELL must be set to
/bin/sh.
29. When compiling a few large programs (hack, jove) I found that ld will
hang if there is no space left on the disk. It would be nice if
microport had provided a "no space left" message on the system console.
30. Bell Technology's hard drives will not work under 2.2 as a
second hard drive mounted on /usr.
31. Wrong results are yielded with the math library on AT-3 with
the math coprocessor. In C, the log function returns positive
values for arguments .8 and .9.
Priority: URGENT.
Submitted By: Carel Braam, seismo!mcvax!eutrc3!rccarel (Netherlands)
Code sample: Yes.
Workaround: get the System-V sources for libm.a and recompile.
#include <math.h>
main()
{
double x;
for (x = 0.1; x < 1.0; x += 0.1)
printf("log(%g) = %g\n",x,log(x));
}
[ed - Bugs numbered 32 - 43 were submitted by:
Carel Braam, seismo!mcvax!eutrc3!rccarel (Netherlands)]
32. A C compiler floating point problem. In some cases (e.g. the
the operands are array elements with negative indices)
the result of the addition of two numbers depends on the order
of the operands. There are similar problems with subtraction.
/*
** Floating-point problem with the Microport V2.2L c compiler.
**
** The following yacc-generated program fragment prints:
**
** 3 + 2 = 2
** 2 + 3 = 5
**
*/
double x[3];
double yyval;
main()
{
register double *yypvt = x+2;
yypvt[-0] = 2;
yypvt[-2] = 3;
yyval = yypvt[-2] + yypvt[-0];
printf("%g + %g = %g\n",yypvt[-2],yypvt[-0],yyval);
yyval = yypvt[-0] + yypvt[-2];
printf("%g + %g = %g\n",yypvt[-0],yypvt[-2],yyval);
}
33. C compiler floating point problem.
Complicated conditional expressions give wrong results.
e.g. min(abs(3),1.0*(7)) = 7, in which min and abs are macros
generating conditional expressions.
34. The fortran-77 i/o system does not work with large memory models.
The following (ratfor) program detects end-of-file after the first
read, even if there is more data available:
program junk
integer aap(80)
998 format(80a1)
for (;;) {
read(5,998,end=999) (aap(i),i=1,80)
write(*,998) (aap(i),i=1,80)
}
999
end
35. The program verifier lint chokes on initializations of arrays
of character pointers:
char *junk[] = { "one", "two", "three" };
produces a "cannot recover" diagnostic from lint.
36. The debugger sdb, when producing a stack trace, suggests that
functions are called with arguments even when they are not.
37. Attempting to format a diskette in /dev/rdsk/fd, while a tar archive
is being read from /dev/dsk/fd148, will corrupt the latter diskette.
38. System will hang occasionally when using tar to write files to
AT style floppies. The tar cannot be killed with kill -9, the
system has to be rebooted. Submitted by: rcw@qetzal
39. Signal handling is incorrect when a process is created from within vi;
vi dumps core when a quit signal is generated (usually with the DEL key);
process created from within vi are not affected by quit or interrupt
signals. Reason: after the fork(), signals are enabled/disabled in
the wrong branch.
40. `Double panic: tss fault' occurs when the floppy in drive A is write
protected and an attempt is made to write more than one file to it with
cpio:
ls|cpio -ocv > /dev/rdsk/fd096
41. When the large memory model is used, conditional expression statement
returning pointers generate a compiler error:
/*
** cc -Ml bug.c
** "bug.c", line 26: compiler error: register allocation error
**
*/
#define getnode(p) (((p)->val) == -1 ? (p) : r_getnode(p))
struct node {
int val;
struct node *next;
};
struct node *r_getnode (p)
struct node *p;
{
return (getnode (p->next));
}
main ()
{
struct node *p;
getnode (p);
}
42. 'Double panic: tss fault' occurs when characters are received
on a serial port immediately after a hangup (data carrier detect
changes state) causing problems with intelligent modems.
43. Compiler error: register allocation error in C-compiler when the large
memory model is used. This compiler error is given in the case that
conditional expression statements returning pointers are used.
Repeat by:
44. Problem using && and || operators in csh.
$ sh
$ echo x && echo x
x
x
$ csh
% echo x && echo x
x
% exit
$ -- the question is where is the second x in the csh 'echo x && echo x'
verdict the '&&' and '||' operators have been mixed up in the csh !!!
43. Bug in "rm".
try
$ touch xfilex yfiley
$ rm .. xfilex yfiley
Please explain the error message, and why xfilex and yfiley
still exist!! actually this isnt really your problem, its a
ported bug and exists both on our pyramid and our tower!
44. Csh commands with a wild character in it causes a core dump.
for example:
setenv x `ls *`