mdapoz@hybrid.UUCP (Mark Dapoz) (10/16/89)
I think I may have stumbled across a bug in the ipc code recently posted. I
was working on trying to write a program which uses the locking(3C) facilities
and I kept running into problems. Whenever I would call the locking() routine,
it would always return with an error, which perror indicates is invalid address.
If I remove the ipc device driver, the program works just fine. I don't know
what the ipc device driver is doing, but whatever it is, it sure does interfere
with the locking() routine. Below is the program which shows this behaviour.
The following error is reported when run with the ipc device driver.
Locking.......
lock: Bad address
The program should just lock the file "mutex" (create the file before running
the program) and then unlock it.
-mark
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
main()
{
int fd;
if ((fd = open("mutex", O_RDONLY)) < 0 ) {
perror("open");
exit(1);
}
printf("Locking.......\n");
if (locking(fd, F_LOCK, 0L) < 0) {
perror("lock");
exit(1);
}
sleep(5);
printf("Unlocking.......\n");
if (locking(fd, F_ULOCK, 0L) < 0) {
perror("unlock");
exit(1);
}
}
--
Mark Dapoz (mdapoz@hybrid.UUCP) ...uunet!mnetor!hybrid!mdapoz
I remind you that humans are only a tiny minority in this galaxy.
-- Spock, "The Apple," stardate 3715.6.alex@umbc3.UMBC.EDU (Alex S. Crain) (10/19/89)
In article <1989Oct16.032605.279@hybrid.UUCP> mdapoz@hybrid.UUCP (Mark Dapoz) writes: >I think I may have stumbled across a bug in the ipc code recently posted. I >was working on trying to write a program which uses the locking(3C) facilities >and I kept running into problems. Whenever I would call the locking() routine, >it would always return with an error, which perror indicates is invalid address. I got a bug report on this awhile back, which I shelved until I could verify it, but it looks like you just did that (I gotta get a machine!). The problem was discovered by Brad Bosch, who sent mail to me which I promptly forgot all about until today, when I recognised it. Suggestions that I don't have it together will should be mailed to me so that I can lose them promptly :-). In any case, the problem is that instead of trapping through syslocal(), the code traps through locking(). The fix is to change the trap number from 67 to 68. Below are the diffs to accomplish this. I've put up a new version (1.3.1) for ftp from umbc3 taht has this patch already. ################################# :alex. #Disclamer: Anyone who agrees # University of Maryland Baltimore County #with me deserves what they get.# alex@umbc3.umbc.edu ################################# *** sysconfig.m4~ Thu Oct 19 11:48:30 1989 --- sysconfig.m4 Thu Oct 19 11:53:06 1989 *************** *** 10,16 # # the syscall number for syslocal() # ! define(SYSL_SYSCALL, 67) # # the offset of the last known local system call. # --- 10,16 ----- # # the syscall number for syslocal() # ! define(SYSL_SYSCALL, 68) # # the offset of the last known local system call. # *** lib/generic.m4~ Thu Oct 19 12:12:02 1989 --- lib/generic.m4 Thu Oct 19 12:12:50 1989 *************** *** 11,17 SYSCALL_NAME: mov.l (%sp),-(%sp) # move the return address mov.l &SYSCALL_NUMBER,4(%sp) # insert the first argum ent ! mov.w &67,%d0 # trap &0 # trap to syslocal() bcc noerror # return if status = 0 jmp __cerror # otherwise __cerror() --- 11,17 ----- SYSCALL_NAME: mov.l (%sp),-(%sp) # move the return address mov.l &SYSCALL_NUMBER,4(%sp) # insert the first argum ent ! mov.w &SYSL_SYSCALL,%d0 # trap &0 # trap to syslocal() bcc noerror # return if status = 0 jmp __cerror # otherwise __cerror() -- ################################# :alex. #Disclamer: Anyone who agrees # University of Maryland Baltimore County #with me deserves what they get.# alex@umbc3.umbc.edu #################################