cly (08/09/82)
A bug in the signal.s library routine (UNIX 3.0.1, 4.2,
and possibly 5.0) has been found.
***************************************************
The following indicates the problem:
1. A process calls signal(2) to set signal x to be caught.
2. The process calls signal(2) again to change the disposition
to either "ignore" or "default".
3. While attempting the change, the process is switched between point XXXXX
and YYYYY in the signal.s code below.
_signal:
mov r5,-(sp)
mov sp,r5
mov 4(r5),r1 / signal
cmp r1,$NSIG
bhis 2f
mov 6(r5),r0 / func (catch addr, 0, or 1)
mov r1,0f
asl r1
mov dvect(r1),-(sp) / save current func
mov r0,dvect(r1) / set vector in user's data area
XXXXX
mov r0,0f+2
beq 1f
bit $1,r0
bne 1f
asl r1
add $tvect,r1
mov r1,0f+2
1:
YYYYY
sys 0; 9f / call ssig to update ublock
4. While switched, a signal comes in of type x.
5. Since the vector slot in user data has been changed to a
0 or a 1, but the system call to update the ublock has
not occurred, a jsr to the address found in location
0 or 1 will be attempted with disasterous results.
One fix (implemented in our system) is to check the current
disposition and then call ssig BEFORE setting the vector
in the above case. If the current disposition is "default"
or "ignore" and you are changing to "catch", the vector
must still be set before calling ssig as is currently done.
Carl Yaffey, Columbus BTL x3399
rmas70!cly