Re: Panic with 1.7.9p2

• Date: Thu, 7 Mar 1996 06:51:50 PST
• From:
  Zachary DeAquila <zachary@zachs.place.org>
• In-reply-to: Your message of "Wed, 06 Mar 1996 21:05:08 PST." <9603070505.AA07228@kilpikonna.media.mit.edu>

>Date: Wed, 6 Mar 1996 21:05:08 PST
>From: asb@media.mit.edu
>Subject: Re: Panic with 1.7.9p2
>In-Reply-to: "Your message of \"Wed, 06 Mar 96 17:48:53 PST.\"
>             <96Mar6.184854pdt.7634@silk.parc.xerox.com>, 6 Mar"
>To: Pavel Curtis <pavel@parc.xerox.com>
>cc: Amy Bruckman <asb@media-lab.media.mit.edu>, moo-cows.PARC@xerox.com,
>        asb@media.mit.edu
>
>
>  ;#2:crash({"foo"})
>  *** Shutting down: server panic ***
>
>This is again on a Dec Alpha running OSF/1 V3.2A. 
>
>The scary thing is, I didn't even need to suspend!
>Trying this on a Sun SparcStation IPC running SunOs 4.1.3, even with a
>suspend before and after, the task just runs out of seconds.
>
>So the problem is: anyone can easily crash any MOO running on a fast enough
>processor.

This is why max_seconds is adjustable... try doing a binary search for a 
max_seconds value that won't crash the MOO... yes, this involves crashing
a test MOO a lot, but *shrug*.  You know the current value won't work, so 
halve it, etc. until you find a value that "secondses out" before crashing.
Hrm.  Come to think of it though, you could be doing multiple-multiple-multiple 
list concats per turn... but that just raises the value of the base, which
is a much smaller change than the exponent... given that, you might be able
to cause the same crash on a Sun by doing something like
;#2:crash({"foo"}); and
crash being:
return #2:crash({@args, @args, @args, @args, @args ... });
...
Hope this helps...

 --Zachary

• Re: Panic with 1.7.9p2
• From: asb@media.mit.edu

• Prev: Re: Panic with 1.7.9p2
• Next: Paradigm
• Index: MOO-cows
• Thread: MOO-cows