Subject: Upgrade to NeXT 3.0 does not help

From: jonathan bradshaw <[email-masked]>
Date: Sat, 13 Nov 1993 00:56:46 -0800

Well, I guess I was wrong. Unfortunatly, I upgraded to NS 3.0 and instead of
the MOO simply panicing and killing itself it now causes the whole NeXT to
panic and die. The NeXT doesn't reboot, and just sits there in the ROM
monitor. I have the MOO automaticly downing on a daily basis but this does
not help. The NeXT has 20mb of ram, the MOO uses 5MB virtual memory.

Out of curiousity, anyone else NOT using GNU malloc routines? Since the NeXT
doesn't, I wonder if this makes a big difference.

I'm looking for help... anyone with a NeXT.... I need the NeXT to reboot
when it panics, not sit in the monitor but I can find NO option to make
this happen. I really hate to have to dump the MOO and go with something
else (recommendations?) since I have so much code in it but I have run
out of options. I cannot keep killing the NeXT machine.

-- 
 Jonathan Bradshaw | Preferred E-Mail is: [email-masked] | Ham N9OXE
 WNDU-AM/FM/TV South Bend IN | Opinions stated are mine and not of my employer
 PGP 2.2 Key is available on keyserver or send mail with subject of 'send key'
 "If any girl rejects you, don't you doubt it's part of the .plan" - D. Gibson

---

From: Chris Hand <[email-masked]>
Date: Sat, 13 Nov 1993 05:17:20 -0800

> doesn't, I wonder if this makes a big difference.

I'm running MOO 1.7.6 on HP-UX 9.01 on a HP7000/735.  I used the HP
cc (which is not particularly good), with bison -- probably an unusual
combination (we were in the process of getting GCC sorted out and I
couldn't wait).

The major problem I had was compiling -- alloca() is referenced by
bison but not (as far as I could see) actually called anywhere, this
caused the link to fail since we don't have alloca().  To fix it I just stuck
a dummy alloca() in one of the C source files.

We've had the MOO running now for about 2 weeks and it hasn't
crashed (touch wood).  We *did* lose some database changes at one time
when we accidentally ran up 2 servers together, but that's most likely
our fault.

Chris

-- 
Chris Hand, Lecturer                      | Dept of Computing Science,
Internet e-mail: [email-masked]            | De Montfort University, The Gateway 
 Reality is 80 Million polygons/second    | LEICESTER, UK   LE1 9BH            
WWW: <A HREF="http://qadir.cms.dmu.ac.uk:9999/People/cph/cphroot.html">cph</A>

---

From: Pavel Curtis <[email-masked]>
Date: Sun, 14 Nov 1993 16:46:47 -0800

> Date:	Sat, 13 Nov 1993 00:56:46 -0800
> From:	jonathan bradshaw <[email-masked]>
> 
> monitor.

Well, I should hope that it was obvious now that the problem is in NeXT's
operating system and not in the server code... :-)

> doesn't, I wonder if this makes a big difference.

On LambdaMOO itself, I use the standard SunOS malloc from the C library and
haven't had any problems.

	Pavel