From: garnett@gestalt.austin.tx.us (John Garnett)
Newsgroups: rec.games.mud.lp
Subject: Amylaar's fixes (was Re: Gamedriver survey [LONG])
Date: 13 Oct 92 13:25:18 GMT

In article <1992Oct4.161059.22188@rhrk.uni-kl.de>  
behrends@arctecserv-1.dfki.uni-kl.de (Karl Reimer Behrends) writes:

> Umm. This is going to be a long reply with lots of details.
> 
> In article <1992Oct3.235822.10384@fy.chalmers.se>, jacob@fy.chalmers.se
(Jacob Hallen) writes:
>>In article <1992Oct2.205121.2309@rhrk.uni-kl.de> behrends@dfki.uni-kl.de
(Karl Reimer Behrends) writes:
>>>
>>>>Now this point is debatable. IMHO the CD driver isn't stable at all (at
least
>>>version 1.57) but prone to unpredictable crashs as well as MudOS 0.8.14
and the
>>>vanilla 3.1.2 driver. I tried four wellknown (hmmm, not that wellknown at
all,
>>>it appears) ways to crash vanilla 3.1.2 on the CD and MudOS driver. 
>> 
>> I would be very interested in hearing about these bugs. Do you have code
>> that can be used to repeat them? Do you have fixes or bug descriptions?
> 
>Certainly. But you could easily have found them by studying Amylaar's done
file.

I've studied Amylaar's "done" file.  At best he gives one sentence describing
the bug and at worst a few words.

Here are Amylaar's done file comments on the bugs you mention:

 * Made proper leaving of a switch() statement with continue; possible.
 * Fixed the general lvalue lifetime bug.
 * Corrected throw(0)
 * Save_object will now mark identical arrays/mappings as such. This also
   enables crash-free saving of recursive structures.

I don't know about you but "general lvalue lifetime bug" isn't enough to
tell me what he fixed or what was even wrong (unless maybe you've seen
the bug in question discussed elsewhere).  And "corrected throw(0)" looks
innocuous enough... how to know that it corrects a crasher? (the same with
continue within a switch).  Well, you might argue that I or others should
look through Amylaar's code and read the comments on the fixes.  Ha!  There
aren't any.  Granted, this might be explained by the fact that Amylaar
usually fixes bugs by doing a complete rewrite of the section involved
rather than patching....(not that I'm complaining).  The context diffs
alone between 3.1.2g and 3.1.2i (3.1.2h wasn't available at the time)
are over 300,000 bytes (with little comment regarding what was changed
and why).

> 1) continue within a switca. The CD driver prints a nice traceback before
>    dumping core, MudOS just dies silently. Easy fix: disallow continue
within
>    switches. Amylaar did better and made it possible to use continue within
>    a switch.

This continue-within-a-switch bug was reported to Amylaar by the people
doing MudOS (originally reported to MudOS by Xeno@VH).  Here is the
ChangeLog entry from the MudOS ChangeLog:

Wed Aug  5 05:10:02 CDT 1992 (Truilkan@TMI)
    * bumped patchlevel up to 0.8.23
    * fixed the switch/continue bug.  "continue" from inside a "switch"
      caused the driver to crash because the continue was preventing
      the "break_sp" stack from being popped.  Solution was to add
      another eoperator (F_POP_BREAK) and another stack (switch_stack)
      to *lang.y.  "continue" statements issued from inside a "switch"
      now generate the code required to pop the "break_sp" stack as
      many times as exist nested "switch" statements (since the beginning
      of the nearest containing loop).

> 2) throw(0). This causes an underflow of the catch context stack since
throw(0)
>    is also used as an end_of_catch code. Fix: disallow throw() or use a
different
>    stack machine code as an end of catch instruction. Thanks to the people
at
>    Nanny for pointing out this bug to me.

Thanks for mentioning this one.  For those interested in fixing it here is
some more information:

The section for F_CATCH in postlang.y marks the end of the code for a catch()
statement by inserting the token to force a throw(0) to occur.  The problem
is that this solution allows the LPC programmer to crash the mud by adding
throw(0) to his code (this statement wasn't meant to be issued by a
programmer - just by the F_CATCH code generator).  The solution is to
remove the throw 0 capability from the F_THROW case in interpret.c and
to add an END_CATCH operator which performs the action that used to be
handled by throw(0).  F_CATCH in postlang.y should insert the code for
this new operator rather than for throw(0).  The END_CATCH operator can't
be generated by any statement other than catch() and so can't be used to
crash the driver.

> 3) Mutual recursive inherits, i.e. A inherits B and B inherits A. This will
>    lead to infinite recursion and crash as soons as stack overflow occurs.
>    Fix: limit the maximal inheritance depth allowed.

This one has been fixed in MudOS for some time now (0.8.17):

Fri Jul 10 21:05:30 1992  Erik Kay  (Wayfarer@Portals)

    * added >>some<< of Whiplash's changes in.  Specifically, the
    patch to hidden objects, which allowed them to actually be hidden.
    (I'm not sure I like this) The other addition is a maximum inherit
    chain size to prevent infinite inherit chains.  This is a
    compatibility buster as it requires a new addition to the runtime
    config file: "inherit chain size".  The number value given is the
    max depth of inheritance the driver will allow.

> 4) save_object() within objects containg circular arrays. Example:

For now this bug is still in MudOS.  However, the idea behind Amylaar's
solution is a good one and will probably eventually be used by MudOS.

> 5) lvalue lifetime bug: There isn't an easy fix for it and it leads to
delayed

This bug is also still in MudOS.  I asked Amylaar about this one and he
claims a substantial part of the (huge) diffs from 3.1.2h and 3.1.2i involve
the solution to this problem.  All of which means if you want to use
Amylaar's fix you'd probably either merge your code into his or plan
on rewriting much of your driver :).

--John
Newsgroups: rec.games.mud.lp