Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rice!rice!sun-spots-request
From: matrix!venkat@uunet.uu.net (D Venkatrangan)
Newsgroups: comp.sys.sun
Subject: Re: debugging query
Keywords: Miscellaneous
Message-ID: <1990Nov1.000753.23868@rice.edu>
Date: 1 Nov 90 00:23:49 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 23
Approved: Sun-Spots@rice.edu
Originator: spots@titan.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 355, message 3
X-Original-Date: 10 Oct 90 17:26:48 GMT
X-Refs:  Original: v9n337

In article <1990Oct7.230303.2350@rice.edu> silvert@cs.dal.ca (Bill Silvert) writes:

>Consistently I have programs give me segmentation errors with virtually no
>way of finding out what the error is -- even if I run dbx with debug and
>trace the best I can do is find out what happened before the crash.  For
>example, this code error:
>
>	char *env;
>	env = getenv("STRING");
>	if(strchr(env, 'a')) ...
>
>crashes if STRING is not defined so that env = NULL (other machines don't
>even consider this an error, they act as though *env = '\0').  But I can't
>get the debugger to tell me that I have illegally passed a NULL pointer, I
>just get the dreaded signal 11.

In SS architecture machines, if you cast a non quad-word aligned address
into a quad-word type (such as in int), you could cause a program crash
similar to the type you have described.  Perhaps your problem is the same.
The debugger would not show that anything is wrong.  About the only thing
you can verify in dbx is to assembly step to the instruction where you get
the segmentation error and examine the target address of the mov that
causes the crash.  Make sure it is quad-word aligned.