Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!bionet!ames!uhccux!munnari.oz.au!goanna!ok
From: ok@goanna.oz.au (Richard O'keefe)
Newsgroups: comp.lang.c
Subject: Re: Bus Error
Message-ID: <3011@goanna.oz.au>
Date: 22 Mar 90 01:36:42 GMT
References: <16139.25F89344@urchin.fidonet.org> <307@digigw.lab.digital.co.jp>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 26

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? 
In article <307@digigw.lab.digital.co.jp>,
gday@digigw.lab.digital.co.jp (Gordon Day) writes:
> IMHO Ms. Lively, ...
> really wanted a bit of help on where to look for the problem in her code.

Just so.  Unfortunately, what Gordon Day goes on to describe is likely
causes of a Segmentation Violation.  To a *very* rough approximation

	Segmentation Violation =	pointer into non-existent memory
					(dereferencing NULL is a common cause)

	Bus Error =			malformed or misaligned pointer
					(e.g. short *p = 1; ... *p ...
					on a PDP-11)

Watch out for integers cast to pointers, for unions that overlay pointers
and integers, for missing arguments in function calls (so that a numeric
argument has been mistaken for an accidentally omitted pointer).  Use lint.

Basically, the best way of looking for the cause of either signal is to use
sdb or dbx or dbxtool or whatever debugger you have and see where the
program stopped.  It should be quite clear which pointer variable was being
dereferenced.  Then try to figure out how it got that value.  With a Bus
Error the value can *never* have been a valid pointer.