Problems with nomask inheritance in MudOS:
Problem analysis by Luke Mewburn <zak@rmit.oz.au>, coding as Zak@Ivory.Tower
There seem to be some inconsistancies in the way that MudOS inheritance
works with the `nomask' pre-function operator. For purposes of example,
I'll show the following inheritance tree that I used whilst testing:
gp
|
|
par
/ \
/ \
bro sis
|
|
bson
nomask mixed query(string x)
In all the tests, there was a function `query' in bson which was nomasked
at all times (unless a specific test mentions its removal for that test
only)
Problems:
- unable, without a prototype, to call query() in sis. Got (for obvious
reasons) `Undefined function query'.
- In sis, a prototype of the form 'mixed query(string x);' allows sis to
to compile, and is ok when par is compiled, but when when attempting to
compile/load gp get the error 'Illegal to redefine nomasked function'.
So, it seems that the way prototypes are handled when merging in
function tables from bro and sis into par, then into gp, is having
problems in the last stage checks.
- attempting to resolve this, I tried in sis something like:
`private mixed query(string x) { return this_object()->query(x); }'
Again, the illegal nomask error for gp. Now, of all the problems, THIS
one stumps me. According to what I read, defining it as private should
mean that it won't get propagated back in the inheritance tree (from sis
-> par -> gp), and thus, shouldn't interfere with the nomask in bson.
Maybe I misunderstand private...
- the above was tried with `private static' instead of private...
- removing the nomask from query in bson allows gp to compile, but defeats
the purpose of why we nomasked in the first place...
- the solution of replacing all query()'s in sis with `this_object()->query()'
works, but this is inelegant.
So, whilst we have a working idea with the this_object()->query stuff, why
did the compiler choke on a private function in a different branch of
inheritance apparantly masking a nomask func (when my idea of private is that
it doesn't work that way.) I suspect that checking isn't correctly done in
the compiler.y function that merges in inherited function tables...
Any ideas??
Additional Info:
This problem spotted by Telsin@ivory.tower (budic@marvin.macc.wisc.edu), and
apparently also experienced by Watcher@tmi-2 while recoding their new player
object. Watcher got around it with this_object()->query() calls.
Ivory Tower is running under A/UX 3.0, currently on a mac IIci w/ 20 megs ram.
Current driver version is 0.9.17.5, but the problem was first noted in
0.9.16.21 or so. [Truilkan tried Lars 3.1.2 and found the same problem].
-----
heart_beat() is not shadowable
-----
need a way to tell the driver to try reconnecting to the addr_server
after it has gone down and come back up (the addr_server). maybe
the driver could just retry every now and then?
--john
-----
Many of the functions in array.c allocate an array and call LPC-code
afterwards. In case of an error, the memory will be gone. Pushing
the array on the stack temporarily should remedy this (of course, for
filter_array() the array of flags has to be disguised as a malloced string).
Ellery
-----
Whenever a socket function is called, it calls master()'s
valid_socket() function to see if there is approval for this action. With
this it is suppose to pass the ip address and port numbers if they are
available. However, whenever socket_connect() is called, it doesn't seem
to pass either. It seems to either pass "0.0.0.0" or "". However, the
socket_close() efun seems to pass the correct ip address and port numbers.
Anyways, is this lack of ip address and port numbers with the
socket_connect() call a bug, or am I missing something? We have setup
a telnet daemon on TMI-2 which controlls whether a socket call is authorized
or not. Thus we hope to be able block out certain ip address from being
called, and this would be very feasible if the valid_socket() call were
functioning as one would expect.
Thanks in advance for looking into this matter.
Glenn Ferguson
AKA Watcher@TMI-2
-----
string *stuff;
stuff = ({"test1", "test2", "test3"});
stuff[0][2..4] = "ab";
write(stuff[0]);
the above code crashed Genocide
(bobf@metronet.com)
Grendel says: int *stuff;stuff = ({ 1, 2, 3, 4 });stuff[1..2] = ({ 2, 3});
Grendel says: that crashes the mud
Grendel says: because the grammar allows it
Grendel says: and the eoperator doesn't expect it
(tbrann@ox.ac.uk)
-----
In compile_object, it is possible for the object to get loaded twice,
causing the game to crash. The sequence of events on our mud was to call
an external object to create the virtual object; when created, this
external object moved a couple of monsters into some rooms; one of these
rooms turned out to be the same virtual room that was currently being
created - so a recursive call to compile_object was made to create it; the
create() function in the external object finished; the external function
then cloned up a new object, initialized it, and returned it; the driver
then crashed because it had already entered an object with that name into
the hash table.
(djohnson@cs.ucsd.edu)
---
lvalue lifetime bug: There isn't an easy fix for it and it leads to delayed
and unpredictable crashes. It's simplest form is something like a[0]=(a=0).
There the reference to a[0] is pushed on the stack, a gets freed and then
the area formerly occupied by a gets assigned something. This leads to
especially nasty effects if you do something more on the right hand side,
i.e. a function call which deallocates a and then loads an object into the
free space - has rather devastating effects, I assure you. Fixing that
means major changes in the gamedriver.
-----
Lots of places in the code that do an apply and don't free the ret value.
Here, Amylaar seems to be saying that we should. This could be the source
of some memory leaks... yes?
d = apply(sort_array_cmp_func, sort_array_cmp_ob, 2);
if (!d) {
return 0;
}
if (d->type != T_NUMBER) { /* In case it's not a number --Amylaar */
free_svalue(d);
ret = 0;
(garnett@gestalt.austin.tx.us)
-----
~: Ellery says: hmm, the disable_commands();
destruct(ob_that_does_add_action_for_me); enable_commands(); will indeed
crash the driver.
Ellery smiles evilly.
-----
Note 19 Schoenf (Wed Sep 8) patchch_in(), patch_out() for 64-Bit machin
es
I'm running MUDOS on a alpha and I like to fix this thing with patch
in and patch_out .....
can one give me directions ??
-schoenf
From djohnson@cs.ucsd.edu Wed Sep 8 02:16:56 1993
Received: from actlab.rtf.utexas.edu by feenix.metronet.com with SMTP id AA05877
(5.65c/feenix for <bobf@metronet.com>); Wed, 8 Sep 1993 11:17:44 -0500
Return-Path: <djohnson@cs.ucsd.edu>
Received: from odin.ucsd.edu by actlab.rtf.utexas.edu (5.0/SMI-SVR4)
id AA29188; Wed, 8 Sep 93 11:17:30 CDT
Received: from seuss.ucsd.edu by odin.ucsd.edu; id AA06781
sendmail 5.67/UCSDPSEUDO.4-CS via SMTP
Wed, 8 Sep 93 09:16:58 -0700 for mudos-bugs@actlab.rtf.utexas.edu
Received: by seuss (5.67/UCSDPSEUDO.4)
id AA06881 for mudos-bugs@actlab.rtf.utexas.edu; Wed, 8 Sep 93 09:16:56
-0700
From: djohnson@cs.ucsd.edu (Darin Johnson)
Message-Id: <9309081616.AA06881@seuss>
Subject: Re: your mail
To: bobf@feenix.metronet.com (Bob Farmer)
Date: Wed, 8 Sep 1993 09:16:56 -0700 (PDT)
Cc: mudos-bugs@actlab.rtf.utexas.edu (MudOS Buglist)
In-Reply-To: <199309080929.AA25958@feenix.metronet.com> from "Bob Farmer" at Sep
8, 93 04:29:25 am
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 592
Hmm, I could whip something up for an alpha I suppose
(or something assumed to work on an alpha, since I can
only use them when a certain prof isn't in town).
However, the same problems in the patch_in and patch_out
*also* occur in the parser when processing switch statements,
and in the f_switch efun. That is, it assumes keys are
4 bytes long. I suspect that if this actually works at
the moment on an alpha, it's because the upper 32 bits
in these addresses are all 0's or something similar.
So if patch_in/patch_out get fixed, the switch code will also
need fixing at the same time.
-----
~: Ellery says: btw, there is a potential crasher in destruct_object
~: Ellery says: move an object inside a shadow's inventory that causes an error
in move_or_destruct()
Ellery says: thereafter the shadow chain will be corrupted.
---
From bobf Thu Sep 30 00:17:19 1993
Received: from actlab.rtf.utexas.edu by feenix.metronet.com with SMTP id AA20288
(5.65c/feenix for <bobf@metronet.com>); Thu, 30 Sep 1993 05:23:07 -0500
Return-Path: <bobf>
Received: from feenix.metronet.com by actlab.rtf.utexas.edu (5.0/SMI-SVR4)
id AA24670; Thu, 30 Sep 93 05:17:43 CDT
Received: by feenix.metronet.com id AA20192
(5.65c/feenix for mudos-bugs@actlab.rtf.utexas.edu); Thu, 30 Sep 1993 05:17:19
-0500
Date: Thu, 30 Sep 1993 05:17:19 -0500
From: Bob Farmer <bobf>
Message-Id: <199309301017.AA20192@feenix.metronet.com>
Apparently-To: mudos-bugs@actlab.rtf.utexas.edu
Content-Length: 197
read_file() doesn't guarantee that a "/" is at the start of the filename
before passing to valid_read()...same problem might exist with
write_file(), read_bytes(), write_bytes(), didn't check yet
---
From bobf Wed Oct 27 14:06:06 1993
Received: from actlab.rtf.utexas.edu by feenix.metronet.com with SMTP id AA22843
(5.65c/feenix for <bobf@metronet.com>); Wed, 27 Oct 1993 20:02:02 -0500
Return-Path: <bobf>
Received: from feenix.metronet.com by actlab.rtf.utexas.edu (5.0/SMI-SVR4)
id AA06490; Wed, 27 Oct 93 19:06:21 CDT
Received: by feenix.metronet.com id AA19571
(5.65c/feenix for mudos-bugs@actlab.rtf.utexas.edu); Wed, 27 Oct 1993 19:06:06
-0500
Date: Wed, 27 Oct 1993 19:06:06 -0500
From: Bob Farmer <bobf>
Message-Id: <199310280006.AA19571@feenix.metronet.com>
Apparently-To: mudos-bugs@actlab.rtf.utexas.edu
Content-Length: 0
log_error() in master causes a crash if a runtime error occurs during it.
hmm. dunno if this is acceptable or not. happened to me on one mud cuz
some guy made what would normally be his log file into a dir.
and write_file() to a dir causes a runtime error.
bt
function f;
f = (: this_object(), ({"func1", "func2"}) :);
functionp(f) doesn't return 1.
-john
---
I think if you do something like:
f = (: ob, ({ func, a, b, c }) :);
...
(*f)(d, e, f);
then the order of arguments may not be what the programmer expects...
(it will be like func(d,e,f,a,b,c))
(djohnson@cs.ucsd.edu)
---
when using binaries, sometimes it seems they don't notice that include files
have newer dates. it seems you must remove the .b file sometimes for
it to update properly. hmmmm.
Not many details available, noticed by at least 2 people though.
---
Note 18 Vax (Mon Dec 13) regexp() bug
> return regexp (({ "aa", "a", "aaabbb" }), "[a-z]+")
Result = ({ })
> return regexp (({ "a+" }), "[a-z]+")
Result = ({ "a+" })
---
The following program,
...
// crash.c
move(dst) { move_object(dst); }
init() { destruct(this_player()); }
...
crashes the driver when you do:
new("/whereever/crash")->move(this_player());
bobf
---
nomask mixed query(string label) {
mixed value;
...
return value;
}
Generates errors because the return type does not match "nomask mixed".
---
In move_or_destruct() of simulate.c [line 1966 in 0.9.19.31, I believe.]
there is an apply to the move() of the dested object. This hidden little
bit of behavior was causing us a bit of a problem since our move lfun
was move(dest, force-the-move). forcing the move was always true of course,
so players autoloads were not dested, they were moved to the env of the
player.
I don't know whether the above code is a bug, or just an undocumented
feature. Perhaps it should be a master apply. I do know that the lack
of documentation of it made for a sticky debugging problem in the mudlib
after we added the force-the-move flag to move().
Thank you for you attention, and for all your work on the driver.
Erik B. Flom
Artagel
@TMI-2
@Elements of Parafox