Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt.cs.cmu.edu!ius2.cs.cmu.edu!edw
From: edw@ius2.cs.cmu.edu (Eddie Wyatt)
Newsgroups: comp.lang.c
Subject: Re: Fatal Bug in VAX C pointer indirection
Message-ID: <1152@ius2.cs.cmu.edu>
Date: Mon, 11-May-87 11:51:15 EDT
Article-I.D.: ius2.1152
Posted: Mon May 11 11:51:15 1987
Date-Received: Wed, 13-May-87 04:07:28 EDT
References: <582@bsu-cs.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 63
Keywords: Fatal Bug VAX C pointer indirection


   This letter really doesn't merit a reply, but I'll write one anyway.

   I take it that your machine is running VMS not Unix.  To say
you are working on a VAX really says nothing.

   I doubt very very very very much that there is anything wrong with
the VMS C compiler or malloc.  I personally don't work with a VMS
system but I have seen enough bus errors and segmentation faults to
guess at what your problem is.  Things to look at:

	o If you have a multitude of modules, make sure that they
	  are all recently compiled.  The problem that may arise here
	  is if you have made any changes to the struct lista then
	  those changes may not be reflected in code that was compiled
	  before the changes (ie sizeof(lista-old) != sizeof(lista)).

	o Do you ever free any objects. If so are you sure that you
	  are not accessing that object after you free it.

	o Do you ever allocate array in fact do you use any arrays?
	  If so are you sure that you do not over index the array.
	  The common problem here is:

			array = alloc_array(int,10);
			for (i = 0; i <= 10 ; i++)
				array[i] = 0;  /* boom */

	o A more bizzaire problem is over writing the code segments
	  of your program.  Fun bug to track down, let me tell
	  you.  It took me a whole day to find one in a program
	  that I did not write.  Anyway, problems can come from
	  accessing uninitialized pointer values. Example:

			foobar()
			    {
			    int *screw; /* :-) */

			    *screw = 2.0;
			    }

	  This may show up right away (segmentation fault or bus
	  error in Unix) or if you are so lucky it will show up
	  miles away in the in totally unrelated code (posibly illegal
	  instruction).

	o I haven't run up against this problem but I think you can even
	  do things like call free on memory not allocated with
	  malloc or calloc (like stack memory) and have things go crazy.

    Just because malloc doesn't return pointers inorder doesn't mean
there is anything wrong.  Malloc will search the free list before making
a system call for more memory (in Unix it is a call to sbrk which
increases the size of the programs data space).  I do believe that is
how "fast fit" works.

  Doesn't VMS have a symbolic debugger?  I thought it did, learn how
to use it fast.

-- 
					Eddie Wyatt

e-mail: edw@ius2.cs.cmu.edu