Xref: utzoo comp.sys.3b1:1822 rec.games.hack:13495
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!zaphod.mps.ohio-state.edu!n8emr!colnet!res
From: res@colnet.uucp (Rob Stampfli)
Newsgroups: comp.sys.3b1,rec.games.hack
Subject: Re: nethack3p10 on unixpc/3b1/7300
Message-ID: <1991Jun27.132849.24734@colnet.uucp>
Date: 27 Jun 91 13:28:49 GMT
References: <1991Jun26.041914.25466@iguana.uucp> <1991Jun27.001421.3061@ceilidh.beartrack.com>
Organization: Little to None
Lines: 25

>	I have been being hit with this search bug, which is deadly if you
>are an elf, since they automatically use the search by their very nature.  I
>have always been hit by it, till I just tried it by shelling out of trn, in
>which it now works.  Since it doesn't dump core, it makes it hard to
>determine the source of the problem.  The error message is:
>
>	Memory fault
...
>	I hit the problem even if logged in via ethernet and rlogin, but if
>I shell out, from trn, or from jove, I don't.  I wonder why?  Lets try
>something!

Often, when a program runs in one environment, but not in another, the
problem is due to a bad reference on the stack.  Depending on where the
page breaks occur relative to the stack pointer, such a reference beyond
the end of the stack pointer may either appear to work, or if it is truly
beyond the last allocated page, cause a memory fault.  The difference is
that the programs have different environments pressed onto the stack when
they are invoked.

Try exporting a few garbage variables which have been set to long strings
and see if this changes anything.  If so, look for automatic arrays that
are indexed beyond their defined size.
-- 
Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh