[Prev][Next][Index][Thread]

# IMPORTANT LambdaMOO patch release 1.8.0p4

- Date: Thu, 18 Apr 1996 18:43:56 PDT
- From:
- Fake-Sender: pavel@parc.xerox.com

    I have released version 1.8.0p4 of the LambdaMOO server to the usual place:

    	ftp://ftp.parc.xerox.com/pub/MOO/LambdaMOO-1.8.0p4.tar.Z

    This is a very nasty bug-fix release.  I mean that both ways: both the bug and
    the release are nasty.  PLEASE READ the following change-log entry very
    carefully if you are currently running a server of versions 1.8.0 through
    1.8.0p3.  I'm sorry the entry is so long and messy, but this one was a pretty
    nasty screw-up on my part.

    	Pavel

    Here's the ChangeLog.txt entry:
    -------------------------------------------------------------------------------
    Version 1.8.0p4, 18 April 1996
    -- Fixed potential memory-smash bug in the parsing of a misplaced `$'
       expression.  (Thanks to Brack for reporting this.)
    -- Fixed odd choice of errors raised by chparent(A, B); it used to raise E_PERM
       when A was not valid or B was neither valid nor equal to #-1.  It now raises
       E_INVARG in these cases.
    -- Fixed *really* nasty bug in the way the $bf_FOO() overrides for protected
       built-in functions were implemented.  The first (and least nasty!) effect
       was a potential memory smash and/or server panic if you killed a task that
       was in the middle of a call to some $bf_FOO().  (Thanks to slayer@kaiwan.com
       for reporting this effect of the bug and thereby ruining the rest of my day,
       spent tracking down and trying to cope with the *rest* of the effects.)  The
       more subtle and terrifying effect is given below.
       ********** There was a serious bug in versions 1.8.0 through 1.8.0p3 of the
       ** NOTE ** server that could cause a database written by such a server to be
       ********** read back in incorrectly and, in some cases, *undetectably*,
       causing one or more bad effects outlined below.  One of the potential
       effects, perhaps the most serious one, *is* detectable and fixable; release
       1.8.0p4 of the server detects and fixes this problem during loading.  If it
       discovers/fixes an instance of the problem, it also prints a warning message
       into the log.
       ----------------------------------------------------------------------------
       NOTE PLEASE: As described below, most databases will NOT be at risk from ANY
       of the potential problems.  I only describe them in this much detail to make
       sure that all POSSIBLE cases are disclosed.
       ----------------------------------------------------------------------------
          In a nutshell, the problem is that the server can write out a database
       file that, on reloading, makes it look as if an overridden built-in function
       (i.e., one that is made wiz-only by a $server_options.protect_FOO property
       and then overridden by a $bf_FOO() verb) *made a verb call* to $bf_FOO()
       instead of being *replaced* by that verb.  This would be in the saved state
       of some task that was suspended at the time the database file was written.
       This means that, after the task resumes and the call to $bf_FOO() returns,
       the built-in function implementation could be re-entered in a very confused
       state.  This confusion could have the following effects:
    	1) A function that never actually calls a verb (i.e., almost any of the
    	   current built-in functions) could mistake $bf_FOO()'s returned value
    	   for an argument list and smash memory all over the server.
    	   (Fortunately, this is the detectable and fixable case mentioned
    	   above; therefore, this effect cannot happen under 1.8.0p4.)
    	2) The eval() function could end up wrapping an extra {1, ...} around
    	   the correct returned value.  That is, instead of returning {F, V} as
    	   it should, it would return {1, {F, V}} in this case.
    	3) The create() function could return a different object number from
    	   the correct one; in particular, it could return an invalid or even
    	   negative object number.
    	4) The recycle() function could recycle the wrong object, without
    	   checking permissions and without calling that object's :recycle
    	   verb, and/or leave the correct object unrecycled.
    	5) The move() function could move the wrong object to the wrong
    	   destination and/or leave the correct object where it was.
       If you reboot your server under 1.8.0p4, I believe that effect (1) above is
       completely prevented and that, in effects (4) and (5), the function in
       question is extremely unlikely to operate on the wrong object.  If you are
       actually at risk from any of these effects (see below), then by far the most
       likely cases are as follows:
    	1) Not possible.
    	2) The eval() function will have the full effect given above.
    	3) The create() function will have the full effect given above.
    	4) The correct object will not actually be recycled, even though its
    	   :recycle verb will have been called.
    	5) The correct object will not actually be moved, even though the
    	   destination's :accept verb will have been called.
       >>> NOT ALL DATABASES ARE AT RISK FROM THESE EFFECTS <<<
          For a database to be at risk, all of the following must be true:
    	a) One or more of the functions eval(), create(), recycle(), or move()
    	   must have been made wiz-only via the $server_options.protect_FOO
    	   property, for the appropriate FOO.
    	b) Such a function must have been overridden by a $bf_FOO() verb.
    	c) It must have been possible for the code of the $bf_FOO() verb (or
    	   any code it calls) to call suspend().
    	d) The database file must have been written to disk (i.e., either via a
    	   checkpoint or a shutdown or a panic) during the time that (a) and
    	   (b) were true and while the call to $bf_FOO() was suspended.
    	e) You must be restarting your server from the database mentioned in
    	   point (d).
       Even in a database that is at risk, it is only at risk for the effects of
       the specific function(s) for which all of points (a) through (e) are true.
       For example, if you have never protected and overridden the move() function,
       then your database is not at risk for effect (5).
         These facts imply that, if your server might be at risk but is still
       running under 1.8.0p3 or earlier, you may be able to remove the risk before
       shutting down, by making one or more of points (a) through (e) false.  For
       example, you might be able to stop overriding one of the functions in
       question and then wait until there are no longer any suspended tasks inside
       calls to the appropriate $bf_FOO() verb.
          >>> WARNING: Do NOT attempt to kill such a suspended task in order to
    		   remove the risk from your system; this would trigger the bug
    		   mentioned at the top of this release note, quite possibly
    		   panicking your server.
       Naturally, I am dismayed at both the existence of this bug and at the fact
       that I cannot guarantee even those not yet bitten by it that they can avoid
       eventually losing.  This is the first time I can recall this sort of thing
       happening in the entire time LambdaMOO has existed.  Just my luck, just as
       I'm about to retire... :-(
    -------------------------------------------------------------------------------

- Prev: Re: The IART MOOnument: Pueblo Enhancing a MOO
- Next: inMOO Multiple Inheritance
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index