Xref: utzoo comp.sys.ibm.pc:28861 comp.lang.c:18687
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!tekbspa!optilink!cramer
From: cramer@optilink.UUCP (Clayton Cramer)
Newsgroups: comp.sys.ibm.pc,comp.lang.c
Subject: Re: Possible bug in MSC malloc (Large Memory Model)
Keywords: malloc, bug MSC5.1
Message-ID: <1447@optilink.UUCP>
Date: 15 May 89 17:23:19 GMT
References: <1071@koko.CSUStan.EDU>
Distribution: usa
Organization: Optilink Corporation, Petaluma, CA
Lines: 116

In article <1071@koko.CSUStan.EDU>, jb@CSUStan.EDU (John Birchfield) writes:
> I have a program which does directory scanning in a big way and I am
> finding that the program corrupts memory and behaves in a more or less
> irrational manner when the Large Memory Model is used.
> 
> The errors reported relate to the inability to allocate memory and the
> program failing or that DOS reports memory as being corrupted and
> can't load COMMAND.COM when the program terminates.
> 
> The problems dissappear when I use the Small Memory Model - I know that this
> sounds like the old pointer size problem but I have looked over the places
> the program does mallocs and frees and they seem to be correct.
> 
> The question then is IS THERE A KNOWN BUG IN MALLOC USING THE LARGE MEMORY
> MODEL???
> 
> John Birchfield                                       1575 Quail Ct.

There may be a bug, but it is almost certainly a bug in your code
somewhere -- probably a place where you free something you don't
own, or use heap you haven't allocated.  Here's something that I
use for debugging.  The #defines go in some high level .h file that
all modules include, and cause all your mallocs and frees to actually
go to MyMalloc and MyFree, which records every malloc and free.
Go through the output file when your program finishes, and remove
all the matching pairs of malloc and free records, and you will
frequently find blocks of memory you didn't malloc being freed.
This screws up the heap something awful, with all sorts of un-
pleasant side effects.

This doesn't do you any good for references through uninitialized
pointers, but it will solve some problems, as well as giving you
an idea how much heap you are mallocing, and how long you are
keeping it.

/* Special purpose definitions intended for use in debugging memory allocation
and freeing errors. */
#define malloc(A) MyMalloc(__FILE__, __LINE__, A)
#define free(A) MyFree(__FILE__, __LINE__, A)

FILE*	MallocOut = NULL;
	
void *MyMalloc (FileName, LineNbr, BytesToGet)

char*		FileName;
int			LineNbr;
size_t		BytesToGet;

	{
	void*	Mem;
	
	if(MallocOut)
		{
#if 0
		Mem = (void*)halloc((long)BytesToGet, sizeof(char));
#else
		Mem = malloc(BytesToGet);
#endif
		if(Mem)
			fprintf(MallocOut, "M %04x:%04x %s:%d %5d\n", FP_SEG(Mem), 
					FP_OFF(Mem), FileName, LineNbr, BytesToGet);
		else
			fprintf(MallocOut, "*          %s:%d %5d\n", FileName, LineNbr, 
					BytesToGet);
		fflush(MallocOut);
		}
	else
#if 0
		Mem = (void*)halloc((long)BytesToGet, sizeof(char));
#else
		Mem = malloc(BytesToGet);
#endif
	return(Mem);
	}

void MyFree (FileName, LineNbr, Mem)

char*		FileName;
int			LineNbr;
void*		Mem;

	{
	if(MallocOut)
		{
		if(Mem)
			fprintf(MallocOut, "F %04x:%04x %s:%d\n", FP_SEG(Mem), 
					FP_OFF(Mem), FileName, LineNbr);
		fflush(MallocOut);
		}
#if 0
	if(Mem)
		hfree(Mem);
#else
	if(Mem)
		free(Mem);
#endif
	}

void StartMallocRecord ()

	{
	MallocOut = fopen("malloc", "w+");
	}

void EndMallocRecord ()

	{
	fclose(MallocOut);
	MallocOut = NULL;
	}

-- 
Clayton E. Cramer                   {pyramid,pixar,tekbspa}!optilink!cramer
Assault rifle possession is a victimless crime.
----------------------------------------------------------------------------
Disclaimer?  You must be kidding!  No company would hold opinions like mine!