Help, Weird GCC behavior

Help, Weird GCC behavior

[Kranasian Soul X (RDX4)]

[-- Attachment #1: Type: text/plain, Size: 2901 bytes --]

To all experts in GCC memory allocation,

Please help me... 

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. 
Please help.


Detail:
The data structures in the Game Server has become quite complex for an easy
explaination but if the tar file will be extracted, all files needed for the
Server be there.  Just in case you want to see the error for yourself...
please, extract the attachment compile it with these options (At least I
do).

gcc -oGameServer -lm -lncurses -lpthread GameServer.c

Execute GameServer and say "Y" to the prompt. and press two returns or
ENTER.  It will put the server online.  It will listen to port 4621.  The
SIGSEGV will not arise until the third connection. (Why?)
To establish a connection:

telnet <Game HOST> 4621

when connected:  (the server will respond with a connection) type

N<TAB><username><TAB><password><TAB><Name><ENTER>

<TAB> -> must be a single tab as a delimiter
<ENTER> -> the carriage return
<username> -> any name (max 8 chars)
<password> -> any password (max 15 chars)
<Name> -> any name (max 20 chars)

The letter N stands for New Player.  It is included.

try doing this with different usernames for 3 times.  A SIGSEGV will arrise.


To help you (and me) locate the source of the problem, every connection task
displays the status.  The last display before the SIGSEGV is four "+"
plusses "++++" which is printed before the return(Return); statement.  This
function is located in MapQueryRoutines.c under GetSightChunk().  see
print("++++");
The function call process starts with:

ThreadNewConnection() in file TNewConnection.c calls
CreateBase() in file PlayerRoutines.c calls
NotifyTileChange in file APlayerRelations.c calls
GetSightChunk in file MapQueryRoutines.c
  ^- where the error occurs.

I don't know if the fault is with me.  As I think it is.  any clue?

Thank you very, very much for reading up to this part.


Greatest Thanks,

Dan Cedric Delima
Kranasian Soul X


"Articulus Primus Dalestini Conquerum Hex"
"Altari Motif Art Tagoni"
"Soldevi solembe"





_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/


[-- Attachment #2: gameserver.tar.gz --]
[-- Type: application/x-gzip, Size: 38435 bytes --]

Re: Help, Weird GCC behavior

[jlw]

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)