Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!caesar.cs.montana.edu!milton!efowler
From: efowler@milton.acs.washington.edu (Eric Fowler)
Newsgroups: comp.lang.c
Subject: Re: MSC 5.1 make
Message-ID: <1490@milton.acs.washington.edu>
Date: 21 Jan 90 05:43:34 GMT
References: <1989Dec15.021527.18711@sjuphil.uucp> <884@thor.wright.EDU> <557@mwtech.UUCP>
Reply-To: efowler@milton.acs.washington.edu (Eric Fowler)
Organization: University of Washington, Seattle
Lines: 30

I have been trying to write a simple program that reads strings from 
an open file, then sorts them into a binary tree structure(this just for 
own curiosity, not for any good reason:-)). The procedure checks each string
against the string in the appropriate field at the appropriate node, then
(as appropriate)either increments an integer field and returns control(the
strings matched), moves "left"/"right" (one string is smaller, the pointer 
that way is not NULL), or sets the pointer to the value returned by a function 
that mallocs memory for the structure and the string field contained therein, 
puts the input string into the string field, and returns a pointer to the new
structure. Naturally, the function which compares the strings, checks the 
pointers, and calls the function to return the pointer to the new structure is
recursive. 
	Now, when this is called, it runs perfectly for a variable length of 
time, that is, it varies according to:(1)whether it is on a mainframe or PC;
(longer on the PC, sometimes terminating successfully);(2)whether the output
is directed to the screen or a file(longer if it goes to a file);(3)which file
it is fed for input. All of the input files are ASCII text files, of modest 
size. Given very small files, it will terminate normally at EOF. Given larger
files, it dies, usually with an error indicating a memory problem(DYNIX:
"segmentation error:core dumped", BSD Tahoe:"bus error", DOS said something 
like this too). Furthermore, the dbx debugger accuses "malloc" of forcing 
an exit. It is clear even to me that there is a memory allocation problem here
(no kidding! :-)). What is not clear is what is going wrong, and how I can 
fix it. No way is the stack getting too big-the files are not that large, and 
it will go much further with some input files than others, that is, it will 
build a tree to depth 8 or 10 with one input file, but bomb at depth 2 or 3
with others. (Any given file with the same output redirection generates id-
entical output every time it is run, however). Also unclear is how the screen 
I/O can screw up the stack. It is apparent that the stack is being corrupted, 
but I don't know how. Any help appreciated. Thanks. =Eric