miller@b-mrda.ca.boeing.com (Mark Miller) (01/05/91)
Sounds like a wild pointer. Look for one of the following instances: /* problem 1 */ char *p1; char *p2 = "Hello there"; strcpy(p2, p1); /* No memory allocated for p1 - overwrites other stuff */ /* problem 2 */ int array[10]; array[12] = 100; /* Writing past end of array */ /* problem 3 */ char array[4]; strcpy (array, "Four"); /* Trailing zero of string runs past end of array */ These and other such instances are tough to find. I have used the heapwalk() and heapcheck() functions to help in troubleshooting and to isolate the troublesome module. Also, check to see that all memory that you dynamically allocate (with malloc, calloc, etc.) is PROPERLY freed. That is, if you use farmalloc(), then you must use farfree() to free the allocated memory. Good luck. ------------------------------------------------------------------------------ Mark R. Miller | Boeing Commercial Airplane Company | Seattle, WA | Internet: miller@b-mrda.boeing.com | Voicenet: (206) 237-0960 | ------------------------------------------------------------------------------ Opinions expressed here do not necessarily reflect those of my employer. ------------------------------------------------------------------------------
dougs@videovax.tv.tek.com (Doug Stevens) (01/05/91)
In article <1991Jan3.125057.21477@cbnewsm.att.com>, mds1@cbnewsm.att.com (marc.d.sayre) writes: > > I use this structure a lot across functions ... > > I recently started to expand the code and start getting weird responses > when I execute the program ... > I've seen this problem MANY times in systems in which the dependencies have not been maintained in the make file. In these cases, the definition of the structure is in an include file, and is not listed as a dependency for all the files that use it. The program gets extended by adding another field to the structure, and some code that operates on that field. All the code that operates on fields listed BEFORE the new field works OK, but code operating on fields listed AFTER the new field breaks (because the file containing the code has not been re-compiled, and still uses the old offset within the structure to access the field). A dead give-away is to do a build-all (if you are operating from a make file, just touch all the .c's, then re-compile); if the code starts working, the above problem is occurring. Another really nasty possibility is that the structure is independently defined in every file that uses it, and the definitions are not the same. My approach is to put structure definitions in .h files, and to always use autodependency checking when compiling and linking.
price@chakra.unl.edu (Chad Price) (01/06/91)
In <1991Jan3.125057.21477@cbnewsm.att.com> mds1@cbnewsm.att.com (marc.d.sayre) writes: >Hello programmers, > For all of you out there that use borland turbo C 1.5 or later I have a > question. I have been programming a lot of stuff with floats, where I have > a global structure called empdata with about ten floats in there. > I recently started to expand the code and start getting weird responses > when I execute the program, all the other functions that use the global structure > work fine, I add a function and it works fine, I change some lines of > code and get strange errors. I take away the code again and still get > the weird errors. The best help I can provide is to suggest that you spend the money & update to the most recent version of Turbo C (++). I had similar problems about a year ago, and was unable to get a resolution from Borland. I do remember that for TC 2.0, there were some patches available from Borland which included a linkage problem with floats - if I recall correctly, if a float wasn't declared in the function (File??) where you used the global variable, then the float routines were not linked in and the program blew up. chad price price@fergvcax.unl.edu