Subject: vm_deallocate error

From: [email-masked] (Chad Wilson)
Date: Wed, 9 Jun 1993 11:12:00 -0700

Alright, not only have i had enuf of the vm_allocate errors causing my MOO
to crash, now i've got a new one!

Is is possible for the creators/maintainers of the MOO server code to make
a nextStep specific version, so it knows how to release memory properly? 
I think that there are enuf MOO's running on NeXT's to warrant this (I
know of 4 at hand).

my new error: vm_deallocate error
 then the MOO just stopped running.  no warnings.  no nothing.

- crwilson@way too many different e-mail addresses.

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 9 Jun 1993 11:21:48 -0700

> Date:	Wed, 9 Jun 1993 11:12:00 -0700
> From:	[email-masked] (Chad Wilson)
> 

I'm afraid that I must disagree.  The number of NeXT machines running MOO
servers is almost entirely irrelevant to how I choose to spend my time working
on the server.  The server uses the ANSI standard memory allocation primitives
malloc() and free() in a completely correct fashion, with no leaks of any
significant size (i.e. no more than a few kilobytes of lost memory over the
course of weeks).  If the NeXT implementation of those primitives is buggy or
inferior, that's a shame but not a major concern for me personally.

Now, all that says is that I won't even attempt to make a NeXTStep-specific
version of the server myself.  I will, however, consider incorporating somebody
else's well-written and -documented patches into the general release.  Feel
free to send them along.

	Pavel

---

From: [email-masked] (Jonathan Bradshaw)
Date: Wed, 9 Jun 1993 11:26:00 -0700

> - crwilson@way too many different e-mail addresses.

I got this once too. Does seem to be a global NeXT memory allocation/dealloc
problem. There are NO core dumps however from it. Just panics. Yeh, I hate
NeXT but I don't see getting any other machine for the MOO. My plan is to
go to 20MB of ram and NeXT Step 3.0. Dunno if this will help or not. Anyone
running NS3? I have found something interesting. If I only run the MOO from
like 7pm - 7am then my likelyhood of a panic is small or none. The longer
the MOO is running the more likely it is to panic. I would say that this
would reflect the increase in malloc()/free() type calls in the period of
time. I have perused the kernel malloc() pages and it seems that a NIL
pointer (which is what malloc() is returning and causes the panic) can
be returned if a significant amount of fragmentation has occoured. Unfortunatly,
I'm not at the host machine (and its locked up) so I can't pull it up (unless
someone has an RTF -> Text program they can send me) or maybe another NeXT
user can send Pavel a copy. 

Maybe disk basing would be a help since then I won't lose an hour or whatever
since the last dump each time it happens. I love the MOO server and have too
much time invested to ever consider switching but I'd love to have my server
running as long as Lambda does with dieing.

In my opinion, the NeXT can't seem to cope with the huge amount of malloc()
free() calls that the MOO makes. Of course, I could be wrong! Since I doubt
there are bugs in the code because Lambda sure hasn't seen them it is likely
to be NeXT based. However, a WORK-AROUND would sure be nice #IFDEF NEXT!!!

-- 
Jonathan Bradshaw | Email [email-masked] | Prodigy XMSN02B | Ham N9OXE
  WNDU-AM/FM/TV South Bend, IN | Disclaimer "My opinions are not my employers"
"If any girl rejects you, don't you doubt it's part of the .plan"-Deborah Gibson