Path: utzoo!attcan!uunet!kddlab!trl!rdmei!iegva1!creamy!oucom2!digigw!gday
From: gday@digigw.lab.digital.co.jp (Gordon Day)
Newsgroups: comp.lang.c
Subject: Re: Bus Error
Summary: You're missing the point!!
Message-ID: <307@digigw.lab.digital.co.jp>
Date: 20 Mar 90 01:48:45 GMT
References: <16139.25F89344@urchin.fidonet.org> <1990Mar13.042241.17357@cubmol.bio.columbia.edu>
Organization: Digital Electronics Corp., Osaka, Japan
Lines: 33

> In article <16139.25F89344@urchin.fidonet.org> Lynn.Lively@p4694.f506.n106.z1.fidonet.org (Lynn Lively) writes:
>
>Does anyone know what a "Bus Error" is? I've got a very complicated program  

Look, you people have been going on about the hardware architecture of the
68000 for some time now, but is that really the point?  IMHO Ms. Lively, while
perhaps fascinated by the intricacies of memory management and fetch/decode
cycles, really wanted a bit of help on where to look for the problem in her
code =:) (If I'm wrong on this, I DO apologise!)

I expect that you are either using C or doing pointer manipulation in some
other language.  What any system trap like "Segmentation Fault", "Bus Error",
etc, boils down to is that your program has clobbered some part of memory that
it had no right to.  In C, the way this happens is you are forgetting to 
allocate space, or assuming it is allocated when it's not, then stuffing data
into said space.  The "solution":

- use lint.

- if you define a pointer somewhere, check very carefully that space has been
  allocated.  In the C world VERY FEW library routines allocate pointers they
  are passed.

- remember: a pointer fault can show up in mysterious ways if it is overwriting
  your stack space (arguments get changed on their way to functions, Bus Errors
  occur, etc).

- practice.

I know the above comment is bloody simplistic, but I felt that was what was
wanted.  Sorry again if I'm wrong.

=:! gday@digital.co.jp%uunet.uu.net