Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!bridge2!mips!prls!pyramid!leadsv!zech
From: zech@leadsv.UUCP (Bill Zech)
Newsgroups: comp.lang.c
Subject: Re: Bus Error
Summary: 68000 bus errors
Message-ID: <10342@leadsv.UUCP>
Date: 14 Mar 90 21:02:44 GMT
References: <16139.25F89344@urchin.fidonet.org> <1990Mar13.042241.17357@cubmol.bio.columbia.edu>
Organization: LOCKHEED, Sunnyvale, CA
Lines: 26

In article <1990Mar13.042241.17357@cubmol.bio.columbia.edu>, ping@cubmol.bio.columbia.edu (Shiping Zhang) writes:
> 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  
> From my own experiences, "Bus Error" results from index of arrays
> reaching beyond their ranges. But I'm not sure if it's the only
> cause for this kind of errors.
> 

In the Motorola 68xxx series chips, a Bus Error is the result of some
peripheral (I/O, memory, etc.), or possibly the cpu board itself, 
asserting the BERR line to the 68xxx chip.

For C programs, the most common source of bus error is asserted by the
cpu board, resulting from a timeout while waiting for DTACK (or DSACK
on 68020s) from the memory or I/O system.  What this boils down to
is that you tried to read or write to non-existant memory or I/O space,
and since nobody responded to the 68xxx's request, the cpu board
timed out and asserted BERR to the 68xxx to make it stop waiting.
BERR causes an exception and your program blows up.  The contents
of the stack at that point contains the address in question and
your program's last instruction address.  Note that because of pre-fetch, your 
program counter could be several bytes ahead of the actual instruction
that failed.

- Bill