Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!jarthur!petunia!polyslo!jdudeck
From: jdudeck@polyslo.CalPoly.EDU (John R. Dudeck)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: Is there a bug in MSC 5.1 malloc for far data?
Message-ID: <2603111f.6e86@polyslo.CalPoly.EDU>
Date: 18 Mar 90 04:39:59 GMT
References: <25f8a7cd.ca@polyslo.CalPoly.EDU> <9573@wpi.wpi.edu>
Reply-To: jdudeck@polyslo.CalPoly.EDU (John R. Dudeck)
Organization: Cal Poly State University -- San Luis Obispo
Lines: 53


In article <9573@wpi.wpi.edu> ear@wpi.wpi.edu (Eric A Rasmussen) writes:
>In article <25f8a7cd.ca@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes:
>>I have been having trouble with a compiler project that I am doing in
>>MS C 5.1.  It appears that malloc() is sometimes getting hung in a very
>>tight loop.  It doesn't happen all the time.  If I run my program
>>right after rebooting it always works, but if I run it right after a
>>compile, sometimes malloc hangs.  If I run it in CodeView and this happens
>>I can stop it with Ctrl-Break, and step through the machine language,
>>and it is stuck in the library routine in a very tight (about 6 instructions)
>>loop.
>>I am using the compact memory model, on a 386/20, and MS-DOS 4.01.
>
>It is possible that you are having a problem which is semi-common in 386's,
>especially fast ones.  If you have a feature known as pipelining enabled, it
>can sometimes cause the machine to hang, even when the program executes
>perfectly on PC's and AT's.  Pipelining reads ahead in the list of
>instructions for the processor to execute, a sort of cache which can help
>increase execution speed.  Problems can be brought on if you use *gasp*
>self-modifying code that modifies the code that has been already read into the
>pipeline.  It is also possible, I would suppose, that it could cause programs
>with really short loops to crash.  Two possible fixes to test this theory
>would be to A) Put the machine in its slowest mode, 8 Mhz for most 386's,
>which generally reduces the number of instructions the processor has time to
>read ahead and may solve the problem, or B) Turn off the pipelining.  
>
Last night I did some further research into my problem.  (A few days ago
I thought it was solved because I found where I was clobbering code via
wild pointers.  But I fixed that one, and then the problem showed up again).

Actually, now I am seeing a slightly different problem from the hanging up:
I found that after several calls to malloc() to get more data, suddenly
it gave me a block of data that it had ALREADY allocated!  So I was
getting the same block of data for two different parts of my program to
write on, and of course everything gets scrambled.

I verified that I was calling malloc() with a reasonable request each time
(around 1k, it varied slightly), by using code view to breakpoint the calls.

One time I tried putting my 386 down to 16mhz (it runs at 20 normally).
I also set the wait state to 1 (I usually set it to 0).  Nothing changed.

My hypotheses at this point are:
 - My library routines are corrupted.
 - DOS 4.01 has a bug.
 - I still have a wild pointer somewhere writing to memory outside my data.

I have seen various references on the net to a malloc() replacement or
some similar package which can be used to verify use of dynamically allocated
memory.  Of course I didn't save the info.  So I would appreciate it if
someone could point me where to find it (via ftp).

Thanks.

-- 
John Dudeck                           "You want to read the code closely..." 
jdudeck@Polyslo.CalPoly.Edu             -- C. Staley, in OS course, teaching 
ESL: 62013975 Tel: 805-545-9549          Tanenbaum's MINIX operating system.