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
-----
Updating master.c causes the mud to crash again. What seems to be happening
is that when init_object() is called on the new master object (from
assert_master_ob_loaded), a reset() gets called on the object. Other than
being something incorrect, on our mud, this reset uses a file operation,
which causes assert_master_ob_loaded to be called again, causing the crash.
-----
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
-----
Example:
string *test;
test = ({ "Decker" });
printf( "Array is: %-15.15O\n", test );
Just sit and wait now...it'll hang the driver.
Decker
-----
Could you fellas make it possible to refresh the simul_efun without
taking down the whole mud ? i.e. not doing a shutdown !
As it is now, one can make changes in the function that are present
but you cannot add or remove function and then update the simul_efun
object. This would be helpful on a running mud, at least whilst
debugging it !
Radagast Redrobe !
-----
string *stuff;
stuff = ({"test1", "test2", "test3"});
stuff[0][2..4] = "ab";
write(stuff[0]);
taht code crashes genocide apparently
haven't looked further into it..will do it soon
bt
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
-----
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)
-----
:z
set_wandering(1, 120, 0);
set_chats(({
"smile",
"sing Santa Claws is coming to town!",
"say Do we have any good children here?",
"say You must be kind to your fellow people.",
"smile Do you believe in the magic of christmas?",
"smile",
"laugh"
}), 10);
:I
Indenting entire code...
Done indenting.
:I
Indenting entire code...
Detected a unterminated string on line 43
Indention halted.
:43
"l}), 10);
:-10
:z
set_wandering(1, 120, 0);
set_chats(({
"smile",
"sing Santa Claws is coming to town!",
"say Do we have any good children here?",
"say You must be kind to your fellow people.",
"smile Do you believe in the magic of christmas?",
"smile",
"laugh"
"l}), 10);
}
:Q
Exit from ed.
So there has been extra "l inserted into during the first intendation
which caused the second intendation to barf about the unterminated string.
---
save_object doesn't prepend a "/" to the filename before passing to
valid_write()
(bobf@metronet.com)
-----
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)
-----
'cost' field in domain/author stats isn't actually set anywhere
(bobf@metronet.com)
-----
From: djohnson@cs.ucsd.edu (Darin Johnson)
Message-Id: <9306220643.AA06062@elvis>
Subject: + versus += for arrays
To: mudos-bugs@actlab.rtf.utexas.edu (MudOS Buglist)
Date: Mon, 21 Jun 1993 23:43:43 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 142
Note that "array = array + scalar" is allowed, yet "array += scalar"
is not allowed. (the first case uses append_vector() in interpret.c)
-----
~: 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.