jshortle@jarthur.Claremont.EDU (John Shortle) (04/20/89)
Hello. We are running rn version 4.3.1.4 on a Sequent Symmetry 81, Dynix 3.0.12. We are having a few subtle problems: 1) rn does not append to save files. If one tries to save a message onto a file that already exists, rn responds: Caught a SIGSEGV--.newsrc restored Illegal instruction (exit to shell) 2) rn does not let one resume from a stopped job. If one stops rn (^Z) from any level below the newsgroup selection level and tries to resume, rn responds: rn rn read error: Inappropriate ioctl for device Caught an internal error--.newsrc restored (exit to shell, job/process killed) We formerly ran the same version of rn on a Vax 11750, 4.3bsd, and did not have any of these problems. Does anyone know how to fix these problems? Please reply by E-mail. Thanks. John Shortle
nagel@beaver.ics.uci.edu (Mark Nagel) (04/23/89)
In article <906@jarthur.Claremont.EDU>, jshortle@jarthur (John Shortle) writes: [I'd email, but I have my own questions + the answer might be useful to others.] |1) rn does not append to save files. If one tries to save a message onto a |file that already exists, rn responds: | Caught a SIGSEGV--.newsrc restored | Illegal instruction |(exit to shell) We run rn on a Symmetry, but I've never seen this behavior. I've seen other bothersome behavior in saving articles, though. For example, for certain users in certain newsgroups, articles can not be saved. Period. I've traced through rn all the way up to the fork of norm.saver, but I've never been able to tell why the script doesn't execute. Sorry I can't help you here... |2) rn does not let one resume from a stopped job. If one stops rn (^Z) from |any level below the newsgroup selection level and tries to resume, rn |responds: | rn | rn read error: Inappropriate ioctl for device | | Caught an internal error--.newsrc restored |(exit to shell, job/process killed) I *can* help with this one. I fixed this a long time ago on the Balance where the problem also exists. I don't have patches or anything, but hopefully I can describe this well enough for you to plunge into the code. What happens is that during the main command loop read function, the value of errno is set to zero prior to the actual read system call. After the read, the valu of errno is checked. Well guess what happens when you hit ^Z. The sigtstp handler function gets called to save some state information, etc. Then when you re-enter rn, the sigcont handler gets called. This also does various things, many of them involving system calls. The result of all of this is that the value of errno gets changed somewhere in these handlers, probably multiple times. The solution is to add a statement to reset errno to zero just prior to returning from the sigcont handler. I installed this fix over a year ago and have had no such problems since. I have no idea why other systems seem to emerge from this program fault unscathed. Mark Nagel @ UC Irvine, Department of Information and Computer Science +----------------------------------------+ ARPA: nagel@ics.uci.edu | Charisma doesn't have jelly in the | UUCP: ucbvax!ucivax!nagel | middle. -- Jim Ignatowski |