1. Segmentation Faults
- Posted by Kayhlan <kayhlan at EARTHLINK.NET>
Aug 14, 2000
-
Last edited Aug 15, 2000
Hello Folks,
I'm coding a game in Euphoria under the Linux platform. After three
years + of programming, I have approximately 1.5 meg of game code (this
is a text-based game, not a graphical one) and I've recently been
getting "segmentation fault" errors. I know that Euphoria does not
generate an ex.err file because of the segmentation fault, but I need to
know what sorts of things cause these segmentation faults because I
cannot duplicate the error at will, it seems to randomly occur. I use
very few calls to the C language, mostly it is just manipulation of
sequences.
I have to tell you, this is a very discouraging development to occur so
close to the completion of my project, so any suggestions or ideas will
really be appreciated. If you need more information on my programming or
what the specs of my game involve, let me know and I can fill in the
details.
Thanks for your help,
Kayhlan
2. Re: Segmentation Faults
On Mon, 14 Aug 2000, Kayhlan wrote:
> Hello Folks,
>
> I'm coding a game in Euphoria under the Linux platform. After three
> years + of programming, I have approximately 1.5 meg of game code (this
> is a text-based game, not a graphical one) and I've recently been
> getting "segmentation fault" errors. I know that Euphoria does not
> generate an ex.err file because of the segmentation fault, but I need to
> know what sorts of things cause these segmentation faults because I
> cannot duplicate the error at will, it seems to randomly occur. I use
> very few calls to the C language, mostly it is just manipulation of
> sequences.
Hi Kayhlan:
>From my own experience, segmentation faults are generally caused by an
attempt to reference a physical location in memory that Euphoria does not "own".
This can happen thu pokes (or peeks) into memory that Euphoria has not
allocated. Sometimes it happens when calling a c routine and passing an
invalid pointer. That causes the c routine to muck about where it doesn't
belong.
These things can be hard to track down, the only way I know is to trace into
the suspected area, and step thru the code. You'll find the call that is
causing the problem. Then it's just a matter of trying to figure out which
parameter of the call is incorrect.
Regards,
Irv
3. Re: Segmentation Faults
Kayhlan writes:
> I've recently been getting "segmentation fault" errors.
Whenever you get a segmentation fault, CauseWay error,
or other machine-level exception, your first line of defence
is to use safe.e in euphoria\include. Simply copy safe.e
into the same directory as your program, then rename it
as machine.e. It will take over the duties of machine.e,
while checking for all sorts of different machine-level bugs.
It doesn't always catch the error, but it's definitely worth a try.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Segmentation Faults
On 14 Aug 2000, at 13:06, Irv Mullins wrote:
> On Mon, 14 Aug 2000, Kayhlan wrote:
> > Hello Folks,
> >
> > I'm coding a game in Euphoria under the Linux platform. After three
> > years + of programming, I have approximately 1.5 meg of game code (this
> > is a text-based game, not a graphical one) and I've recently been
> > getting "segmentation fault" errors. I know that Euphoria does not
> > generate an ex.err file because of the segmentation fault, but I need to
> > know what sorts of things cause these segmentation faults because I
> > cannot duplicate the error at will, it seems to randomly occur. I use
> > very few calls to the C language, mostly it is just manipulation of
> > sequences.
>
> Hi Kayhlan:
>
> >From my own experience, segmentation faults are generally caused by an
> attempt to reference a physical location in memory that Euphoria does not
> "own".
> This can happen thu pokes (or peeks) into memory that Euphoria has not
> allocated. Sometimes it happens when calling a c routine and passing an
> invalid pointer. That causes the c routine to muck about where it doesn't
> belong.
>
> These things can be hard to track down, the only way I know is to trace into
> the suspected area, and step thru the code. You'll find the call that is
> causing the problem. Then it's just a matter of trying to figure out which
> parameter of the call is incorrect.
do something like this:
if ( PtrVar > UpperMemoryLimit ) or ( PtrVar < LowerMemoryLimit ) then trace(1)
end if
That will drop you into the debugger where you can check vars or ! to abort and
get a
var dump in ex.err.
Kat
