MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Weird listen()ing, server PANIC, and bad make, to boot!

Well, several things [this is all with 1.8.0alpha6, with the patches to
execute.c and list.c installed -- though I wasn't using decode_binary(), for
whatever that's worth].  Before I describe the (reproduceable) panic, I
should also mention some strangeness with listen():

I was listening to two ports again, and noticed some very
odd behavior -- when a user telnetting to the second port (which was being
listened to by a copy of #0) quit the MOO, the .aliases property of object #66
(Display Options) was printed to the screen before the disconnected finished.
(This was fully reproduceable, and changes to #66.aliases were reflected
in the output.  Weird...)

My guess was that this was not being done by anything in the db, but I wanted
to be sure before posting here. As far as I could ascertain, this description
was not being sent through player:tell() or player:notify().  I was trying
some things out to see if maybe it was coming through $user_disconnected()
[perhaps with a raw notify() command -- though why on earth it would do
  for each in (#66.aliases) notify(player, each); endfor
is beyond me] when the panic happened -- and the weirdest part is that
according to the traceback, it was caused by a comment line:

Jan 28 21:39:40: object:bar (this == #11), line 1:  server panic
Jan 28 21:39:40: ... called from object:foo (this == #11), line 7
Jan 28 21:39:40: ... called from object:look_self (this == #11), line 5
Jan 28 21:39:40: ... called from built-in function pass()
Jan 28 21:39:40: ... called from parent:look_self (this == #11), line 26
Jan 28 21:39:40: ... called from parent:l*ook (this == #11), line 8
Jan 28 21:39:40: (End of [edited] traceback)

Object and it's parent are `rooms,' somewhat modified Lambda ones. The first 5
lines of object:bar() were all string comments, as were the first 6 lines
of object:foo().  Line 7 simply tests that object:bar() is true:
if(this_list = object:bar())
 ...

so it looks to me (an armchair debugger :-) ) like the problem is somewhere
else - perhaps related to the pass()?  It was independent of the listen()
stuff I described earlier, because I reloaded the db (well, the PANIC db --
maybe it's corrupted, but wouldn't that come out in the loading process?) and
simply typed look, and forced another panic.

I tried to dbx it again, but got

% dbx moo core
dbx version 2.10.1
Type 'help' for help.
Corefile produced from file "moo"
Child died at pc 0x43a0a0 of signal : Illegal instruction
reading symbolic information ...
dbx: internal error: Proc symbol (begin_code_allocation:F19) without proc table entry

Is there something else I should be doing to make dbx happy?
The computer the moo is on doesn't have gdb installed, and the computers
which do have gdb don't seem to like to configure script -- I had to remove a
control-L which appears near the beginning of it; although configure seems
happy then (and says all the network options work), make doesn't work:

% make
gcc -Wall -Wwrite-strings -g  -O -c ast.c
gcc -Wall -Wwrite-strings -g  -O -c code_gen.c
gcc -Wall -Wwrite-strings -g  -O -c db_file.c
In file included from db_file.c:33:
options.h:233: #error You cannot use BSD sockets without having select()!
*** Exit 1
Stop.
Home | Subject Index | Thread Index