rao@enuxha.eas.asu.edu (Arun Rao) (09/12/89)
I saw a posting last week (or earlier ?) about someone who kept getting an "Alarm Clock" message while entering text into Xfig on his Mips machine. Did anyone post a fix for this bug ? We have exactly the same problem with our Ardent Titan. The funny thing is that the message persists even after Xfig has aborted - even the 'ls' command will yield "Alarm clock" a few times. What *does* the message mean, anyway ? Thanks in advance. -Arun -- Arun Rao ARPANET: rao@enuxha.eas.asu.edu BITNET: agaxr@asuacvax, agazr@asuacad 950 S. Terrace Road, #B324, Tempe, AZ 85281 Phone: (602) 968-1852 (Home) (602) 965-2657 (Office)
brsmith@umn-cs.CS.UMN.EDU (Brian R. Smith) (09/14/89)
rao@enuxha.eas.asu.edu (Arun Rao) writes: > I saw a posting last week (or earlier ?) about someone who > kept getting an "Alarm Clock" message while entering text > into Xfig on his Mips machine. > Did anyone post a fix for this bug ? We have exactly the > same problem with our Ardent Titan. The funny thing is > that the message persists even after Xfig has aborted - > even the 'ls' command will yield "Alarm clock" a few > times. > What *does* the message mean, anyway ? It's printed by csh when one of its children (commands) dies from the SIGALRM signal. That's probably not helpful, but it is intriguing... maybe you've got a homicidal process hanging around. Brian
kk@hpl-opus.HP.COM (Konstantinos Konstantinides) (09/14/89)
I had the same error when I compiled it on a HP9000/350. The error disappeared when I recompiled it with the -lbsd option. ------------------ K. Konstantinides kk@hpkronos.hplabs.hp.com
guy@auspex.auspex.com (Guy Harris) (09/17/89)
>I had the same error when I compiled it on a HP9000/350. >The error disappeared when I recompiled it with the -lbsd option. Sounds like a BSD signal semantics vs. non-BSD signal semantics problem; in fact, checking "blink.c", that's probably what it is. The problem is that in the original UNIX from Research, when a signal was delivered to a process, the signal action reverted to the "default" action, which was, in most cases, to kill the process - it was the case for SIGALRM. Berkeley changed that in 4.2BSD so that the signal handler wasn't reset, but the signal was "blocked" when the signal was delivered; the process could explicitly unblock it, and if it didn't it would get explicitly unblocked when the signal handler returned. While the BSD behavior is better, it's incompatible, and there's no way to get the old-style behavior; this means people end up writing programs assuming the BSD semantics are the only ones you ever get (especially if they've only worked on BSD systems) and those programs crash and burn on systems without the BSD semantics. One fix would be to put signal(SIGALRM, blink); as the first statement in "blink()". However, since "xfig" already uses one BSDism, namely "setitimer" to get alarm-clock signals with less than one second resolution, you might want to just assume that you're running on a system where you can, somehow, get BSD signal semantics. Try seeing whether your system has the "sigvec" call and, if so, use it instead of "signal" in "blink.c". If not, check for "sigaction" instead.