dpw@rayssd.UUCP (Darryl P. Wagoner) (08/22/86)
On both larn11.0 and larn12.0 I have ran across this bug
where in casting spells like "lit" it will get hung in
loop. It doesn't happen everytime. Has this happen on
other system ? Does anyone have a fix for this. Signals
are still taken care of, but otherwise it is locked up.
My quick fix is going to be to ask the player when he hit
the interrupt key. But that is just a hack to get it to recover.
If no else has fixed this I will jump into it some weekend.
--
Darryl Wagoner
Raytheon Co.; Portsmouth RI; (401)-847-8000 x4089
best path {allegra|gatech|mirror|raybed2} ---------\
next best {linus|ihnp4|pyrbos} ---------------------->!rayssd!dpw
if all else fails {brunix|cci632} -------------------------/kaufman@Shasta.STANFORD.EDU (Marc Kaufman) (08/24/86)
In article <89@rayssd.UUCP> dpw@rayssd.UUCP (Darryl P. Wagoner) writes: >On both larn11.0 and larn12.0 I have ran across this bug >where in casting spells like "lit" it will get hung in >loop... Look at 'godirect' (in monster.c) and 'napms' (the sleep/delay routine). I ran into a problem with sending the wrong size parameter (short vs. long) to the napms routine, because on my machine ints are 16 bits. The system hangs up waiting an arbitrarily long period of time..
arnold@socrates.ucsf.edu (Ken Arnold%CGL) (08/28/86)
In article <794@Shasta.STANFORD.EDU> kaufman@Shasta.UUCP (Marc Kaufman) writes: >In article <89@rayssd.UUCP> dpw@rayssd.UUCP (Darryl P. Wagoner) writes: >>On both larn11.0 and larn12.0 I have ran across this bug >>where in casting spells like "lit" it will get hung in >>loop... >Look at 'godirect' (in monster.c) and 'napms' (the sleep/delay routine). >I ran into a problem with sending the wrong size parameter (short vs. long) >to the napms routine, because on my machine ints are 16 bits. >The system hangs up waiting an arbitrarily long period of time.. It's worse than that. The code for SYSV namps() is something like the following: get current time figure out the future time which is the current time + delay while (time to stop < current time) continue; return Well, that loop should be while (time to stop > current time) continue; This fails harmlessly as long as "time to stop" is greater than the current time at the start of the loop. However, the delay for the "lit" spell is so small that it is quite possible (quite probable, actually) that the current time at the start of the loop is later than the expected time to stop. Which means the loop goes on forever. Which is your bug, even after the short vs. long type problem. I tried to send this bug to the author and/or his friend and found myself singularly unsuccessful in reaching either one. Would either of them like to mail me a note? I have some other useful fixes ... Ken Arnold