From mboxrd@z Thu Jan  1 00:00:00 1970
From: jlw@sco.com
To: kranasian_soul@excite.com, help-gcc@gnu.org, help@gnu.org
Cc: dctd@mudspring.uplb.edu.ph
Subject: Re: Help, Weird GCC behavior
Date: Mon, 05 Mar 2001 10:42:00 -0000
Message-id: <200103051836.NAA29467@sapphire.newjersey.sco.com>
X-SW-Source: 2001-03/msg00031.html

Kranasian Soul wrote:
	
	My thesis is having problems.  I have been pain-stakingly building a
	Civ-like Game Server Platform for online gaming.  I have tried a lot of
	memory debuggers but after weeks of debugging, I have found out that the
	souce of the Segmentation fault is a return() statement.  What could
	possibly occur in a return statement that would cause a segmentation fault? 
	I used MALLOC_CHECK_=1 flag to try to see if it is related to malloc and it
	displays
	
	malloc(): top chunk corrupt
	realloc(): not a valid ptr 0xXXXXXX
	
	I don't know what could possibly cause an error in my return statement when
	the return line in a function is
	
		return(Return);
	
	nothing different with this one since i have been using Return as a return
	variable by convention.  I have attached my Server Files with this email. 

I was unable to compile your code because I do not have a copy of mss.h
on my system, but all the symptoms that you describe can be a manifestation
of a single user coding error......  writing beyond the end of an array -
destroying data in memory locations following that array.

  1. Segmentation fault following a return() statement.

     In addition to passing any return value to the calling function, the
     return implicitly restablishes the frame pointer value of the caller
     and branches to the calling function code through a return pointer
     that is typically stored on the stack.

     If either the previous frame pointer or return address value has
     been corrupted, a failure is imminent.  A common user error is to
     write beyond the end of a local array, thus destroying either the
     return address of previous frame pointer.

     The only array in GetSightChunk() is Display[10] into which a
     string is constructed with sprintf().  The format string of the 
     sprintf will construct a 10 character string (counting the terminating
     NULL) if and only if the  value of GameWorld[x][y].Data)->ChunkType
     is a value between 0 and 9.  The code seems to limit the values to
     be printed to >= 0 and <= 4, but the code also seems to expect the
     possibility that the value of the pointer GameWorld[x][y].Data
     may change during the execution of this function ==>   ERROR!!!
     message.

     I see other places in your code where ChunkType may be set to values
     greater than 10.  If the last print out of Display, shows more than a
     single char used (including leading sign or space)to represent
     ChunkType, sprintf() has
     placed more than 10 characters into Display (check the value returned
     by sprintf()), surrounding data on the stack probably has been 
     corrupted.

  2. malloc(): top chunk corrupt

     An previous malloc() created data item has had data written beyond the
     end of the space allocated and corrupted the data used by the malloc
     routines to manage free space.

       - writing beyond the size of an array.
       - writing through a pointer to a "small" item that has been cast to 
         a pointer t a "larger" item.

  3.realloc(): not a valid ptr 0xXXXXXX

     Again writing beyond the end of an allocateed block of mamort mat corrupt
     the control structure used to manage that block's memory allocation and
     reallocation.

     Another possibility is trying to realloc() a pointer that has already been
     free()'ed or realloc() a pointer that was not created through malloc().

Hope that provides you with some clues to resolve your problems.

-- John Wolfe     (jlw@sco.com)